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.and...@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-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
