[jsr-291-eg] Fw: comment
glyn_normington at uk.ibm.com
Wed Aug 30 10:39:56 EDT 2006
Here is the only comment I have received so far on the EDR specification.
----- Forwarded by Glyn Normington/UK/IBM on 30/08/2006 15:38 -----
<marchiori at cadit.
jsr-291-comments at jcp.org
23/08/2006 16:11 cc
the osgi mechanism to control component dependencies is badly
needed by java developer, but it is not complete.
- the api does not allow to know at runtime which bundle is providing a
package to another bundle, a piece of information necessary to developers
and system administrators to know the internal wirings performed by the
- the service framework provides yet-another register/lookup naming
registry. We already have jndi and jmx, which doesn't even integrate well
between them, but the new framwork doen't look better. jmx provides a name
to 'live' objects to provide access to their live state for management
purposes. jndi gives name to 'dead' objects to provide access to their
persisted state. Ideally the java platform should provide a flexible
mechanism to capture the internal state of an object so as to allow it to
go back and forth between live and dead state, but with the same name. The
serialization mechanism isn't enough flexible. The javax.persistence new
package is targeted to databases and isn't enough generalized. It should be
not the service provider, to instatiate objects, configure them, and make
them available to service consumer. Otherwise: suppose a bundle (for
example an osgi adaptation of spring), is used as a general purprose tool
to configure and 'install' services: how would you give it access
dynamically to classes provided by other bundles?
- A service consumer should not use any api to have access to services. For
example the spring framework allows to fulfill object dependencies at
runtime without clattering the client code with unnecessary api. An object
dependency should be declared simply (using an inject attribute on a field?
an attribute in the MANIFEST.MF?) and fulfilled at runtime.
- if we should judge the service layer by the extension services already
defined for the osgi framework, then I would take a very negative
conclusion. The services are cluttered by api imposed by the service layer.
- suppose I wuold like to dinamically fournish a persistence service to
objects (such as implement the new javax.persistence package). Then I may
need to modify on the fly bytecodes as they are loaded by bundle
classloaders. There is no mean to do this currently in the osgi framework.
More information about the jsr-291-eg