Any one plans to fix SHALE-409 bug?

View: New views
4 Messages — Rating Filter:   Alert me  

Any one plans to fix SHALE-409 bug?

by mario.buonopane :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

 

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.

Parent Message unknown Re: Any one plans to fix SHALE-409 bug?

by Gary%20VanMatre :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>From: <mario.buonopane@...>
>
>
>
> 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: Any one plans to fix SHALE-409 bug?

by mario.buonopane :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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:gvanmatre@...]
Sent: 26 giugno 2007 05.38
To: dev@...
Subject: Re: Any one plans to fix SHALE-409 bug?

>From: <mario.buonopane@...>
>
>
>
> 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.

Parent Message unknown RE: Any one plans to fix SHALE-409 bug?

by Gary%20VanMatre :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>From: <mario.buonopane@...>
>
> 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?
>


Yeah, the ViewControllerCallbacks2 class  is in the tiger library and overrides
behavior in the view library.



>
>
>
> -----Original Message-----
> From: Gary VanMatre [mailto:gvanmatre@...]
> Sent: 26 giugno 2007 05.38
> To: dev@...
> Subject: Re: Any one plans to fix SHALE-409 bug?
>
> >From:
> >
> >
> >
> > 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.