FAQ
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

Search Discussions

  • Werner Punz at May 1, 2008 at 10:20 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriesmyfaces
postedApr 30, '08 at 11:33a
activeMay 1, '08 at 10:20a
posts2
users1
websitemyfaces.apache.org

1 user in discussion

Werner Punz: 2 posts

People

Translate

site design / logo © 2019 Grokbase