geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: GERONIMO-6185: SchemaFactory.newInstance() fails on IBM JDK
Date Mon, 10 Oct 2011 14:15:09 GMT
I read those comments on this JIRA, seems we have many solutions, I listed
them all, so that we could compare them clearly. Personally, I like the
option b and e.
a. Use the equonix specific compatible bootdelegation
    For this, I am not sure whether Equonix provides a filter option, so it
only will try those classes from system classloader as the last try. While I
guess that, in most scenario, this will not bring any issue. The only
problem, I think is that whether we would support other OSGi framework, and
actually, we ship Felix.

b. Use JVM specific bootdelegation properties
    I think that this option is fine, and I saw that we have already added
some packages in the bootdelgation configuration.

c. Replicate SchemaFactory
    I am not sure I understand this correctly, if it means to create same
name classes with OSGi searching algorithm, so do we need to fork all those
classes ?

d. Set the context classloader with null.
    This may require the users to update their codes, guess that it is not a
good idea.

e. Create a wrapper SchemaFactory implementation
    Geronimo could provide a wrapper implementation for the SchemaFactory,
and we could do any hack in the class, it is also require to configure a
global system property and export that class in the
org.osgi.framework.system.packages.extra property.

2011/10/8 Jarek Gawor <>

> Hi all,
> Just looking for opinions on GERONIMO-6185 and what we can do about
> it. For example, should we have JVM specific bootdelegation
> properties? Or should we find some way to replicate SchemaFactory
> class with our own that has some fall back mechanism? Other ideas?
> Thanks,
> Jarek


View raw message