You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2013/04/04 13:09:28 UTC
classloader resolution
Hi,
just created https://issues.apache.org/jira/browse/OWB-812
the issue is: how to get the right classloader for a Bean<?> when creating
a proxy.
ATM we use the bean class classloader but it will likely fail in a bunch of
JavaEE server and OSGi.
I thought to add a ClassLoaderResolverService (or sthg like it) or
(probably better) link a ClassLoader to each WebBeansContext
wdyt?
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
Re: classloader resolution
Posted by Romain Manni-Bucau <rm...@gmail.com>.
so the beanclass is a better default for JavaEE world (unusable in OSGi)
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/4/4 Joseph Bergmark <be...@gmail.com>
> I think the problem with using the TCCL all the time is that it will likely
> be the module classloader, but the class we are proxying could exist in a
> shared library of some form (ear/lib for example). That would mean the
> proxy class would end up defined in the different classloader than the
> class it is proxying and therefore it wouldn't be able to override package
> private methods.
>
>
> On Thu, Apr 4, 2013 at 9:32 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >wrote:
>
> > using TCCL sounds fine too
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/4/4 Joseph Bergmark <be...@gmail.com>
> >
> > > I like the idea of a flexible ClassLoaderResolverService, as long as
> can
> > > obtain the information about the bean class (if any) and interfaces.
> I'm
> > > not sure if just knowing the WebBeansContext is enough.
> > >
> > > For the old javassist proxies, one trick was using the bean class as
> long
> > > as that classloader also had visibility to the necessary proxy
> > > infrastructure classes (javassist.proxy.ProxyFactory I think was the
> key
> > > one). Otherwise I think we would fall back on using the TCCL which was
> > > normally the module classloader.
> > >
> > > I'm not familiar with the new proxy code, but I wonder if we have a
> > similar
> > > dependency.
> > >
> > >
> > > On Thu, Apr 4, 2013 at 7:09 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >wrote:
> > >
> > > > Hi,
> > > >
> > > > just created https://issues.apache.org/jira/browse/OWB-812
> > > >
> > > > the issue is: how to get the right classloader for a Bean<?> when
> > > creating
> > > > a proxy.
> > > >
> > > > ATM we use the bean class classloader but it will likely fail in a
> > bunch
> > > of
> > > > JavaEE server and OSGi.
> > > >
> > > > I thought to add a ClassLoaderResolverService (or sthg like it) or
> > > > (probably better) link a ClassLoader to each WebBeansContext
> > > >
> > > > wdyt?
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > >
> >
>
Re: classloader resolution
Posted by Joseph Bergmark <be...@gmail.com>.
I think the problem with using the TCCL all the time is that it will likely
be the module classloader, but the class we are proxying could exist in a
shared library of some form (ear/lib for example). That would mean the
proxy class would end up defined in the different classloader than the
class it is proxying and therefore it wouldn't be able to override package
private methods.
On Thu, Apr 4, 2013 at 9:32 AM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> using TCCL sounds fine too
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/4/4 Joseph Bergmark <be...@gmail.com>
>
> > I like the idea of a flexible ClassLoaderResolverService, as long as can
> > obtain the information about the bean class (if any) and interfaces. I'm
> > not sure if just knowing the WebBeansContext is enough.
> >
> > For the old javassist proxies, one trick was using the bean class as long
> > as that classloader also had visibility to the necessary proxy
> > infrastructure classes (javassist.proxy.ProxyFactory I think was the key
> > one). Otherwise I think we would fall back on using the TCCL which was
> > normally the module classloader.
> >
> > I'm not familiar with the new proxy code, but I wonder if we have a
> similar
> > dependency.
> >
> >
> > On Thu, Apr 4, 2013 at 7:09 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >wrote:
> >
> > > Hi,
> > >
> > > just created https://issues.apache.org/jira/browse/OWB-812
> > >
> > > the issue is: how to get the right classloader for a Bean<?> when
> > creating
> > > a proxy.
> > >
> > > ATM we use the bean class classloader but it will likely fail in a
> bunch
> > of
> > > JavaEE server and OSGi.
> > >
> > > I thought to add a ClassLoaderResolverService (or sthg like it) or
> > > (probably better) link a ClassLoader to each WebBeansContext
> > >
> > > wdyt?
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > http://rmannibucau.wordpress.com/>
> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > *Github: https://github.com/rmannibucau*
> > >
> >
>
Re: classloader resolution
Posted by Romain Manni-Bucau <rm...@gmail.com>.
using TCCL sounds fine too
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/4/4 Joseph Bergmark <be...@gmail.com>
> I like the idea of a flexible ClassLoaderResolverService, as long as can
> obtain the information about the bean class (if any) and interfaces. I'm
> not sure if just knowing the WebBeansContext is enough.
>
> For the old javassist proxies, one trick was using the bean class as long
> as that classloader also had visibility to the necessary proxy
> infrastructure classes (javassist.proxy.ProxyFactory I think was the key
> one). Otherwise I think we would fall back on using the TCCL which was
> normally the module classloader.
>
> I'm not familiar with the new proxy code, but I wonder if we have a similar
> dependency.
>
>
> On Thu, Apr 4, 2013 at 7:09 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >wrote:
>
> > Hi,
> >
> > just created https://issues.apache.org/jira/browse/OWB-812
> >
> > the issue is: how to get the right classloader for a Bean<?> when
> creating
> > a proxy.
> >
> > ATM we use the bean class classloader but it will likely fail in a bunch
> of
> > JavaEE server and OSGi.
> >
> > I thought to add a ClassLoaderResolverService (or sthg like it) or
> > (probably better) link a ClassLoader to each WebBeansContext
> >
> > wdyt?
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
>
Re: classloader resolution
Posted by Joseph Bergmark <be...@gmail.com>.
I like the idea of a flexible ClassLoaderResolverService, as long as can
obtain the information about the bean class (if any) and interfaces. I'm
not sure if just knowing the WebBeansContext is enough.
For the old javassist proxies, one trick was using the bean class as long
as that classloader also had visibility to the necessary proxy
infrastructure classes (javassist.proxy.ProxyFactory I think was the key
one). Otherwise I think we would fall back on using the TCCL which was
normally the module classloader.
I'm not familiar with the new proxy code, but I wonder if we have a similar
dependency.
On Thu, Apr 4, 2013 at 7:09 AM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> Hi,
>
> just created https://issues.apache.org/jira/browse/OWB-812
>
> the issue is: how to get the right classloader for a Bean<?> when creating
> a proxy.
>
> ATM we use the bean class classloader but it will likely fail in a bunch of
> JavaEE server and OSGi.
>
> I thought to add a ClassLoaderResolverService (or sthg like it) or
> (probably better) link a ClassLoader to each WebBeansContext
>
> wdyt?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>