If you mean by integrating with OSGi as the same ideas, yes, I think every
project has such ideas, but the actual problem is implementing them ;)
I would like to highlight the difference between what I've done so far and
offered to be applied to JAX-WS RI and what was posted on the link you
provided:
1- I talked about OSGi-Compliant, OSGi-Compatible and OSGi Powered projects.
The link you provided tackles only the compliance problem, as such Web
Service Application will not run in OSGi Frameworks like Equinox, Felix and
Knopflerfish. If Glassfish v3 sets the Thread context class loader to a
class loader which loads classes and resources from the OSGi Environment,
then some of the applications might be runable in the OSGi Environment but
they will still have a problem if multiple versions of the same Web Service
existed.
2- Using JAX-WS RI as it is will not enable installing and removing Web
Services at runtime because Web Services in JAX-WS RI are initialized at
JAX-WS RI Servlet initialization time, JAX-WS RI servlet is not ready for
Web Services to be added at runtime.
3- For Web Services to be installed in bundles you need a module which will
scan the bundles for Web Services, the link you provided doesn't tackle this
problem, as such it's not possible to install bundles at runtime (an
additional reason for lack of dynamic behavior support), rather installing a
whole Web Application every time installing a Web Service is needed.
4- Going through the link and other links there were no single example on
how this works, as such, no proof that it works in the first place, instead
it was written there "Please give us feedback if this works for you". I'm
not sure whether we are comparing a solution which is not tested and lacks
any examples with a solution which was based on a published research, has
examples which are compatible with all major OSGi Frameworks and already
works in production systems.
I would like to highlight the idea that I talked about earlier:
"*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.*"
It's worth to mention that Axis2 already has ongoing work where Web Services
are run dynamically in the OSGi Environment. I've created a template
application for running Axis2 in the OSGi
Environment<
http://java.dzone.com/articles/a-template-application-running>which
saved hours of works for developers who reported their experience.
I think it's important to peruse
Dynamic-WS<
http://www.dynamicjava.org/projects/dynamic-ws>again so the
idea about the benefits will be clearer, the example
applications of Dynamic-WS are runnable within seconds even by
non-developers.
Best Regards,
Valery
On Mon, Dec 29, 2008 at 7:20 PM, Henri Gomez <henri.gomez_at_gmail.com> wrote:
> Well it seems many have the same ideas :)
>
> http://blogs.sun.com/ritzmann/entry/osgifying_metro_for_glassfish_v3
>
>
> 2008/12/29 Valery Abu-Eid <vladrin_at_dynamicjava.org>:
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>
>