You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/06/06 10:10:27 UTC
[RT] Per sitemap classloading and ClassLoaderFactory
In 2.2 we have the nice feature to have a class loader on a per sitemap
base. This allows to load classes just for this sitemap (and all sub
sitemaps).
Now, the implementation - the SitemapLanguage - uses a global
component, the ClassLoaderFactory to get the per sitemap classloader.
Current we only have on implementation and even if we had different
implementations, you can only configure one classloader factory for the
whole cocoon instance.
For my own application I want to use an own classloader for a specific
sitemap - which is not possible today.
So what do you think about removing the (avalon) component
ClassLoaderFactory and make the class loader factory configurable on a
per sitemap base. Then you can define the class for the factory on the
components section:
<map:components classloader-factory-class="..."/>
If this attribute is missing we use the default which is the
DefaultClassLoaderFactory.
WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Per sitemap classloading and ClassLoaderFactory
Posted by Carsten Ziegeler <cz...@apache.org>.
Ok, as it seems that noone has a better idea I will make the role used
to get the class loader factory configurable.
Carsten
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>Can you elaborate on your use case?
>>
>
> I can try :) I don't have a clear concept right now. All I want to do is
> to scan the classpath defined for the sitemap for some specific classes
> (or perhaps resources - don't know yet). If these classes implement a
> specific interface an instance of this class is created and registered.
> Something along these lines.
>
>
>>Hmm... since this class has to be defined by a higher-level classloader,
>>what about allowing different implementations for the
>>ClassLoaderFactory, i.e. using a role rather than a class name?
>
>
> Ah, ok, I see, we have a chicken/egg problem here. Now, my idea was that
> the classloader resides in the classpath defined for the sitemap which
> wouldn't work. Hmpf. Ok, a role would work as well.
> Hmm, I'm not happy with that solution. My idea was that this mechanism
> is independent and the sitemap directory contains everything required to
> handle this, including the own classloader class. Do you see any
> possible solution for this?
>
>
>>Also, it seems to me this property belongs more to <map:classpath>
>>rather than <map:components>.
>>
>
> Oh, you're right. Sure!
>
> Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Per sitemap classloading and ClassLoaderFactory
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Can you elaborate on your use case?
>
I can try :) I don't have a clear concept right now. All I want to do is
to scan the classpath defined for the sitemap for some specific classes
(or perhaps resources - don't know yet). If these classes implement a
specific interface an instance of this class is created and registered.
Something along these lines.
>
> Hmm... since this class has to be defined by a higher-level classloader,
> what about allowing different implementations for the
> ClassLoaderFactory, i.e. using a role rather than a class name?
Ah, ok, I see, we have a chicken/egg problem here. Now, my idea was that
the classloader resides in the classpath defined for the sitemap which
wouldn't work. Hmpf. Ok, a role would work as well.
Hmm, I'm not happy with that solution. My idea was that this mechanism
is independent and the sitemap directory contains everything required to
handle this, including the own classloader class. Do you see any
possible solution for this?
>
> Also, it seems to me this property belongs more to <map:classpath>
> rather than <map:components>.
>
Oh, you're right. Sure!
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Per sitemap classloading and ClassLoaderFactory
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>In 2.2 we have the nice feature to have a class loader on a per sitemap
>base. This allows to load classes just for this sitemap (and all sub
>sitemaps).
>Now, the implementation - the SitemapLanguage - uses a global
>component, the ClassLoaderFactory to get the per sitemap classloader.
>Current we only have on implementation and even if we had different
>implementations, you can only configure one classloader factory for the
>whole cocoon instance.
>
>For my own application I want to use an own classloader for a specific
>sitemap - which is not possible today.
>
>
Can you elaborate on your use case?
>So what do you think about removing the (avalon) component
>ClassLoaderFactory and make the class loader factory configurable on a
>per sitemap base. Then you can define the class for the factory on the
>components section:
><map:components classloader-factory-class="..."/>
>
>If this attribute is missing we use the default which is the
>DefaultClassLoaderFactory.
>
>
Hmm... since this class has to be defined by a higher-level classloader,
what about allowing different implementations for the
ClassLoaderFactory, i.e. using a role rather than a class name?
Also, it seems to me this property belongs more to <map:classpath>
rather than <map:components>.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Per sitemap classloading and ClassLoaderFactory
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 juin 05, à 10:10, Carsten Ziegeler a écrit :
> Then you can define the class for the factory on the
> components section:
> <map:components classloader-factory-class="..."/>
>
> If this attribute is missing we use the default which is the
> DefaultClassLoaderFactory....
I don't know this part of the code in much detail, but this sounds like
a good idea:
+1
-Bertrand