Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Allow context providers to be loaded by a uniqueclassloader
Title: RE: [higgins-dev] Allow context providers to be loaded by a uniqueclassloader
Hi,
 
I am on vacation till the end of the year, so my reading on that list is light so appologize for the
late response.
 
Marcus, yes we did it in ALF - our RP security gateway is implemented
in the form of a servelet filter and we wanted to avoid clashing with the
libraries that the RP is using. The way we implemented this, is we gave
the custom class-loader ability to pick up the libraries from an arbritrary
folder. It iterates the jars and class files there and adds them to the classpath.
 
Another approach would be to go the route Apache Axis2 has taken with
their modules and service packages. Instead of placing the dependencies
in separate folders, they zip it up in a jar-like structures with .sar or .mar
extensions which they unpack on application startup in a temporary location
before adding them to the isolationist classloader classpath.
 
Whatever the approach, it would allow the CP-creators to use their own
libraries instead of relying on Higgins-distributed libraries.
 
One more note before listing the source locations. We ran into several
problems - mainly with JCE libraries (BountyCastle in particular) due to
how JCE is being loaded - in a global JCE implementation repository which
instantly becomes available to all classes (due to JCE being part of the
system classloader). So if another application wants to use JCE-library
loaded by the isolation classloader it will get an exception. XMLSecurity
in particular, did not use newer JCE interfaces where it could use Crypto
(for example) objects instantiated by the caller but instead used the
JCE factories to get Crypto objects, which of course (if the JCE library
was loaded via the isolation classloader) led to problems. We ended up
having the BC JCE be installed in the system classpath.
 
Here are the locations of our implementation
 
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.alf/components/ALFGatekeeper/src/org/eclipse/alf/security/sso/server/gatekeeper/filterloader/?root=Technology_Project
 
That package contains the implementation for the filterloader library.
 
One last thing to mention: make sure all objects/data that is returned to
the context classloader are instantiated through it or you will get linkage, etc
errors. Most of our efforts went there to ensure clear separation of which
object is created where.
 
George
 
 
Type your signature here

From: higgins-dev-bounces@xxxxxxxxxxx on behalf of Brian Walker
Sent: Fri 11/30/2007 4:34 PM
To: Higgins (Trust Framework) Project developer discussions
Subject: RE: [higgins-dev] Allow context providers to be loaded by a uniqueclassloader

Doesn't look like you got any response on this one Markus?

-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Markus Sabadello
Sent: Tuesday, November 27, 2007 6:16 AM
To: Higgins (Trust Framework) Project developer discussions
Cc: Brian Walker
Subject: [higgins-dev] Allow context providers to be loaded by a unique classloader

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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top