RE: SHALE-409 fix
Any news about the fix? -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: 23 maggio 2007 22.44 To: user@shale.apache.org Subject: Re: SHALE-409 fix From: Craig McClanahan [EMAIL PROTECTED] On 5/23/07, Gary VanMatre wrote: From: Craig McClanahan On 5/23/07, Gary VanMatre wrote: From: Torsten Krah [EMAIL PROTECTED] The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. I'm thinking that we could just remove that bit of logic because the web container should fire the ServletRequestListener [1] regardless? It will indeed get called later, but outside the JSF lifecycle ... which means you would not be able to get to the FacesContext in a destroy() method. That's why this logic was inserted in the first place. Ah, I figured there was good reason. What if we delegated to the tiger LifecycleListener from the JSF phase listener - same pattern? // Delegate to the Tiger Extensions instance if it exists LifecycleListener tiger = tiger(); if (tiger != null) { tiger.contextDestroyed(event); } private LifecycleListener tiger() ... At first blush this looks good, but I'm heads down getting ready for a trip to India next week, so I won't be able to actually play with this until the first week of June. Cool. I'll try to take a look this week. I don't have a Solaris box sitting around to test but I could make the change to the 1.1.0-SNAPSHOT and we could decide if we want to push it to the other branch later on. Craig Gary Craig Gary However, there might be a funky case that resulted in this logic in the PhaseListener - not sure. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/j ava/org/ apache/shale/view/faces/LifecycleListener.java?view=markup Torsten Gary -- Forwarded message -- From: Torsten Krah To: user@shale.apache.org Date: Wed, 23 May 2007 19:11:48 + Subject: Re: SHALE-409 fix The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. Torsten Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb [EMAIL PROTECTED]: Please fix the bug SHALE-409. Regards Mario Buonopane This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: SHALE-409 fix
The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. Torsten Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb [EMAIL PROTECTED]: Please fix the bug SHALE-409. Regards Mario Buonopane This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. smime.p7s Description: S/MIME cryptographic signature
Re: SHALE-409 fix
From: Torsten Krah [EMAIL PROTECTED] The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. I'm thinking that we could just remove that bit of logic because the web container should fire the ServletRequestListener [1] regardless? However, there might be a funky case that resulted in this logic in the PhaseListener - not sure. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/LifecycleListener.java?view=markup Torsten Gary---BeginMessage--- The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. Torsten Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb [EMAIL PROTECTED]: Please fix the bug SHALE-409. Regards Mario Buonopane This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. smime.p7s Description: S/MIME cryptographic signature ---End Message---
Re: SHALE-409 fix
On 5/23/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Torsten Krah [EMAIL PROTECTED] The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. I'm thinking that we could just remove that bit of logic because the web container should fire the ServletRequestListener [1] regardless? It will indeed get called later, but outside the JSF lifecycle ... which means you would not be able to get to the FacesContext in a destroy() method. That's why this logic was inserted in the first place. Craig However, there might be a funky case that resulted in this logic in the PhaseListener - not sure. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/LifecycleListener.java?view=markup Torsten Gary -- Forwarded message -- From: Torsten Krah [EMAIL PROTECTED] To: user@shale.apache.org Date: Wed, 23 May 2007 19:11:48 + Subject: Re: SHALE-409 fix The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. Torsten Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb [EMAIL PROTECTED]: Please fix the bug SHALE-409. Regards Mario Buonopane This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: SHALE-409 fix
On 5/23/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Craig McClanahan [EMAIL PROTECTED] On 5/23/07, Gary VanMatre wrote: From: Torsten Krah [EMAIL PROTECTED] The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. I'm thinking that we could just remove that bit of logic because the web container should fire the ServletRequestListener [1] regardless? It will indeed get called later, but outside the JSF lifecycle ... which means you would not be able to get to the FacesContext in a destroy() method. That's why this logic was inserted in the first place. Ah, I figured there was good reason. What if we delegated to the tiger LifecycleListener from the JSF phase listener - same pattern? // Delegate to the Tiger Extensions instance if it exists LifecycleListener tiger = tiger(); if (tiger != null) { tiger.contextDestroyed(event); } private LifecycleListener tiger() ... At first blush this looks good, but I'm heads down getting ready for a trip to India next week, so I won't be able to actually play with this until the first week of June. Craig Craig Gary However, there might be a funky case that resulted in this logic in the PhaseListener - not sure. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/ apache/shale/view/faces/LifecycleListener.java?view=markup Torsten Gary -- Forwarded message -- From: Torsten Krah To: user@shale.apache.org Date: Wed, 23 May 2007 19:11:48 + Subject: Re: SHALE-409 fix The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. Torsten Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb [EMAIL PROTECTED]: Please fix the bug SHALE-409. Regards Mario Buonopane This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: SHALE-409 fix
From: Craig McClanahan [EMAIL PROTECTED] On 5/23/07, Gary VanMatre wrote: From: Craig McClanahan On 5/23/07, Gary VanMatre wrote: From: Torsten Krah [EMAIL PROTECTED] The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. I'm thinking that we could just remove that bit of logic because the web container should fire the ServletRequestListener [1] regardless? It will indeed get called later, but outside the JSF lifecycle ... which means you would not be able to get to the FacesContext in a destroy() method. That's why this logic was inserted in the first place. Ah, I figured there was good reason. What if we delegated to the tiger LifecycleListener from the JSF phase listener - same pattern? // Delegate to the Tiger Extensions instance if it exists LifecycleListener tiger = tiger(); if (tiger != null) { tiger.contextDestroyed(event); } private LifecycleListener tiger() ... At first blush this looks good, but I'm heads down getting ready for a trip to India next week, so I won't be able to actually play with this until the first week of June. Cool. I'll try to take a look this week. I don't have a Solaris box sitting around to test but I could make the change to the 1.1.0-SNAPSHOT and we could decide if we want to push it to the other branch later on. Craig Gary Craig Gary However, there might be a funky case that resulted in this logic in the PhaseListener - not sure. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/ apache/shale/view/faces/LifecycleListener.java?view=markup Torsten Gary -- Forwarded message -- From: Torsten Krah To: user@shale.apache.org Date: Wed, 23 May 2007 19:11:48 + Subject: Re: SHALE-409 fix The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. Torsten Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb [EMAIL PROTECTED]: Please fix the bug SHALE-409. Regards Mario Buonopane This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
RE: SHALE-409 fix
Antonio, can i? Looking to http://issues.apache.org/struts/browse/SHALE-409 seems to be present the solution. What can I do to write the patch? -Original Message- From: Antonio Petrelli [mailto:[EMAIL PROTECTED] Sent: 22 maggio 2007 15.48 To: user@shale.apache.org Subject: Re: SHALE-409 fix 2007/5/22, [EMAIL PROTECTED] [EMAIL PROTECTED]: Please fix the bug SHALE-409. If you want it fixed, why don't you write a patch? Antonio This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: SHALE-409 fix
2007/5/22, [EMAIL PROTECTED] [EMAIL PROTECTED]: Antonio, can i? Looking to http://issues.apache.org/struts/browse/SHALE-409 seems to be present the solution. What can I do to write the patch? With write I meant modify your local version, export a diff file and post the newly created patch. If you post this patch, not only the community will be happy, but most probably the issue will be fixed in a shorter time than the ones without patches. In conclusion, modify your local version and see if it works. In affirmative case, create a diff file (through the use of svn diff) and post it to the issue page itself. Antonio
RE: SHALE-409 fix
Antonio, I have tested the patch suggested by Matt Hughes at http://issues.apache.org/struts/browse/SHALE-409. And does work. I have modified the private method afterRenderResponse of ViewPhaseListener class: private void afterRenderResponse(PhaseEvent event) { // Initialize local values we will need Map map = event.getFacesContext().getExternalContext().getRequestMap(); // Remove our list of initialized views explicitly map.remove(FacesConstants.VIEWS_INITIALIZED); List list = new ArrayList(); Iterator entries = map.entrySet().iterator(); // First select all the ViewController and AbstractRequestBean instances while (entries.hasNext()) { Map.Entry entry = (Map.Entry) entries.next(); if ((entry.getValue() instanceof ViewController) || (entry.getValue() instanceof AbstractRequestBean)) { list.add(entry.getKey()); } } // Second select all remaining instances, which will include annotated // managed beans if Shale Tiger is present /* COMMENTED BY BUONOPANE entries = map.entrySet().iterator(); while (entries.hasNext()) { Map.Entry entry = (Map.Entry) entries.next(); if (!list.contains(entry.getKey())) { list.add(entry.getKey()); } }*/ // Iterate through the keys in the specified order, removing the // corresponding request scope attribute instances Iterator keys = list.iterator(); while (keys.hasNext()) { String key = (String) keys.next(); try { log.info( removing +key); map.remove(key); } catch (Exception e) { handleException(event.getFacesContext(), e); } } } I have just commented the line the second loop identified by the string COMMENTED BY BUONOPANE. As you can see I also have logged the key of the objects removed and following are the keys deleted by the original version: removing __acegi_session_integration_filter_applied removing dialog removing org$apache$shale$view$VIEW_POSTBACK removing org.apache.myfaces.myFacesJavascript removing com.ibm.websphere.servlet.uri_non_decoded removing __acegi_filterSecurityInterceptor_filterApplied removing removing generic removing t removing org.apache.myfaces.calendar.JAVASCRIPT_ENCODED removing bundle removing org.apache.shale.view.PHASE_ID removing com.sun.faces.FORM_CLIENT_ID_ATTR removing class org.apache.myfaces.shared_tomahawk.renderkit.html.util.JavascriptUtils.O LD_VIEW_ID removing ricerche$ricercaPolizzePage removing org.apache.struts.taglib.tiles.CompContext removing org.apache.myfaces.application.jsp.JspStateManagerImpl.RESTORED_SERIALIZ ED_VIEW removing org.apache.myfaces.config.beansUnderConstruction removing javax.faces.webapp.UIComponentTag.UNIQUE_ID_COUNTER removing org.apache.myfaces.AddResourceFactory.CACHE_MAP_KEY removing org.apache.myfaces.component.html.util.ExtensionFilter.doFilterCalled removing org.apache.myfaces.inputTextHelp.JAVASCRIPT_ENCODED removing jsf_sequence removing com.ibm.servlet.engine.webapp.dispatch_type The problem is that I don't understand the second loop commented so I can just comment it. What do you think? Mario -Original Message- From: Antonio Petrelli [mailto:[EMAIL PROTECTED] Sent: 22 maggio 2007 15.59 To: user@shale.apache.org Subject: Re: SHALE-409 fix 2007/5/22, [EMAIL PROTECTED] [EMAIL PROTECTED]: Antonio, can i? Looking to http://issues.apache.org/struts/browse/SHALE-409 seems to be present the solution. What can I do to write the patch? With write I meant modify your local version, export a diff file and post the newly created patch. If you post this patch, not only the community will be happy, but most probably the issue will be fixed in a shorter time than the ones without patches. In conclusion, modify your local version and see if it works. In affirmative case, create a diff file (through the use of svn diff) and post it to the issue page itself. Antonio This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.