Some thoughts off the top of my head:
I'm not sure if you are already aware that Metro is available as OSGi
bundle for GlassFish V3. It hasn't been used outside GlassFish and I
doubt it would work but it works fine in GF V3 at least. See here for
a bit more on the topic:
http://blogs.sun.com/ritzmann/entry/osgifying_metro_for_glassfish_v3
The main issue with the above is that it is one big bundle. We simply
didn't have the time to create proper OSGi manifests for all the
projects that go into Metro. (And we don't have any influence on third
party projects of course.)
As the blog indicates, casting JAXB into an OSGi bundle was a major
challenge. JAXB 2 uses a unique class-loading strategy to maintain
backwards compatibility with JAXB 1. That caused a major headache when
using the bundle tool because it got hopelessly confused by the
proprietary jar structure when determining dependencies. I finally
ended up removing the JAXB 1.0 classes from the JAR, then run the
bundle tool and then readd the JAXB 1.0 classes.
I am not very familiar with how the Bundle Activator and class loading
in general works in OSGi. The important thing is however that whatever
we do it may not clash with GlassFish V3. Its implementation takes
care e.g. that Metro can load classes contained in a web application.
Fabian
On 7. Jan 2009, at 21:39, Potociar Marek wrote:
> Hello Valery,
> as you may know, the JAX-WS RI is part of Metro web services stack
> together with WSIT[1]. WSIT is basically an interoperability
> extension built on top of JAX-WS RI and implements various WS-*
> technologies. I would like to ask if you would be also interested in
> working with us (the WSIT team) on a proper integration of WSIT with
> OSGi. Please, let me know.
>
> Best regards,
> Marek Potociar
>
> [1] http://wsit.dev.java.net
>
> On 29.12.2008, at 17:17, Valery Abu-Eid wrote:
>
>> Hello,
>>
>> My name is Valery Abu-Eid (a longtime happy JAX-WS RI user), I
>> maintain DynamicJava.org a website which provides open source
>> projects and articles that leverage the use of OSGi, I developed
>> the project Dynamic-WS which allows the dynamic use of JAX-WS RI in
>> the OSGi Environment and I've did a research on the subject of
>> developing highly dynamic Web Services on top of OSGi, the research
>> used Dynamic-WS with JAX-WS RI run on top of OSGi to prove the
>> efficiency of the proposed approach.
>>
>> Since JAX-WS RI jars are OSGi-incompliant, I used some techniques
>> which need further advancement to be run simply in any OSGi
>> Environment, which in turn limits the use of JAX-WS RI for OSGi
>> Applications. I think that it's more appropriate to make core JAX-
>> WS RI modules compatible with OSGi instead of finding workarounds
>> for every separate case.
>>
>> So far I've migrated/integrated with OSGi more than 10 open source
>> projects some of them are JSR APIs like JAXB, StAX and JPA. Usually
>> I consider three OSGi-adoption levels when migrating/integrating a
>> project with OSGi:
>> 1- OSGi-Compliant: Project jars contain needed OSGi Metadata (OSGi
>> related manifest headers) as such they can be installed and started
>> in the OSGi Environment without package wiring problems (package
>> sharing and class visibility problems).
>> 2- OSGi-Compatible: The project functions properly in the OSGi
>> Environment, its behavior is similar as when run in plain Java
>> environment.
>> 3- OSGi Powered: The project uses OSGi capabilities to provide
>> additional features like dynamic behavior and versioning.
>>
>> How OSGi-Migration can benefit JAX-WS RI?
>> 1- Developers who develop Web Services for OSGi Applications will
>> be able to use JAX-WS RI.
>> 2- Until the moment JAX-WS RI doesn't support Web Services Hot
>> Deployment, migrating it to OSGi would allow developers deploy Web
>> Services and other application modules in bundles which can be
>> easily installed and removed at runtime, the approach which is even
>> more efficient that the Web Service Hot Deployment.
>>
>> Before carrying on I would like to highlight three facts:
>> 1- Making JAX-WS RI jars OSGi-compliant requires only adding the
>> correct values of the OSGi headers to manifest files of JAX-WS-RI
>> jars and such effort doesn't conflict with the work done so far.
>> 2- An 80% probability that making JAX-WS RI OSGi-compatible would
>> require no changes to the already written code, rather adding a
>> single class to 2-4 libraries (the Bundle Activator) and adding a
>> new jar file.
>> 3- Glassfish v3 will be running on top of OSGi, an OSGi-compatible
>> JAX-WS RI will run smoothly with Glassfish v3.
>>
>> Since I've already worked on integrating JAX-WS RI with OSGi and
>> developed a project that allows running JAX-WS RI Web Services
>> dynamically on top of OSGi which is already used in production by
>> other developers, I think it would be relatively easy for me to
>> apply the same experience to migrate JAX-WS RI to OSGi in my free
>> time. So basically what I offer you is to get me involved in the
>> development of JAX-WS RI to migrate it to OSGi. While it might seem
>> not too complicated to involve new people with a project, past
>> experience shows that first OSGi-migration efforts usually overlook
>> many important details that cause incompatibility problems and bad
>> OSGi design choices.
>>
>> What I will be doing if I get involved?
>> 1- Adding needed headers to manifest files.
>> 2- Adding Bundle Activator class (a class which will be invoked by
>> the OSGi Framework when the Bundle is run in the environment) to
>> some jar files, the Bundle Activator will not be referenced by
>> other classes in the jar file, as such no modification to exiting
>> code will be required.
>> 3- Adding a new module (or a set of modules) that would allow
>> installing Web Services in bundles in the OSGi Environment.
>> 4- Developing a Tests project that will validate the implemented
>> features.
>>
>> What will be the end result?
>> 1- The base modules of JAX-WS RI will be OSGi-compatible, as a
>> result JAX-WS RI will be runnable in the OSGi Environment.
>> 2- Installing JAX-WS RI base modules alongside other module(s) will
>> allow developers to install and remove Web Services dynamically in
>> the OSGi Environment.
>> 3- JAX-WS RI will be compatible with the OSGi Frameworks: Eclipse
>> Equinox, Apache Felix and Knopflerfish and Java Environments JRE
>> and JDK 1.5 and 1.6.
>> 4- A Tests project which validates the claims above.
>> (The OSGi migration will not affect the behavior of JAX-WS RI in
>> non-osgi Environments in a single way)
>>
>> Waiting to hear your thoughts on the ideas above.
>>
>> Best Regards,
>> Valery