[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    OSGi interoperability (too late for 2.5.0)
From:       Wesley Leggette <wleggette () cleversafe ! com>
Date:       2009-12-09 18:11:46
Message-ID: C745460B.21D4C%wleggette () cleversafe ! com
[Download RAW message or body]



I had meant to bring this up before release, but I guess I'm a bit late now:

In my company, we use XmlBeans heavily but are planning on migrating to OSGi
eventually. The main problem with xmlbeans/osgi interoperability right now
is that the context class loader is the main mechanism to load schemas. This
works in a traditional environment, and can even be made to work in
container environments like Tomcat. However, the context class loader cannot
load all schemaorg_apache_xmlbeans packages that exist, even if they are
exported through OSGi manifests, since an OSGi bundle only imports packages
it has specific knowledge of.

The solution I would be proposing is to use (or make a new) class that would
be a "SchemaTypeSystem" registrar. The implementation of this registrar
would be to attempt to load all schema type systems off the context class
path as currently done (this would make the system work exactly the same in
traditional systems and in tomcat, etc.). Additionally, one could call
"register(SchemaTypeSystem)" and "unregister(SchemaTypeSystem)" on the
object, which would maintain such registered systems as a global static.

The only other addition to the xbean.jar would be an OSGi manifest exporting
org.apache.xmlbeans and org.apache.xmlbeans.impl (and whatever else was
strictly needed, but note it would no longer need to export
schema_org_xmlbean packages like current xmlbeans OSGi builds).
Additionally, it would have a Declarative Service (DS) manifest indicating
the schema type system registrar as a "registrar" service, the built-in
schema type system as a "type system" service, and the registrar service
would dynamically depend on all available "type system" services. (For those
that are not OSGi guys, DS is an XML configuration that, when other
"bundles" have similar DS configs that advertise "type system" services, the
DS system would automatically call "register(..)" on the registrar as they
became available, and "unregister(..)" as they disappeared. DS is optional,
and for developers that don't use it, they would obtain the registrar
programatically and call register() and unregister() themselves).


These three changes, I believe, would completely meet the needs of OSGi
interoperability. They would not be especially difficult to implement, nor
would they affect normal operation or add any significant size to
xbeans.jar. Most importantly, they would NOT depend on any osgi java APIs,
so there would be no runtime effect for non-OSGi users.


I, of course, would be perfectly willing to implement all of this. What I
want to know is, would such a patch be accepted? I'm clearly too late for
2.5.0 (although I was hoping I could catch that), so if I were to implement
this and it were accepted, could this make this into a 2.5.X or 2.6.0 within
the next 6 months?


Wesley Leggette





On 12/9/09 11:23, "Cezar Andrei" <cezar.andrei@oracle.com> wrote:

> Please cast your vote for the XMLBeans v2.5.0-RC1, as published at
> http://xmlbeans.apache.org/dist/, to become XMLBeans v2.5.0 official release.
>  
> The vote will be open until end of day Saturday, 12th of December. Anyone is
> allowed to show support or lack of it, but only XMLBeans committer votes are
> binding.
>  
> [ ]  +1  -  I am in favor of this release, and can help
> 
> [ ]  +0  -  I am in favor of this release, but cannot help
> 
> [ ]  -0  -  I am not in favor of this release
> 
> [ ]  -1  -  I am against this proposal (must include a reason)
> 
>  
>  
>  
> My vote is:
> [X]  +1  -  I am in favor of this release, and can help
> 
>  
> Cezar 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]