Re: ExtensionsFilter does not seem to be THREAD SAFE (Again Urgent!!)

[Mario Ivankovits <ma...@ops.co.at>]

Hi!

Sorry for all my "urgent" mails, but I address them so only if I really
think it IS urgent. ;-)

> Yes, that is true.
>   
This turned out to be a serious problem here.

Not only the java.lang.StringIndexOutOfBoundsException problem, but also
that it might deliver the content of another request in another session.

This is due to the fact that the response buffer will be passed into
DefaultAddResource which stores it in a member "originalResponse".
At this moment it is possible that another request for the same context
will pick up this content.

And guess what, this is what we have here 3-5 times the day.

Looking in DefaultAddResource makes me wonder why it has to be a context
singleton?
It is a rather lightweight class and it should be not that a performance
loss if we simple instantiate it per request.
Also we can get rid of the request attributes like HEADER_BEGIN_INFO....
as then the whole class is request scoped.

If it is due to the fact that it is hard to find the correct constructor
I'll propose to add a setContextPath(String) to the AddResource interface.
That way we can use the default constructor and simply set the context path.

After "green light" from you I'll do it that way.

Ciao,
Mario

Re: ExtensionsFilter does not seem to be THREAD SAFE (Again Urgent!!)

[Martin Marinschek <ma...@gmail.com>]

+1

regards,

Martin

On 2/23/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> Sorry for all my "urgent" mails, but I address them so only if I really
> think it IS urgent. ;-)
>
> > Yes, that is true.
> >
> This turned out to be a serious problem here.
>
> Not only the java.lang.StringIndexOutOfBoundsException problem, but also
> that it might deliver the content of another request in another session.
>
> This is due to the fact that the response buffer will be passed into
> DefaultAddResource which stores it in a member "originalResponse".
> At this moment it is possible that another request for the same context
> will pick up this content.
>
> And guess what, this is what we have here 3-5 times the day.
>
> Looking in DefaultAddResource makes me wonder why it has to be a context
> singleton?
> It is a rather lightweight class and it should be not that a performance
> loss if we simple instantiate it per request.
> Also we can get rid of the request attributes like HEADER_BEGIN_INFO....
> as then the whole class is request scoped.
>
> If it is due to the fact that it is hard to find the correct constructor
> I'll propose to add a setContextPath(String) to the AddResource interface.
> That way we can use the default constructor and simply set the context path.
>
> After "green light" from you I'll do it that way.
>
> Ciao,
> Mario
>
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces