dev@jsr311.java.net

Re: JSR311: Support for OSGi Service Platform

From: Tobias Hofer <tobias.hofer_at_basis06.com>
Date: Thu, 14 Aug 2008 08:20:25 +0200

On Wed, 2008-08-13 at 14:07 -0700, Larry Cable wrote:
> Yup ... I would still argue that fewer/thiner component models are
> better these days ... its the combinatorial complexity that makes
> applications using multiple models difficult to write or
> even to get to interoperate; I freely admit that I am a perpetrator of
> such crimes in the past ... but we all should learn from our mistakes ...
>
> My personal opinion of the OSGi "Services" Registry is that it is "prior
> generation" API style thinking that would and should be replaced with
> Dependency Injection thus breaking the dependency
> on OSGi and making classes independent and more reusable in a variety of
> other (DI capable) containers.
OSGi supports dependency injection using declarative services. There's
no need no anything about the service registry.

Tobias

> Dhanji R. Prasanna wrote:
> >
> >
> > On Wed, Aug 13, 2008 at 6:30 AM, Bill Burke <bburke_at_redhat.com
> > <mailto:bburke_at_redhat.com>> wrote:
> >
> > <snip>
> >
> >
> >
> > One of them is the lack of a root resource service
> > interface. I suggest
> > to introduce an empty interface named
> > 'javax.ws.rs.RootResource' or
> > alike. This interface would allow an OSGi bundle to
> > expose its resources
> > using the OSGi service registry using interface that
> > is part of the
> > official API.
> >
> > I don't think an OSGi bundled JAX-RS application *needs*
> > to export any classes. I also don't think an OSGI service
> > registry is appropriate for JAX-RS components.
> >
> > Exactly right. There's no need to export any classes. But the
> > bundle
> > must provide information about the services it provides. That
> > information is used by the framework to wire bundles and their
> > components together.
> >
> >
> > The problem is, again, there are different popular component
> > architectures out there. The main ones being Spring, EJB 3, Seam,
> > and maybe even Guice.
> >
> >
> > Yea, exactly. I recall our discussions early in the life of this EG
> > where Larry Cable & I argued strongly in favor of deliberately *not*
> > creating a custom component model for JaxRs. Rather for taking an
> > agnostic approach, especially because of Guice (on my side) and Spring
> > (I imagine, on Larry's).
> >
> > Which, the spec leads also agreed with (we removed some of the
> > scoping/lifecycle constructs at that time).
> >
> > Dhanji.
> >
> >
> > Notice: This email message, together with any attachments, may contain
> > information of BEA Systems, Inc., its subsidiaries and affiliated
> > entities, that may be confidential, proprietary, copyrighted and/or
> > legally privileged, and is intended solely for the use of the
> > individual or entity named in this message. If you are not the
> > intended recipient, and have received this message in error, please
> > immediately return this by email and then delete it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>