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.
SHALE-409 fix
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.
