Re: [jira] Reopened: (WW-2105, WW-2052)
Are these issues re-opened because of the back-porting to 2.0.10, or because they do not work in trunk? Nils-H - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Reopened: (WW-2105, WW-2052)
Nils, Backporting :) That's why I assigned them to me. It's working in our apps (done a lot of testing last few days), so it looks safe to me to check in. When I'm done with checking in, I'll assign these issues back to you for reviewing, if you don't mind. Regards, Rene Am Do, 23.08.2007, 10:11, schrieb Nils-Helge Garli: > Are these issues re-opened because of the back-porting to 2.0.10, or > because they do not work in trunk? > > Nils-H > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Reopened: (WW-2105, WW-2052)
Great! I'll review them when you're done. Nils-H On 8/23/07, Rene Gielen <[EMAIL PROTECTED]> wrote: > Nils, > > Backporting :) > That's why I assigned them to me. It's working in our apps (done a lot of > testing last few days), so it looks safe to me to check in. > When I'm done with checking in, I'll assign these issues back to you for > reviewing, if you don't mind. > > Regards, > Rene > > Am Do, 23.08.2007, 10:11, schrieb Nils-Helge Garli: > > Are these issues re-opened because of the back-porting to 2.0.10, or > > because they do not work in trunk? > > > > Nils-H > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OSS Bamboo] Struts 2 SVN - 2.0.x Branch (Java 6) build 65 has FAILED (0 tests failed). Change made by Rene Gielen
The project Struts 2 SVN - 2.0.x Branch (Java 6) has the following 3 changes by 1 author: *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/apps/portlet/src/main/webapp/WEB-INF/web.xml > (56) *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/context/PreparatorServletTest.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/context/ServletContextHolderListener.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/util/HttpServletRequestMock.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/context/PreparatorServlet.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/context/ServletContextHolderListenerTest.java > (568892) *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletStateInterceptor.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/interceptor/PortletAwareInterceptorTest.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/interceptor > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletRequestAware.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/result/PortletActionRedirectResult.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletAwareInterceptor.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletContextAware.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletResponseAware.java > (568894) --- No failed tests found, a possible compilation error. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-STRUTS20J6-65 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OSS Bamboo] Struts 2 SVN - 2.0.x Branch build 121 has FAILED (0 tests failed). Change made by Rene Gielen
The project Struts 2 SVN - 2.0.x Branch has the following 3 changes by 1 author: *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/context/PreparatorServletTest.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/context/ServletContextHolderListener.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/util/HttpServletRequestMock.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/context/PreparatorServlet.java > (568892) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/context/ServletContextHolderListenerTest.java > (568892) *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletStateInterceptor.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/interceptor/PortletAwareInterceptorTest.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/interceptor > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletRequestAware.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/result/PortletActionRedirectResult.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletAwareInterceptor.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletContextAware.java > (568894) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/interceptor/PortletResponseAware.java > (568894) *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/dispatcher/Jsr168DispatcherTest.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/views/freemarker/PortletFreemarkerResult.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/context/PortletActionContext.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/dispatcher/DirectRenderFromEventAction.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/result/PortletResult.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/result/PortletVelocityResult.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/dispatcher/Jsr168Dispatcher.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/PortletActionConstants.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/resources/struts-portlet-default.xml > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/result/PortletResultTest.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/components/URL.java > (568895) --- No failed tests found, a possible compilation error. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-STRUTS20-121 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OSS Bamboo] Struts 2 SVN - 2.0.x Branch (Java 6) build 66 has FAILED (0 tests failed). Change made by Rene Gielen
The project Struts 2 SVN - 2.0.x Branch (Java 6) has the following 1 change by 1 author: *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/dispatcher/Jsr168DispatcherTest.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/views/freemarker/PortletFreemarkerResult.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/context/PortletActionContext.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/dispatcher/DirectRenderFromEventAction.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/result/PortletResult.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/result/PortletVelocityResult.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/dispatcher/Jsr168Dispatcher.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/PortletActionConstants.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/resources/struts-portlet-default.xml > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/test/java/org/apache/struts2/portlet/result/PortletResultTest.java > (568895) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/components/URL.java > (568895) --- No failed tests found, a possible compilation error. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-STRUTS20J6-66 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OSS Bamboo] Struts 2 SVN - 2.0.x Branch build 122 was SUCCESSFUL (with 704 tests). Change made by Rene Gielen
The project Struts 2 SVN - 2.0.x Branch has the following 1 change by 1 author: *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletHttpSession.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletInputStream.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletRequest.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletContext.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletRequestDispatcher.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletResponse.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletConfig.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletOutputStream.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/package.html > (568896) --- All 704 tests passed. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-STRUTS20-122 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OSS Bamboo] Struts 2 SVN - 2.0.x Branch (Java 6) build 67 was SUCCESSFUL (with 704 tests). Change made by Rene Gielen
The project Struts 2 SVN - 2.0.x Branch (Java 6) has the following 1 change by 1 author: *Rene Gielen* made the following changes at Comment: WW-1989, WW-2052, WW-2053, WW-2101, WW-2105: Backporting portlet servlet wrapping, portlet redirect/redirectAction result and related issues to 2.0.x > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletHttpSession.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletInputStream.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletRequest.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletContext.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletRequestDispatcher.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletResponse.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletConfig.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/PortletServletOutputStream.java > (568896) > /struts/struts2/branches/STRUTS_2_0_X/core/src/main/java/org/apache/struts2/portlet/servlet/package.html > (568896) --- All 704 tests passed. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-STRUTS20J6-67 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Reopened: (WW-2105, WW-2052)
Done. Am Do, 23.08.2007, 10:50, schrieb Nils-Helge Garli: > Great! I'll review them when you're done. > > Nils-H > > On 8/23/07, Rene Gielen <[EMAIL PROTECTED]> wrote: >> Nils, >> >> Backporting :) >> That's why I assigned them to me. It's working in our apps (done a lot >> of >> testing last few days), so it looks safe to me to check in. >> When I'm done with checking in, I'll assign these issues back to you for >> reviewing, if you don't mind. >> >> Regards, >> Rene >> >> Am Do, 23.08.2007, 10:11, schrieb Nils-Helge Garli: >> > Are these issues re-opened because of the back-porting to 2.0.10, or >> > because they do not work in trunk? >> > >> > Nils-H >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Reopened: (WW-2105, WW-2052)
Good work Rene! I have read through the diffs, and they look nice. Most of the biggest issues in 2.0.x should be fixed with this backport! I'll build and run the sample app later and will post the results when I'm done. Thanks again! Nils-H On 8/23/07, Rene Gielen <[EMAIL PROTECTED]> wrote: > Done. > > Am Do, 23.08.2007, 10:50, schrieb Nils-Helge Garli: > > Great! I'll review them when you're done. > > > > Nils-H > > > > On 8/23/07, Rene Gielen <[EMAIL PROTECTED]> wrote: > >> Nils, > >> > >> Backporting :) > >> That's why I assigned them to me. It's working in our apps (done a lot > >> of > >> testing last few days), so it looks safe to me to check in. > >> When I'm done with checking in, I'll assign these issues back to you for > >> reviewing, if you don't mind. > >> > >> Regards, > >> Rene > >> > >> Am Do, 23.08.2007, 10:11, schrieb Nils-Helge Garli: > >> > Are these issues re-opened because of the back-porting to 2.0.10, or > >> > because they do not work in trunk? > >> > > >> > Nils-H > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ApacheCon US 07 Atlanta - BOF anyone?
The BOF schedule is up: * http://wiki.apache.org/apachecon/BirdsOfaFeatherUs07 Do we want to schedule a open roadmap discussion, or something. It seems that there are three Struts events on the convention schedule: * Migrating to Ajax (Ted Husted) 11/12 10a * Using Groovy with Struts 2 (Mark Menard) 11/13, 10a * Go Light with Apache Struts 2 and REST (Don Brown) 11/15 5:30p The first two are part of "training days". I'll get these up on the site as we did before, and add that security page. There's also an experimental "Planet Struts" aggregator for the committers' personal blogs that we could add as a link: * http://people.apache.org/~rubys/planet/struts/ -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OSS Bamboo] Struts 2 SVN - Main Build build 485 was SUCCESSFUL (with 703 tests). Change made by jholmes
The project Struts 2 SVN - Main Build has the following 1 change by 1 author: *jholmes* made the following changes at Comment: Revert upgrade from OGNL 2.6.11 to 2.7. There were compilation issues in the Struts 1 plugin due to differences in one of the OGNL interfaces that the Struts 1 plugin uses for accessing DynaBean properties. > /struts/struts2/trunk/core/pom.xml (568984) --- All 703 tests passed. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-485 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OSS Bamboo] Struts 2 SVN - Main Build (Java 6) build 138 was SUCCESSFUL (with 703 tests). Change made by jholmes
The project Struts 2 SVN - Main Build (Java 6) has the following 1 change by 1 author: *jholmes* made the following changes at Comment: Revert upgrade from OGNL 2.6.11 to 2.7. There were compilation issues in the Struts 1 plugin due to differences in one of the OGNL interfaces that the Struts 1 plugin uses for accessing DynaBean properties. > /struts/struts2/trunk/core/pom.xml (568984) --- All 703 tests passed. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-MAINJ6-138 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
S2 release plans?
What should we do? I'm in favor of rolling a 2.0.10 beta release and a 2.1 beta release. The 2.0.10 beta would get the security fix out and allow users to get an incremental upgrade with low risk. The 2.1 beta would allow users to start testing the new 2.1 features. 2.0.10 is virtually ready to go. I have already created the release notes and they are available online at: http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.10 All we need to do is close (or move) a couple open tickets assigned to 2.0.10 and roll a release. Preparing a 2.1.0 release will take a little more work. We still need to setup release notes, etc. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 release plans?
That sounds fine to me. We can roll 2.0.10 as soon as you are ready, and then 2.1.0 as soon as the notes and such are updated. On 8/23/07, James Holmes <[EMAIL PROTECTED]> wrote: > What should we do? I'm in favor of rolling a 2.0.10 beta release and a 2.1 > beta > release. The 2.0.10 beta would get the security fix out and allow users to > get an > incremental upgrade with low risk. The 2.1 beta would allow users to start > testing the new 2.1 features. > > 2.0.10 is virtually ready to go. I have already created the release notes and > they are available online at: > > http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.10 > > All we need to do is close (or move) a couple open tickets assigned to 2.0.10 > and > roll a release. > > Preparing a 2.1.0 release will take a little more work. We still need to setup > release notes, etc. > > James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exception thrown in OGNL evaluation.
Hi Guys, I'm going to chime in in support of Ruimo Uno here. We have had problems with this too. This is not a design issue. At the end of the day, the view is calling a method and what that method does is largely irrelevant. It may throw an exception, even if you have carefully designed your application to make that unlikely. I agree that you do not want exception handling code in your views, but that isn't what we are talking about here. If a unexpected problem occurs that prevents the view from rendering properly, I don't want it handled, I want an exception thrown, eventually resulting in a 500 error. The problem is that the exception IS handled (by swallowing it). IMNSHO reacting to an exception by quietly failing to render a part of the view, and continuing on, is simply broken. cheers Perryn -Original Message- From: Ruimo Uno [mailto:[EMAIL PROTECTED] Sent: Monday, 20 August 2007 1:57 PM To: Struts Developers List Subject: Re: Exception thrown in OGNL evaluation. Hi, Rene, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > > You won't get NPE in this scenario. Ognl automatically create instance > > for you. I believe you know about this feature. > > > > Not when trying to read the property, only when applying values. The first > invocation with null foo object will cause OGNL to try to read the > property of the foo.name property and fail silently - no object will be > created. This will happen when then parameters interceptor tries to apply > values to the model (when invoking the save view) Hmm, I am not sure I fully understand what you mean but I also talking about applying the http request parameters into the model object. The automatic instance creation is done inside the OGNL and the code chage that I proposed in my first mail is not for OGNL but for XWork. You can still happily use this convenient feature even with my code change. > > Closing the session should be fixed as a design bug. I agree with you > > at this point. But in this case, the system should show an user > > friendly 'sorry page' so that the user can perform appropriate action. > > As we cannot take all bugs out of our system, need a sfety net. If > > there is a network problem between ap server and db server, lazy > > loading will fail by system error. > > but how could the fooService.getById(this.id), executed by the prepare or > action method succeed and the lazy reference getter fail just a few > millies later, when the session is still open??? Yes, it should be a rare case but there IS a possibility and also there may be bugs around there and they may throw the RuntimeException, such as NPE. > Yes, but your display logic should not handle errors coming from business > logic. That should always be done in the controller stack (action / > interceptors), or even underlying layers if apply. This simply means > moving error prone calls of the underlying layers to the controller, not > the view. While JPA / Hibernate gives you the opportunity of doing lazy > fetching of references (which is good, but very unique to ORM, but not to > other service providers), it is not always the best pattern have the > _view_ initialize the fetches you _know_ you will need... I understand your design preference. It is sometimes preferable to take easier design pattern such as dto pattern that never access db while view rendering. The code may become a bit more redundant but it should simplify the problem determination. But I still wonder why XWork swallows the system error/runtime excpetion if there is no meanig to do so. As I stated above, the automatic instance creation won't be destroyed. Any other concers to rethrow the system error/runtime exception to the upper layer? -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exception thrown in OGNL evaluation.
Hi Guys, I'm going to chime in in support of Ruimo Uno here. We have had problems with this too. This is not a design issue. At the end of the day, the view is calling a method and what that method does is largely irrelevant. It may throw an exception, even if you have carefully designed your application to make that unlikely. I agree that you do not want exception handling code in your views, but that isn't what we are talking about here. If a unexpected problem occurs that prevents the view from rendering properly, I don't want it handled, I want an exception thrown, eventually resulting in a 500 error. The problem is that the exception IS handled (by swallowing it). IMNSHO reacting to an exception by quietly failing to render a part of the view, and continuing on, is simply broken. cheers Perryn -Original Message- From: Ruimo Uno [mailto:[EMAIL PROTECTED] Sent: Monday, 20 August 2007 1:57 PM To: Struts Developers List Subject: Re: Exception thrown in OGNL evaluation. Hi, Rene, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > > You won't get NPE in this scenario. Ognl automatically create instance > > for you. I believe you know about this feature. > > > > Not when trying to read the property, only when applying values. The first > invocation with null foo object will cause OGNL to try to read the > property of the foo.name property and fail silently - no object will be > created. This will happen when then parameters interceptor tries to apply > values to the model (when invoking the save view) Hmm, I am not sure I fully understand what you mean but I also talking about applying the http request parameters into the model object. The automatic instance creation is done inside the OGNL and the code chage that I proposed in my first mail is not for OGNL but for XWork. You can still happily use this convenient feature even with my code change. > > Closing the session should be fixed as a design bug. I agree with you > > at this point. But in this case, the system should show an user > > friendly 'sorry page' so that the user can perform appropriate action. > > As we cannot take all bugs out of our system, need a sfety net. If > > there is a network problem between ap server and db server, lazy > > loading will fail by system error. > > but how could the fooService.getById(this.id), executed by the prepare or > action method succeed and the lazy reference getter fail just a few > millies later, when the session is still open??? Yes, it should be a rare case but there IS a possibility and also there may be bugs around there and they may throw the RuntimeException, such as NPE. > Yes, but your display logic should not handle errors coming from business > logic. That should always be done in the controller stack (action / > interceptors), or even underlying layers if apply. This simply means > moving error prone calls of the underlying layers to the controller, not > the view. While JPA / Hibernate gives you the opportunity of doing lazy > fetching of references (which is good, but very unique to ORM, but not to > other service providers), it is not always the best pattern have the > _view_ initialize the fetches you _know_ you will need... I understand your design preference. It is sometimes preferable to take easier design pattern such as dto pattern that never access db while view rendering. The code may become a bit more redundant but it should simplify the problem determination. But I still wonder why XWork swallows the system error/runtime excpetion if there is no meanig to do so. As I stated above, the automatic instance creation won't be destroyed. Any other concers to rethrow the system error/runtime exception to the upper layer? -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hold 2.0.10
Guys - In the thread "Re: Dojo 0.9 final. Time to migrate in S2?" I noticed that Musachy mentioned that the s2.1.x tags were dojo 0.4.2. Is this the case for the 2.0.x branch as well? If it is, I was doing some research, and came across the following:* "Dojo* 0.4.3 is now available to download. This is a security release. *Dojo* 0.4.1 and 0.4.2 users are strongly recommended to upgrade as soon as possible. 0.4.1 and 0.4.2 have a flaw in two files that could allow cross site scripting (*XSS*) attacks against your site if you do not upgrade." If this is the case, then I'll submit this issue and I think we should include it in the 2.0.10 release. /Ian
Re: Hold 2.0.10
+1 ! Ian Roughley schrieb: > Guys - > > In the thread "Re: Dojo 0.9 final. Time to migrate in S2?" I noticed > that Musachy mentioned that the s2.1.x tags were dojo 0.4.2. Is this > the case for the 2.0.x branch as well? > > If it is, I was doing some research, and came across the following:* > "Dojo* 0.4.3 is now available to download. This is a security release. > *Dojo* 0.4.1 and 0.4.2 users are strongly recommended to upgrade as soon > as possible. 0.4.1 and 0.4.2 have a flaw in two files that could allow > cross site scripting (*XSS*) attacks against your site if you do not > upgrade." > > If this is the case, then I'll submit this issue and I think we should > include it in the 2.0.10 release. > > /Ian > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
