Any one plans to fix SHALE-409 bug?
I have successfully tested to comment the second loop:
// Second select all remaining instances, which will include
annotated
// managed beans if Shale Tiger is present
/*
entries = map.entrySet().iterator();
while (entries.hasNext()) {
Map.Entry entry = (Map.Entry) entries.next();
if (!list.contains(entry.getKey())) {
list.add(entry.getKey());
}
}*/
Is there any one can try it and plans to release the fix?
Can I help you?
Thanks in advance
Mario
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 - Release
On 6/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk I'd be happy with either of the above, perhaps some preference for A. It depends on the workload involved with upgrading to the 1.2 spec. If the load is heavy, A would be better. If it's lighter, B would be better. I wonder how many people are still using 1.1. We are currently still bound to it, but could upgrade without too much work, and probably will as soon as MyFaces 1.2 is released. Greg
Re: Shale - Release
I like A. I would prefer version 2.0 for JSF 1.2 because it allows more version flexibilty for the JSF 1.1. I am partial to a major release.minor release.maintaince release model where their is upward API compatibility within a major release, 1.1 to 1.2. Paul Spencer Rahul Akolkar wrote: On 6/22/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Greg Reddin [EMAIL PROTECTED] On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. snip/ shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? -Rahul
Re: Any one plans to fix SHALE-409 bug?
From: [EMAIL PROTECTED]
I have successfully tested to comment the second loop:
// Second select all remaining instances, which will include
annotated
// managed beans if Shale Tiger is present
/*
entries = map.entrySet().iterator();
while (entries.hasNext()) {
Map.Entry entry = (Map.Entry) entries.next();
if (!list.contains(entry.getKey())) {
list.add(entry.getKey());
}
}*/
Is there any one can try it and plans to release the fix?
The problem with commenting out this loop is that we might
break someone else's application. The second loop forces
the destroy method to be invoked for beans with the @Destroy
annotation before the response has completed and the faces
context released.
I've been looking at this one off and on. At first I thought we
could just invoke the LifecycleListener from the ViewPhaseListener
but we don't have ServletContextEvent there.
Another option might be to add a destroy method to the
ViewControllerCallbacks class. This utility bean is registered as
a managed bean. The tiger library overrides the registered bean
to look for the @Preprocess and @Prerender runtime method
annotations. The ViewControllerCallbacks2 class would inspect
for the @Destroy annotation or the other interfaces.
We could remove the second loop and modify the first to use the
ViewControllerCallbacks bean.
Consider:
// First select all the ViewController and AbstractRequestBean instances
while (entries.hasNext()) {
Map.Entry entry = (Map.Entry) entries.next();
if
(getViewControllerCallbacks(event.getFacesContext()).hasDestroy(entry.getValue()))
{
list.add(entry.getKey());
}
}
What do you think?
Can I help you?
Thanks in advance
Mario
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 - Release
From: Craig McClanahan [EMAIL PROTECTED] Sorry for the late response ... still catching up from a backlog due to being on the road for most of May. Comments below. On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Gary VanMatre wrote: From: Greg Reddin On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? My personal preference would be for scenario A over scenario B or C, but with a twist ... target the JSF 1.2 based stuff for a 2.x release series, rather than 1.1 or 1.2. Why? Because a redesign of the existing APIs to take JSF 1.2 into account (and therefore also become dependent on Java SE 5) is very likely to require some significant changes (just as one example, much of tiger basically goes away and becomes part of the core functionality in view and other places), so upping the major version number would be more appropriate. I'd like also like to see the annotation processor moved to the core with a pluggable way to register handlers. It seems silly to scan the classpath multiple times for each library that might have future annotations. Maybe a commons chain would be a good way to register annotation handlers? Version numbers aside, I would prefer A over B. We need to put out a new release anyway; the ease of use additions in the current trunk are modest but nice, and if we focused on just finishing 1.1 we might actually get a release out this year :-). +1 I don't like C -- we still want to have the *ability* to go back and do a 1.0.5 if some security problem or something rears its head; in the mean time, lets just get 1.1 done and out the door while we start talking about what the future might hold. And that starts from us (yes, me included :-) rolling up our sleeves and addressing the current issues in the trunk code -- and *perhaps* backporting bugfixes to the 1.0 branch, but that needn't be a priority. -Rahul Craig Gary
Re: Shale - Release
On 6/25/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Craig McClanahan [EMAIL PROTECTED] Sorry for the late response ... still catching up from a backlog due to being on the road for most of May. Comments below. On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Gary VanMatre wrote: From: Greg Reddin On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? My personal preference would be for scenario A over scenario B or C, but with a twist ... target the JSF 1.2 based stuff for a 2.x release series, rather than 1.1 or 1.2. Why? Because a redesign of the existing APIs to take JSF 1.2 into account (and therefore also become dependent on Java SE 5) is very likely to require some significant changes (just as one example, much of tiger basically goes away and becomes part of the core functionality in view and other places), so upping the major version number would be more appropriate. I'd like also like to see the annotation processor moved to the core with a pluggable way to register handlers. It seems silly to scan the classpath multiple times for each library that might have future annotations. Maybe a commons chain would be a good way to register annotation handlers? Silly it may be, the alternative seems to be everyone agreeing to use a common low level library to abstract away the very real differences between what kinds of annotations different projects would look for. That should work about as successfully as Commons Logging has :-). More seriously: * What is really important is a way to scan for runtime annotations that does not require loading all the classes in a way that runs all the static initializers. * It turns out that there is such a scheme to look at ... the Class.forName() variant of class loading (at least; hopefully there are others as well so you can do the discovery from a parent class loader) that does exactly this. Thanks to Bob Lee of Google for a pointer to look at this (which is the mechanism Google Guice uses). Craig
