RE: Any one plans to fix SHALE-409 bug?
I think that the second loop is needed when using Shale Tiger so I think
is better put this code in shale-tiger.jar. In this way, developer (like
me) not using tiger extension does not need it.
Are u agree?
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: 26 giugno 2007 05.38
To: dev@shale.apache.org
Subject: 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.ge
tValue())) {
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.
>
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/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
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: 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
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 .. 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. 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: Shale - Release
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 <[EMAIL PROTECTED]> 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. > 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. 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 :-). 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
Re: Shale - Release
On 6/25/07, Greg Reddin <[EMAIL PROTECTED]> wrote: 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. Makes sense to me. Additionally, if as Gary alluded to, there are limited new features for JSF 1.1 (to shift focus to 1.2) then scenario C might not be too bad either (sorry, its snipped out here) since the major differences between current trunk and v1.0.x branch in the dialog modules seem to be working as intended (so IMO they can be folded into one without too much risk). I should have mentioned that in my mind the last line of development (highest Shale version numbers) in all scenarios corresponded to trunk (so in all cases is JSF 1.2, to Gary's point). -Rahul Greg
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
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.
