Looking into the OSGi problem some more, I've decided that because a
particular bundle is not going to have access to the entire classpath (to
some degree this is possible, but it's not framework agnostic) it seems too
much trouble to design my software with that assumption. In my particular
application, there is an "xml loader" service which loads an "xml registry"
(global configuration). It then passes sections of this document to
components that need to be configured.
So, instead of having the central "xml loader" service do strict validation
on all components, I'm going to have it do basic validation on the core
schema. It will do this, then given the xsi:type of each section of the
document it can determine which component to pass that section to. Then,
each section will be responsible for further validating the section of the
document against a more specific schema.
While this is not the most ideal situation (as double validation will
generally need to be done and errors reported back to the central system) it
seems to be a better fit.
All this said, there are a few barriers to doing this with the current
schema type loader implementation. The particulary onerous bit is in
SchemaTypeLoaderImpl:
public static SchemaTypeLoaderImpl getContextTypeLoader ( )
{
ClassLoader cl = Thread.currentThread().getContextClassLoader();
SchemaTypeLoaderImpl result = (SchemaTypeLoaderImpl)
SystemCache.get().getFromTypeLoaderCache(cl);
if (result == null)
{
result =
new SchemaTypeLoaderImpl(
new SchemaTypeLoader[] { BuiltinSchemaTypeSystem.get()
}, null, cl );
SystemCache.get().addToTypeLoaderCache(result, cl);
}
return result;
}
In particular, in OSGi, Thread.getContextClassLoader() is undefined. In
tests I've run using Equinox, it does not return a class loader that is
particularly useful. In that particular OSGi framework, the class loader
that gets returned is the class loader for the SystemTypeLoaderImpl itself,
which as I'm embedded xmlbeans into the bundle that contains the "core" xml
loader ends up always being the class loader which has no knowledge of the
more specific schema components. If XMLBeans were itself an OSGi bundle the
situation would be even worse, as the class loader would have no knowledge
of even my core schema.
Suffice it to say, in OSGi the class loader which ends up being the most
useful is actually the one returned by
MySpecificObject.Factory.getClass().getClassLoader() as this ends up being
the "bundle class loader", which will have access to any schema elements
define in that jar file.
Obviously this is NOT the class loader to be used in a J2EE application
framework, though it would likely be alright in a straight-up java
application. But in any case, the change I would think I'd want to implement
would be this:
1. For all schema type loading code,
2. Instead of the context schema type loader loading from the context class
loader obtained from getContextClassLoader() it,
3. First attempts to load from the class loader that loaded the particular
object Factory that called it,
4. Then load from the ContextClassLoader if the schema component still was
not found.
My questions would be:
1. Would this loading order work outside of OSGi?
2. Would this be an overall acceptable change?
3. Where besides SchemaTypeLoaderImpl would this change have to be made?
4. What is the best way to make the schema type loader aware of the class
loader associated with the code that is calling it? (I assume it would have
to be passed in, since there is no static equivalent to
getContextClassLoader() that actually works correctly in OSGi)
Wesley
On 10/15/09 01:17, "Wesley Leggette" <[email protected]> wrote:
>
>
>
> I'm working on an application that heavily uses XMLBeans to provide for a
> modular information repository system. I'm also considering how best to move
> into using OSGi.
>
> Does anybody have any suggestions on how to make using XMLBeans with OSGi
> less painful? The thing I like most about XMLBeans is the built in type
> system, and how it can find schema types off the class path. However, once
> you use OSGi, this becomes problematic because the general best practice
> nowadays is to import specific packages that you know you'll need. This ends
> up conflicting with the auto-discovery nature of XMLBeans. You basically
> have to end up exporting the entire set of packages under
> schemaorg_apache_xmlbeans, and then using Require-Bundle to make sure that
> all possible schema elements can be discovered.
>
> Part of the problem is that I have a "common" bundle that has the base
> schema, from which I want to detect schema components (which describes
> elements which are extensions off the base schema) in other bundles. I'm
> really keen on keeping this sort of model because it prevents me from having
> to maintain a monolithic schema package (which works well for my particular
> application), but for the trouble mentioned above.
>
>
> Wesley
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
