Re: Question regarding the low levels of the servlet api/containers

[Werner Punz <we...@gmail.com>]

Never mind guys the servlet filter or maybe the phase
listener seems the only way to go
the problem seems to be that the classloader hierarchy seems to be 
refreshed periodically.

Werner



Werner Punz schrieb:
> Hia guys, this is not really off topic due to being myfaces related
> I am working on dynamic groovy code reloading in Myfaces
> just as Lubke has done lately in the RI.
> I have most of it up and running already, the groovy code reloading
> already works like a charm, a classloader also is in place which
> tries to solve it on the lowest level but
> I face one last issue, which I try to solve differently than Sun did.
> 
> I want to introduce the new groovy enabled reloading classloader
> als clean as possible into the running webapp.
> 
> Since I am not a total expert on this issue.
> What is the cleanest way to inject a classloader
> into an app servers webapp.
> 
> The classloader should replace the original context classloader
> and add its own behavior.
> I am currently thinking of a zero config if possible.
> So far I can see only following ways.
> 
> Configuration Tomcat has its own mechanism to introduce it into the
> context.xml, this seems to be tomcat only, and spring basically does the 
> same. If I do it I would break spring that way for people who need that 
> in spring.
> 
> Context listener. Now this is a different beast, if I do it there
> I run on certain ear containers into the situation that the context 
> classloader is not set while the context listener already is triggered, 
> you still can reach it, but if you then set your own classloader as 
> context classloader I am not sure how the containers react which have 
> exactly this issue.
> 
> Servlet filter: This could work but it introduces another configuration
> in the already overloaded web.xml.
> This is the way Lubke solved it according to his blog (I did not have a 
> look at the code since I do not want to copy anything codewise)
> 
> 
> Phase listener: Probably the best way due to zero config, but it would 
> introduce a dependency into JSF.
> And I want to have this stuff up and running outside of jsf as well
> I do not see to many dependencies which would enforce a JSF only solution.
> Besides that, it would, only work as soon as the jsf lifecycle is 
> triggered the first time (minor issue but still an issue)
> 
> I probably guess the best approach would be to use the phase listener
> for JSF and a filter approach for non jsf enviroments.
> If anyone knows how the EAR containers behave if you set your
> own classloader manually in a case of a context classloader being 
> returned as null, this might be an opion as well.
> 
> Does anyone have another idea how to achieve this?
> 
> Werner
> 
>