[higgins-dev] Allow context providers to be loaded by a unique classload

["Markus Sabadello" <msabadello@xxxxxxxxxxxxx>]

Hi all,

I am currently revisiting this feature request.. If I understand it
correctly, the idea is that it should be possible to load context
providers in their own isolated classloaders. I.e. if the LDAP context
provider has a dependency that contains a class "com.test.Test", and
the OpenID context provider has a dependency that contains a different
class "com.test.Test", they should not interfere. This requires
different class loaders for each CP.

Since we distribute our CPs as .jar files, I would assume that their
(own, unique) dependencies need to be .jar files inside the CP jar
file (e.g. in a lib/ subdirectory). So I need a custom class loader
that can load classes from jar files in a jar file. The parent
classloader would be the default classloader, so that nothing changes
for CPs that don't need this feature.

I will try to do this, but it may be a bit difficult to load classes
from jar files inside another jar file (I know the OneJAR project can
do something like this).

George Stanchev are you reading this? If yes, you mentioned that you
once implemented a custom classloader for a purpose like this.. If you
still have this, maybe I could see it?

Markus

---------- Forwarded message ----------
From: George Stanchev <Gstanchev@xxxxxxxxxx>
Date: Aug 28, 2007 3:26 PM
Subject: RE: [higgins-dev] Re: [Bug 190604] Allow context providers to
be loaded by a unique classloader
To: "Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>




Hi,

As I opened that bug, I can clarify. The CP can use libraries that
are clashing with the Higgins libraries. For example, the STS uses
Axis bindings which prevents CPs to use Axis2 as a WS stack to contact
its identity stores and is forced to use whatever comes with the STS
for compatibility.

What is the best solution is to "isolate" the CP in its own unique
classloader. Obviously, it is not only up to the CP to implement it
as it has to be managed from the CP context.

For example of such architectural model, see how Axis2 modules are
implemented - each module is "isolated" from the others using own
classloader created by and managed by the Axis2 engine that loads them.

Same model is applied to their sevice packages (aar files).

The Higgins CPs have a "plugin flavor" to them which calls for such
design.

George

 ________________________________
 From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Markus Sabadello
Sent: Saturday, August 25, 2007 6:27 PM

To: Higgins (Trust Framework) Project developer discussions
Subject: [higgins-dev] Re: [Bug 190604] Allow context providers to be
loaded by a unique classloader



Hi all,

The summary of this bug says "Allow context providers to be loaded by
a unique classloader".

I'm not sure what 'unique' means here. Does it simply mean that it
should be possible to specify the classloader to be used?

If yes, I am going to close the bug.

Markus


On 8/8/07, bugzilla-daemon@xxxxxxxxxxx < bugzilla-daemon@xxxxxxxxxxx> wrote:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=190604
> Product/Component: Higgins / IdAS
>
> Jim Sermersheim <jimse@xxxxxxxxxx > changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Severity|normal                      |enhancement
>
>
>
>
> --
> Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>





**********************************************************************

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of
the original message.

**********************************************************************


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev