You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by David Jencks <da...@yahoo.com> on 2010/12/07 01:44:04 UTC
Classloaders and component boundaries
In geronimo we've been studying the ee platform spec section 8.3 and think that it's allowable to have a single classloader per ear, and we're currently implementing this (in geronimo 3). However the jsf spec requires that different web apps in an ear be distinguishable in the javax.faces.FactoryFinder. Currently myfaces' FactoryFinder distinguishes web apps by context classloader.
While there might be other possible solutions, I'd like to make the way FactoryFinder figures out what context it's in pluggable. The default implementation would continue to use the TCCL, and geronimo can install a system that relies on explicit notification from the container when component boundaries are crossed.
I've refactored the myfaces bit of this and it seems to work fine, but I'm still working on the geronimo part. However since a myfaces release seems imminent I'd like to get this proposal out for consideration and review ASAP. I've opened MYFACES-2995 and am attaching an initial patch for consideration.
thanks
david jencks
Re: Classloaders and component boundaries
Posted by David Jencks <da...@yahoo.com>.
Hi,
It's a month later, holidays are over, I'd like to ask again that this be considered.
thanks
david jencks
On Dec 6, 2010, at 6:09 PM, Leonardo Uribe wrote:
> Hi
>
> I don't think we can include it for 2.0.3 release. This change should be discussed carefully, and that requires some time to analyze and identify the implications if this patch is included.
>
> regards,
>
> Leonardo Uribe
>
> 2010/12/6 David Jencks <da...@yahoo.com>
> In geronimo we've been studying the ee platform spec section 8.3 and think that it's allowable to have a single classloader per ear, and we're currently implementing this (in geronimo 3). However the jsf spec requires that different web apps in an ear be distinguishable in the javax.faces.FactoryFinder. Currently myfaces' FactoryFinder distinguishes web apps by context classloader.
>
> While there might be other possible solutions, I'd like to make the way FactoryFinder figures out what context it's in pluggable. The default implementation would continue to use the TCCL, and geronimo can install a system that relies on explicit notification from the container when component boundaries are crossed.
>
> I've refactored the myfaces bit of this and it seems to work fine, but I'm still working on the geronimo part. However since a myfaces release seems imminent I'd like to get this proposal out for consideration and review ASAP. I've opened MYFACES-2995 and am attaching an initial patch for consideration.
>
> thanks
> david jencks
>
>
Re: Classloaders and component boundaries
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I don't think we can include it for 2.0.3 release. This change should be
discussed carefully, and that requires some time to analyze and identify the
implications if this patch is included.
regards,
Leonardo Uribe
2010/12/6 David Jencks <da...@yahoo.com>
> In geronimo we've been studying the ee platform spec section 8.3 and think
> that it's allowable to have a single classloader per ear, and we're
> currently implementing this (in geronimo 3). However the jsf spec requires
> that different web apps in an ear be distinguishable in the
> javax.faces.FactoryFinder. Currently myfaces' FactoryFinder distinguishes
> web apps by context classloader.
>
> While there might be other possible solutions, I'd like to make the way
> FactoryFinder figures out what context it's in pluggable. The default
> implementation would continue to use the TCCL, and geronimo can install a
> system that relies on explicit notification from the container when
> component boundaries are crossed.
>
> I've refactored the myfaces bit of this and it seems to work fine, but I'm
> still working on the geronimo part. However since a myfaces release seems
> imminent I'd like to get this proposal out for consideration and review
> ASAP. I've opened MYFACES-2995 and am attaching an initial patch for
> consideration.
>
> thanks
> david jencks
>
>
Re: Classloaders and component boundaries
Posted by David Jencks <da...@yahoo.com>.
On Dec 7, 2010, at 4:42 AM, Mark Struberg wrote:
> Hi!
>
> Isn't the single EAR classloader the parentClassLoader of the WebApp ClassLoaders? I do not really undrestand the problem here... Using only 1 classloader for the whole EAR (including webapps therein) would make the re-deployment of single webapps impossible. But this is needed as far as I remember the spec...
Could you quote something? I've never seen any requirements even vaguely resembling this, geronimo has never implemented anything like this, and we've certified a lot of versions. Recently several of us have looked carefully at the ee spec and think that 1 classloader per ear is definitely allowed.
thanks
david jencks
>
> So imo this sounds like a no-go
>
> LieGrue,
> strub
>
> --- On Tue, 12/7/10, David Jencks <da...@yahoo.com> wrote:
>
>> From: David Jencks <da...@yahoo.com>
>> Subject: Classloaders and component boundaries
>> To: "MyFaces Development" <de...@myfaces.apache.org>
>> Date: Tuesday, December 7, 2010, 12:44 AM
>> In geronimo we've been studying the
>> ee platform spec section 8.3 and think that it's allowable
>> to have a single classloader per ear, and we're currently
>> implementing this (in geronimo 3). However the jsf
>> spec requires that different web apps in an ear be
>> distinguishable in the javax.faces.FactoryFinder.
>> Currently myfaces' FactoryFinder distinguishes web apps by
>> context classloader.
>>
>> While there might be other possible solutions, I'd like to
>> make the way FactoryFinder figures out what context it's in
>> pluggable. The default implementation would continue
>> to use the TCCL, and geronimo can install a system that
>> relies on explicit notification from the container when
>> component boundaries are crossed.
>>
>> I've refactored the myfaces bit of this and it seems to
>> work fine, but I'm still working on the geronimo part.
>> However since a myfaces release seems imminent I'd like
>> to get this proposal out for consideration and review
>> ASAP. I've opened MYFACES-2995 and am attaching an
>> initial patch for consideration.
>>
>> thanks
>> david jencks
>>
>>
>
>
>
Re: Classloaders and component boundaries
Posted by Mark Struberg <st...@yahoo.de>.
Hi!
Isn't the single EAR classloader the parentClassLoader of the WebApp ClassLoaders? I do not really undrestand the problem here... Using only 1 classloader for the whole EAR (including webapps therein) would make the re-deployment of single webapps impossible. But this is needed as far as I remember the spec...
So imo this sounds like a no-go
LieGrue,
strub
--- On Tue, 12/7/10, David Jencks <da...@yahoo.com> wrote:
> From: David Jencks <da...@yahoo.com>
> Subject: Classloaders and component boundaries
> To: "MyFaces Development" <de...@myfaces.apache.org>
> Date: Tuesday, December 7, 2010, 12:44 AM
> In geronimo we've been studying the
> ee platform spec section 8.3 and think that it's allowable
> to have a single classloader per ear, and we're currently
> implementing this (in geronimo 3). However the jsf
> spec requires that different web apps in an ear be
> distinguishable in the javax.faces.FactoryFinder.
> Currently myfaces' FactoryFinder distinguishes web apps by
> context classloader.
>
> While there might be other possible solutions, I'd like to
> make the way FactoryFinder figures out what context it's in
> pluggable. The default implementation would continue
> to use the TCCL, and geronimo can install a system that
> relies on explicit notification from the container when
> component boundaries are crossed.
>
> I've refactored the myfaces bit of this and it seems to
> work fine, but I'm still working on the geronimo part.
> However since a myfaces release seems imminent I'd like
> to get this proposal out for consideration and review
> ASAP. I've opened MYFACES-2995 and am attaching an
> initial patch for consideration.
>
> thanks
> david jencks
>
>