You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Vincent Tencé <Vi...@gemplus.com> on 2002/02/13 00:02:40 UTC
ExclaliburComponentManager
Hi everybody,
I'm new to the world of Avalon and have some questions regarding
ExcaliburComponentManager.
But first a quick introduction.
We are currently developping web server applications that we run in Tomcat
(the version I used
at the moment is 3.2.3, I might jump to 4.x soon). I have been looking to
the Avalon framework
for about a month and I introduced it to my team of developers.
So far I am very happy with the results! It's a way to enforce usage of best
practises and patterns
in our work and we can leverage the work that has been put into Avalon. Thx
for that.
We are learning a lot from the code we use and we can feel the benefits of
using patterns like IoC and SoC.
Now the problem :-) and the question. Somehow with Tomcat (maybe only 3.2.3)
the context class loader
cannot find my classes so we have to use getClass().getClassLoader(). It's
an issue since in a lot
of the excalibur code the context class loader is used by default.
I guess there are workarounds, and we had to think of one for
ExcaliburComponentSelector. We want
to use a selector in our roles.xml file but ExcaliburComponentSelector
cannot find any classes of the
webapp.
So we overrided ExcaliburComponentManager like this (not very clean) and
used that class instead:
public class DefaultComponentSelector extends ExcaliburComponentSelector {
private static Class clazz;
static {
clazz = new HackClass().getClass();
}
public DefaultComponentSelector() {
super(clazz.getClassLoader());
}
private static class HackClass {
}
}
I wanted to know I you have also experienced that problem when using Avalon
with servlet containers.
Is it a tomcat issue? I am not very familiar with class loader issues. Is
there a better way
to get the same result than the hack code above? What is the preferred way
of doing things here?
Btw, I guess there is mistake in the paper Developping with Apache Avalon at
bottom of page 39 (pdf format).
There is an example of an xml configuration file and it says that when you
have multiple instances
of a component you specify the instance name with the "hint" keyword but the
code is expecting "name" instead.
Thanks for your answers,
Vincent
Hope everybody will understand my English :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExclaliburComponentManager
Posted by Vincent Tencé <Vi...@gemplus.com>.
You're right. Thx.
I just run some tests with Catalina, and the problem doesn't occur. So I
guess
the context class loader is set properly in Tomcat 4.0.1. This fixes the
problem.
Thx for your help.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 11:07 AM
> To: Avalon Developers List
> Subject: Re: ExclaliburComponentManager
>
>
> Vincent Tencé wrote:
> > Unfortunatly
> >
> >
> >>super(this.getClass().getClassLoader());
> >>
> >
> > doesn't work cause It seems I cannot call getClass() before
> the super
> > constructor returns :-/
>
> You can do it through the static method:
>
> ComponentManager.class.getClassLoader();
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Tencé wrote:
> Unfortunatly
>
>
>>super(this.getClass().getClassLoader());
>>
>
> doesn't work cause It seems I cannot call getClass() before the super
> constructor returns :-/
You can do it through the static method:
ComponentManager.class.getClassLoader();
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExclaliburComponentManager
Posted by Vincent Tencé <Vi...@gemplus.com>.
Unfortunatly
> super(this.getClass().getClassLoader());
doesn't work cause It seems I cannot call getClass() before the super
constructor returns :-/
Vincent
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 9:33 AM
> To: Avalon Developers List
> Subject: Re: ExclaliburComponentManager
>
>
> Vincent Tencé wrote:
>
>
> <snip/>
>
>
> > So far I am very happy with the results! It's a way to
> enforce usage of best
> > practises and patterns
> > in our work and we can leverage the work that has been put
> into Avalon. Thx
> > for that.
> > We are learning a lot from the code we use and we can feel
> the benefits of
> > using patterns like IoC and SoC.
>
> Glad to hear it.
>
> >
> > Now the problem :-) and the question. Somehow with Tomcat
> (maybe only 3.2.3)
> > the context class loader
> > cannot find my classes so we have to use
> getClass().getClassLoader(). It's
> > an issue since in a lot
> > of the excalibur code the context class loader is used by default.
>
> This has to do with actually setting the ContextClassloader.
> Cocoon handles this
> in the Servlet's service() method by explicitly calling
>
> Thread.currentThread().setContextClassLoader(this.classloader);
>
> with every request (handles new threads that are introduced.
>
>
>
> > I guess there are workarounds, and we had to think of one for
> > ExcaliburComponentSelector. We want
> > to use a selector in our roles.xml file but
> ExcaliburComponentSelector
> > cannot find any classes of the
> > webapp.
> > So we overrided ExcaliburComponentManager like this (not
> very clean) and
> > used that class instead:
> >
> > public class DefaultComponentSelector extends
> ExcaliburComponentSelector {
> >
> > private static Class clazz;
> >
> > static {
> > clazz = new HackClass().getClass();
> > }
> >
> > public DefaultComponentSelector() {
> > super(clazz.getClassLoader());
> > }
> >
> > private static class HackClass {
> > }
> > }
>
>
> You can also do this:
>
> super(this.getClass().getClassLoader());
>
> That works as well.
>
>
>
>
> > I wanted to know I you have also experienced that problem
> when using Avalon
> > with servlet containers.
> > Is it a tomcat issue? I am not very familiar with class
> loader issues. Is
> > there a better way
> > to get the same result than the hack code above? What is
> the preferred way
> > of doing things here?
> >
> > Btw, I guess there is mistake in the paper Developping with
> Apache Avalon at
> > bottom of page 39 (pdf format).
> > There is an example of an xml configuration file and it
> says that when you
> > have multiple instances
> > of a component you specify the instance name with the
> "hint" keyword but the
> > code is expecting "name" instead.
> >
> > Thanks for your answers,
> > Vincent
> >
> > Hope everybody will understand my English :)
>
>
> Hopefully my answers helped you :)
>
>
> --
>
> "They that give up essential liberty to obtain a little
> temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Tencé wrote:
<snip/>
> So far I am very happy with the results! It's a way to enforce usage of best
> practises and patterns
> in our work and we can leverage the work that has been put into Avalon. Thx
> for that.
> We are learning a lot from the code we use and we can feel the benefits of
> using patterns like IoC and SoC.
Glad to hear it.
>
> Now the problem :-) and the question. Somehow with Tomcat (maybe only 3.2.3)
> the context class loader
> cannot find my classes so we have to use getClass().getClassLoader(). It's
> an issue since in a lot
> of the excalibur code the context class loader is used by default.
This has to do with actually setting the ContextClassloader. Cocoon handles this
in the Servlet's service() method by explicitly calling
Thread.currentThread().setContextClassLoader(this.classloader);
with every request (handles new threads that are introduced.
> I guess there are workarounds, and we had to think of one for
> ExcaliburComponentSelector. We want
> to use a selector in our roles.xml file but ExcaliburComponentSelector
> cannot find any classes of the
> webapp.
> So we overrided ExcaliburComponentManager like this (not very clean) and
> used that class instead:
>
> public class DefaultComponentSelector extends ExcaliburComponentSelector {
>
> private static Class clazz;
>
> static {
> clazz = new HackClass().getClass();
> }
>
> public DefaultComponentSelector() {
> super(clazz.getClassLoader());
> }
>
> private static class HackClass {
> }
> }
You can also do this:
super(this.getClass().getClassLoader());
That works as well.
> I wanted to know I you have also experienced that problem when using Avalon
> with servlet containers.
> Is it a tomcat issue? I am not very familiar with class loader issues. Is
> there a better way
> to get the same result than the hack code above? What is the preferred way
> of doing things here?
>
> Btw, I guess there is mistake in the paper Developping with Apache Avalon at
> bottom of page 39 (pdf format).
> There is an example of an xml configuration file and it says that when you
> have multiple instances
> of a component you specify the instance name with the "hint" keyword but the
> code is expecting "name" instead.
>
> Thanks for your answers,
> Vincent
>
> Hope everybody will understand my English :)
Hopefully my answers helped you :)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 13 Feb 2002 10:02, Vincent Tencé wrote:
>
>>I wanted to know I you have also experienced that problem when using Avalon
>>with servlet containers.
>>Is it a tomcat issue? I am not very familiar with class loader issues. Is
>>there a better way
>>to get the same result than the hack code above? What is the preferred way
>>of doing things here?
>>
>
> If the avalon jars are in the webapps lib dir (ie
> myapp/WEB-INF/lib/avalon-*.jar) then in theory you should be fine. Your
> servlet container *should* set the context classloader - if it doesn't then
> it is probably buggy.
>
> However if you keep your jars in other places (like in the servlet engines
> common directory or something) then I would expect to see the behaviour you
> describe.
>
> Could you describe where you are placing avalon jars and where the code that
> uses them is placed.
>
>
>
>>Btw, I guess there is mistake in the paper Developping with Apache Avalon
>>at bottom of page 39 (pdf format).
>>There is an example of an xml configuration file and it says that when you
>>have multiple instances
>>of a component you specify the instance name with the "hint" keyword but
>>the code is expecting "name" instead.
>>
>
> Berin - do you wanna pick this up.
I'll apply the patch.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExclaliburComponentManager
Posted by Vincent Tencé <Vi...@gemplus.com>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Wednesday, February 13, 2002 3:11 AM
> To: Avalon Developers List
> Subject: Re: ExclaliburComponentManager
>
> ....
>
> If the avalon jars are in the webapps lib dir (ie
> myapp/WEB-INF/lib/avalon-*.jar) then in theory you should be
> fine. Your
> servlet container *should* set the context classloader - if
> it doesn't then
> it is probably buggy.
>
So apparently Tomcat 3.2.3 does not do it. I'll follow Berin suggestions and will try
Thread.currentThread().setContextClassLoader(this.classloader);
in my FrontComponent servlet service method, so I can get rid of the hack.
> However if you keep your jars in other places (like in the
> servlet engines
> common directory or something) then I would expect to see the
> behaviour you
> describe.
>
> Could you describe where you are placing avalon jars and
> where the code that
> uses them is placed.
They are placed in my web app lib dir, not in tomcat lib dir.
Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Peter Donald <pe...@apache.org>.
On Wed, 13 Feb 2002 10:02, Vincent Tencé wrote:
> I wanted to know I you have also experienced that problem when using Avalon
> with servlet containers.
> Is it a tomcat issue? I am not very familiar with class loader issues. Is
> there a better way
> to get the same result than the hack code above? What is the preferred way
> of doing things here?
If the avalon jars are in the webapps lib dir (ie
myapp/WEB-INF/lib/avalon-*.jar) then in theory you should be fine. Your
servlet container *should* set the context classloader - if it doesn't then
it is probably buggy.
However if you keep your jars in other places (like in the servlet engines
common directory or something) then I would expect to see the behaviour you
describe.
Could you describe where you are placing avalon jars and where the code that
uses them is placed.
> Btw, I guess there is mistake in the paper Developping with Apache Avalon
> at bottom of page 39 (pdf format).
> There is an example of an xml configuration file and it says that when you
> have multiple instances
> of a component you specify the instance name with the "hint" keyword but
> the code is expecting "name" instead.
Berin - do you wanna pick this up.
--
Cheers,
Pete
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>