Hi all,
I'm converting the entity XML tools (in the webtools application) from jsp to widgets: the conversion is rather simple, the jsp file is substituted bya a screen definition, a bsh script containing all the java code from the jsp file, and an ftl template. Everything works fine except one thing: during xml data import (in xmldsimport.jsp and xmldsimportdir.jsp) if an error is found in the xml file, i.e.: reader.parse(url); the current transaction is marked for roll back (probably by the reader object) and the whole screen blow up. Probably a solution could be that of starting a new transaction inside the jsp template... but I'm not sure. Your suggestions are welcome. Jacopo _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Jacopo, From this description I'm not quite sure what is going wrong, though it sounds like the biggest issue is that the error coming back isn't very helpful, is that correct? Perhaps a good way to work through this is to leave the current page in place and submit the new one as an alternate page that can be enabled by changing the view-map to point to it instead of the jsp. -David On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote: > Hi all, > > I'm converting the entity XML tools (in the webtools application) > from jsp to widgets: the conversion is rather simple, the jsp file > is substituted bya a screen definition, a bsh script containing all > the java code from the jsp file, and an ftl template. > > Everything works fine except one thing: during xml data import (in > xmldsimport.jsp and xmldsimportdir.jsp) if an error is found in the > xml file, i.e.: > > reader.parse(url); > > the current transaction is marked for roll back (probably by the > reader object) and the whole screen blow up. > > Probably a solution could be that of starting a new transaction > inside the jsp template... but I'm not sure. > > Your suggestions are welcome. > > Jacopo > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev smime.p7s (3K) Download Attachment |
David,
sorry, I was not clear at all. The main problem is that, if an error is found parsing the entity xml file, then the screen is not rendered, instead you get the attached error page/message. I think that the problem is that the screen is not rendered because the screen's transaction has been marked for rollback by the parser... but I could be wrong. The problematic code is this (taken from line 152 of xmldsimport.jsp): try { numberRead = reader.parse(url); } catch(Exception exc) { %><div class="tabletext">ERROR: <%=exc.toString()%></div><% } That I have simply converted in bsh code in the following way: try { numberRead = reader.parse(fulltext); } catch(Exception exc) { errorMessageList.add("ERROR: " + exc.getMessage()); } If an exception is thrown by the reader.parse(...) method, instead of the error message in the screen, I get an error page (see error.GIF). (I've trown a "bogus exception" from the parse(...) method for debug purposes). I've resolved the problem adding a rollback command: try { numberRead = reader.parse(fulltext); } catch(Exception exc) { TransactionUtil.rollback(true, "ERROR: ", exc); errorMessageList.add("ERROR: " + exc.getMessage()); } With this code I get a good error message in the screen (see solution.GIF). However I don't know if this is a good way of doing things or not. Jacopo David E. Jones wrote: > > Jacopo, > > From this description I'm not quite sure what is going wrong, though > it sounds like the biggest issue is that the error coming back isn't > very helpful, is that correct? > > Perhaps a good way to work through this is to leave the current page in > place and submit the new one as an alternate page that can be enabled > by changing the view-map to point to it instead of the jsp. > > -David > > > On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote: > >> Hi all, >> >> I'm converting the entity XML tools (in the webtools application) >> from jsp to widgets: the conversion is rather simple, the jsp file is >> substituted bya a screen definition, a bsh script containing all the >> java code from the jsp file, and an ftl template. >> >> Everything works fine except one thing: during xml data import (in >> xmldsimport.jsp and xmldsimportdir.jsp) if an error is found in the >> xml file, i.e.: >> >> reader.parse(url); >> >> the current transaction is marked for roll back (probably by the >> reader object) and the whole screen blow up. >> >> Probably a solution could be that of starting a new transaction >> inside the jsp template... but I'm not sure. >> >> Your suggestions are welcome. >> >> Jacopo >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Technically no code block should rollback or commit a transaction that it didn't begin. It is fine to set the rollbackOnly flag anywhere, which is what it is meant for. What this code should probably do is either not catch the exception at all, or catch it and then after logging a debug message just re- throw the exception. -David On Oct 15, 2005, at 2:41 AM, Jacopo Cappellato wrote: > David, > > sorry, I was not clear at all. > The main problem is that, if an error is found parsing the entity xml > file, then the screen is not rendered, instead you get the attached > error page/message. > I think that the problem is that the screen is not rendered because > the > screen's transaction has been marked for rollback by the parser... > but I > could be wrong. > > The problematic code is this (taken from line 152 of xmldsimport.jsp): > > try { > numberRead = reader.parse(url); > } catch(Exception exc) { > %><div class="tabletext">ERROR: <%=exc.toString()%></div><% > } > > That I have simply converted in bsh code in the following way: > > try { > numberRead = reader.parse(fulltext); > } catch(Exception exc) { > errorMessageList.add("ERROR: " + exc.getMessage()); > } > > If an exception is thrown by the reader.parse(...) method, instead > of the error message in the screen, I get an error page (see > error.GIF). > (I've trown a "bogus exception" from the parse(...) method for > debug purposes). > > I've resolved the problem adding a rollback command: > > try { > numberRead = reader.parse(fulltext); > } catch(Exception exc) { > TransactionUtil.rollback(true, "ERROR: ", exc); > errorMessageList.add("ERROR: " + exc.getMessage()); > } > > With this code I get a good error message in the screen (see > solution.GIF). > > However I don't know if this is a good way of doing things or not. > > Jacopo > > > David E. Jones wrote: > >> Jacopo, >> From this description I'm not quite sure what is going wrong, >> though it sounds like the biggest issue is that the error coming >> back isn't very helpful, is that correct? >> Perhaps a good way to work through this is to leave the current >> page in place and submit the new one as an alternate page that >> can be enabled by changing the view-map to point to it instead of >> the jsp. >> -David >> On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote: >> >>> Hi all, >>> >>> I'm converting the entity XML tools (in the webtools >>> application) from jsp to widgets: the conversion is rather >>> simple, the jsp file is substituted bya a screen definition, a >>> bsh script containing all the java code from the jsp file, and >>> an ftl template. >>> >>> Everything works fine except one thing: during xml data import >>> (in xmldsimport.jsp and xmldsimportdir.jsp) if an error is found >>> in the xml file, i.e.: >>> >>> reader.parse(url); >>> >>> the current transaction is marked for roll back (probably by the >>> reader object) and the whole screen blow up. >>> >>> Probably a solution could be that of starting a new transaction >>> inside the jsp template... but I'm not sure. >>> >>> Your suggestions are welcome. >>> >>> Jacopo >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >>> >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> > > > > <error.GIF> > <solution.GIF> > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev smime.p7s (3K) Download Attachment |
Jacopo, Okay, after looking around for a while at this I was trying to figure out a way we could generally handle situations like this better, and all I can come up with is this: the logic there really should go into an event (probably as a service) as it is not data preparation logic. If something like this happened in data preparation logic then the view wouldn't render successfully and we would want this sort of thing to happen. The only way to get the view to display properly would be to know which screen actions are critical and should abort screen rendering or which should be ignored and listed as error messages. In general that's not such a big deal, but in a case where form submission processing is done in the view instead of in an event where it should be, we are breaking the design pattern and there is no real way to make it work properly. Does that make sense? So, I guess the solution is to move the import logic to a service and mount it as a request event... -David On Oct 24, 2005, at 3:29 AM, Jacopo Cappellato wrote: > Hi David, > > The code is now in SVN (thanks for committing it with r. 6007), so > you can easily have a look at it (see EntityImport.bsh, line 182). > > The code now is: > > try { > numberRead = reader.parse(fulltext); > } catch(Exception exc) { > TransactionUtil.rollback(true, "ERROR: ", exc); > errorMessageList.add("ERROR: " + exc.getMessage()); > } > > and, as a result of an exception thrown by the parse(...) method, > we get the with-rollback.jpg page (this is a nice error message). > > If I change the code to: > > try { > numberRead = reader.parse(fulltext); > } catch(Exception exc) { > errorMessageList.add("ERROR: " + exc.getMessage()); > } > > I get the without-rollback.jpg screen. > > If I change the code to not catch the exception: > > //try { > numberRead = reader.parse(fulltext); > //} catch(Exception exc) { > errorMessageList.add("ERROR: " + exc.getMessage()); > //} > > I get the no-catch.jpg screen. > > Thanks for your time. > > Jacopo > > David E. Jones wrote: > >> Technically no code block should rollback or commit a transaction >> that it didn't begin. It is fine to set the rollbackOnly flag >> anywhere, which is what it is meant for. >> What this code should probably do is either not catch the >> exception at all, or catch it and then after logging a debug >> message just re- throw the exception. >> -David >> On Oct 15, 2005, at 2:41 AM, Jacopo Cappellato wrote: >> >>> David, >>> >>> sorry, I was not clear at all. >>> The main problem is that, if an error is found parsing the entity >>> xml >>> file, then the screen is not rendered, instead you get the attached >>> error page/message. >>> I think that the problem is that the screen is not rendered >>> because the >>> screen's transaction has been marked for rollback by the >>> parser... but I >>> could be wrong. >>> >>> The problematic code is this (taken from line 152 of >>> xmldsimport.jsp): >>> >>> try { >>> numberRead = reader.parse(url); >>> } catch(Exception exc) { >>> %><div class="tabletext">ERROR: <%=exc.toString()%></div><% >>> } >>> >>> That I have simply converted in bsh code in the following way: >>> >>> try { >>> numberRead = reader.parse(fulltext); >>> } catch(Exception exc) { >>> errorMessageList.add("ERROR: " + exc.getMessage()); >>> } >>> >>> If an exception is thrown by the reader.parse(...) method, >>> instead of the error message in the screen, I get an error page >>> (see error.GIF). >>> (I've trown a "bogus exception" from the parse(...) method for >>> debug purposes). >>> >>> I've resolved the problem adding a rollback command: >>> >>> try { >>> numberRead = reader.parse(fulltext); >>> } catch(Exception exc) { >>> TransactionUtil.rollback(true, "ERROR: ", exc); >>> errorMessageList.add("ERROR: " + exc.getMessage()); >>> } >>> >>> With this code I get a good error message in the screen (see >>> solution.GIF). >>> >>> However I don't know if this is a good way of doing things or not. >>> >>> Jacopo >>> >>> >>> David E. Jones wrote: >>> >>> >>>> Jacopo, >>>> From this description I'm not quite sure what is going wrong, >>>> though it sounds like the biggest issue is that the error >>>> coming back isn't very helpful, is that correct? >>>> Perhaps a good way to work through this is to leave the current >>>> page in place and submit the new one as an alternate page that >>>> can be enabled by changing the view-map to point to it instead >>>> of the jsp. >>>> -David >>>> On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote: >>>> >>>> >>>>> Hi all, >>>>> >>>>> I'm converting the entity XML tools (in the webtools >>>>> application) from jsp to widgets: the conversion is rather >>>>> simple, the jsp file is substituted bya a screen definition, >>>>> a bsh script containing all the java code from the jsp file, >>>>> and an ftl template. >>>>> >>>>> Everything works fine except one thing: during xml data import >>>>> (in xmldsimport.jsp and xmldsimportdir.jsp) if an error is >>>>> found in the xml file, i.e.: >>>>> >>>>> reader.parse(url); >>>>> >>>>> the current transaction is marked for roll back (probably by >>>>> the reader object) and the whole screen blow up. >>>>> >>>>> Probably a solution could be that of starting a new >>>>> transaction inside the jsp template... but I'm not sure. >>>>> >>>>> Your suggestions are welcome. >>>>> >>>>> Jacopo >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [hidden email] >>>>> http://lists.ofbiz.org/mailman/listinfo/dev >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------- >>>> -- --- >>>> _______________________________________________ >>>> Dev mailing list >>>> [hidden email] >>>> http://lists.ofbiz.org/mailman/listinfo/dev >>>> >>>> >>> >>> >>> >>> <error.GIF> >>> <solution.GIF> >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> > > > <no-rollback.JPG> > <with-rollback.JPG> > <without-rollback.JPG> > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev smime.p7s (3K) Download Attachment |
David,
thanks for your review and solution. I'll put this refactorings (moving import logic to services) in my todo list. Jacopo David E. Jones wrote: > > Jacopo, > > Okay, after looking around for a while at this I was trying to figure > out a way we could generally handle situations like this better, and > all I can come up with is this: the logic there really should go into > an event (probably as a service) as it is not data preparation logic. > If something like this happened in data preparation logic then the view > wouldn't render successfully and we would want this sort of thing to > happen. > > The only way to get the view to display properly would be to know which > screen actions are critical and should abort screen rendering or which > should be ignored and listed as error messages. In general that's not > such a big deal, but in a case where form submission processing is done > in the view instead of in an event where it should be, we are breaking > the design pattern and there is no real way to make it work properly. > > Does that make sense? So, I guess the solution is to move the import > logic to a service and mount it as a request event... > > -David > > > On Oct 24, 2005, at 3:29 AM, Jacopo Cappellato wrote: > >> Hi David, >> >> The code is now in SVN (thanks for committing it with r. 6007), so >> you can easily have a look at it (see EntityImport.bsh, line 182). >> >> The code now is: >> >> try { >> numberRead = reader.parse(fulltext); >> } catch(Exception exc) { >> TransactionUtil.rollback(true, "ERROR: ", exc); >> errorMessageList.add("ERROR: " + exc.getMessage()); >> } >> >> and, as a result of an exception thrown by the parse(...) method, we >> get the with-rollback.jpg page (this is a nice error message). >> >> If I change the code to: >> >> try { >> numberRead = reader.parse(fulltext); >> } catch(Exception exc) { >> errorMessageList.add("ERROR: " + exc.getMessage()); >> } >> >> I get the without-rollback.jpg screen. >> >> If I change the code to not catch the exception: >> >> //try { >> numberRead = reader.parse(fulltext); >> //} catch(Exception exc) { >> errorMessageList.add("ERROR: " + exc.getMessage()); >> //} >> >> I get the no-catch.jpg screen. >> >> Thanks for your time. >> >> Jacopo >> >> David E. Jones wrote: >> >>> Technically no code block should rollback or commit a transaction >>> that it didn't begin. It is fine to set the rollbackOnly flag >>> anywhere, which is what it is meant for. >>> What this code should probably do is either not catch the exception >>> at all, or catch it and then after logging a debug message just re- >>> throw the exception. >>> -David >>> On Oct 15, 2005, at 2:41 AM, Jacopo Cappellato wrote: >>> >>>> David, >>>> >>>> sorry, I was not clear at all. >>>> The main problem is that, if an error is found parsing the entity xml >>>> file, then the screen is not rendered, instead you get the attached >>>> error page/message. >>>> I think that the problem is that the screen is not rendered >>>> because the >>>> screen's transaction has been marked for rollback by the parser... >>>> but I >>>> could be wrong. >>>> >>>> The problematic code is this (taken from line 152 of xmldsimport.jsp): >>>> >>>> try { >>>> numberRead = reader.parse(url); >>>> } catch(Exception exc) { >>>> %><div class="tabletext">ERROR: <%=exc.toString()%></div><% >>>> } >>>> >>>> That I have simply converted in bsh code in the following way: >>>> >>>> try { >>>> numberRead = reader.parse(fulltext); >>>> } catch(Exception exc) { >>>> errorMessageList.add("ERROR: " + exc.getMessage()); >>>> } >>>> >>>> If an exception is thrown by the reader.parse(...) method, instead >>>> of the error message in the screen, I get an error page (see >>>> error.GIF). >>>> (I've trown a "bogus exception" from the parse(...) method for >>>> debug purposes). >>>> >>>> I've resolved the problem adding a rollback command: >>>> >>>> try { >>>> numberRead = reader.parse(fulltext); >>>> } catch(Exception exc) { >>>> TransactionUtil.rollback(true, "ERROR: ", exc); >>>> errorMessageList.add("ERROR: " + exc.getMessage()); >>>> } >>>> >>>> With this code I get a good error message in the screen (see >>>> solution.GIF). >>>> >>>> However I don't know if this is a good way of doing things or not. >>>> >>>> Jacopo >>>> >>>> >>>> David E. Jones wrote: >>>> >>>> >>>>> Jacopo, >>>>> From this description I'm not quite sure what is going wrong, >>>>> though it sounds like the biggest issue is that the error coming >>>>> back isn't very helpful, is that correct? >>>>> Perhaps a good way to work through this is to leave the current >>>>> page in place and submit the new one as an alternate page that >>>>> can be enabled by changing the view-map to point to it instead >>>>> of the jsp. >>>>> -David >>>>> On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote: >>>>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm converting the entity XML tools (in the webtools >>>>>> application) from jsp to widgets: the conversion is rather >>>>>> simple, the jsp file is substituted bya a screen definition, a >>>>>> bsh script containing all the java code from the jsp file, and >>>>>> an ftl template. >>>>>> >>>>>> Everything works fine except one thing: during xml data import >>>>>> (in xmldsimport.jsp and xmldsimportdir.jsp) if an error is >>>>>> found in the xml file, i.e.: >>>>>> >>>>>> reader.parse(url); >>>>>> >>>>>> the current transaction is marked for roll back (probably by >>>>>> the reader object) and the whole screen blow up. >>>>>> >>>>>> Probably a solution could be that of starting a new transaction >>>>>> inside the jsp template... but I'm not sure. >>>>>> >>>>>> Your suggestions are welcome. >>>>>> >>>>>> Jacopo >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [hidden email] >>>>>> http://lists.ofbiz.org/mailman/listinfo/dev >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------- >>>>> -- --- >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [hidden email] >>>>> http://lists.ofbiz.org/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> >>>> <error.GIF> >>>> <solution.GIF> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [hidden email] >>>> http://lists.ofbiz.org/mailman/listinfo/dev >>>> >>> --------------------------------------------------------------------- >>> --- >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >> >> >> <no-rollback.JPG> >> <with-rollback.JPG> >> <without-rollback.JPG> >> > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Free forum by Nabble | Edit this page |