On Wed, 2008-08-13 at 08:24 -0400, Bill Burke wrote:
>
> Tobias Hofer wrote:
> > Well, I agree that OSGi is not a user-friendly framework in the sense
> > that most
> > popular libraries and frameworks do not work on it. But I do not agree
> > that there
> > are tons of component models because all of them you listed do not
> > fulfill the
> > criteria for what a software component shall be.
> >
> > Some of the criteria that Clemens Szyperski and David Messerschmitt give
> > for
> > what a component in a component model must fulfill are
> > - Encapsulated
> > - A unit of independent deployment and versioning
> > - etc.
> > There exist three more criteria, but that two are the most interesting
> > for now.
> >
>
> I don't want to argue about what is and what isn't a component, but
> Seam, Web Beans, EJB, etc... do meet the above definition.
Yes, but was is exactly a component? Is it a whole application or is it
a small and reusable unit that may be shared by multiple applications
with its own life cycle (e.g. It may come and go during runtime).
>
> > Unfortunately does IMHO the JAX-RS API not fullfill the criteria to work
> > in a
> > component model because of the RuntimeDelegate class.
>
> Not necessarily true. It is possible though to have a RuntimeDelegate
> per bundle. You could use Classloader as a key to find the particular
> instance or push/pop this instance value within a ThreadLocal.
I'm in struggle with that RuntimeDelegate. I'll try to explain you my
scenario. Think of a deployment unit (A) that contains the JAX-RS API
version 0.10. Think of a JAX-RS component (R). This deployment unit (R)
has a dependency to the JAX-RS API (A). It's the only dependency it has
because there's no need for the component (R) to depend on any specific
JAX-RS implementation.
Now the compoment model is allowed to start the component (R) because
all of its dependencies are fulfilled but the JAX-RS API is not usable
without a JAX-RS implementation.
One possible solution is to bundle the JAX-RS API with a specific
implementation, say jersey. But this will bring the same API with the
same version muliple times in different deployment units. That's not
very transparent.
The JAXP API for example allows to inject a concrete Factory to an other
component because the JAXP API does not depend on the static newInstance
method itself.
Such a solution is, as I understand, not possible by the JAX-RS API
because of the dependencies to the RuntimeDelegate in the API classes.
> > It would be nice to
> > see a growing number of libraries and frameworks that can be used without
> > pain in a real component model. Would JAX-RS be one of them?
> >
>
> I see JAX-RS as a compliment/extension to existing component models (Web
> Beans, Seam, etc...). JAX-RS should be dispatching HTTP requests, not
> doing dependency injection, transaction boundaries, etc...
Yes, so do I. Component life cycle management should not part of the
JAX-RS.
> > Now, I don't wont that this discussion will end up in a dispute about
> > what a
> > component model is. There exist a common usage of that term that does not
> > match the point of view mentioned. But I think that component
> > encapsulation
> > and independent deployment and versioning of components really are
> > desirable because that makes it easier to produce stronger applications.
>
> As a side note, you talk about this like it doesn't already exist
> (independent deployment and versioning of components). independent
> deployment, hot deployment, versioning, and isolation already currently
> exists in most application servers. Yes, versioning is weak, you have
> to define an isolated deployment with all the versioned jars you need.
> But it works.
I know that most application servers allow hot deployment. But AFAIK the
scope of a deployment is a whole application or probably a subsystem as
an ear, war or the like that does not have dependencies to other
deployed parts of which the application server may be aware of.
> This is why I don't see OSGi as very revolutionary for the end user. I
> see it more as something to benefit framework developers and middleware
> providers. To give us a common kernel to deploy on so we can mix and
> match each other's software.
convinced.
Tobias