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.
my $0.02
- Larry
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.