[jsr-291-eg] Fw: comment
hargrave at us.ibm.com
Wed Aug 30 11:54:46 EDT 2006
jsr-291-eg-bounces at membercvs.osgi.org wrote on 08/30/2006 10:39:56 AM:
> Here is the only comment I have received so far on the EDR
> Thanks Marchiori!
> ----- Forwarded by Glyn Normington/UK/IBM on 30/08/2006 15:38 -----
> Marchiori Carlo
> <marchiori at cadit.
> it> To
> 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.
Thanks for the comments. Nothing is ever complete... :-) but we try hard.
> - the api does not allow to know at runtime which bundle is providing a
> package to another bundle, a piece of information necessary to
> and system administrators to know the internal wirings performed by the
The PackageAdmin API will provide this information. It exists to allow the
wiring introspection. Most OSGi framework impls have command line consoles
which use the PackageAdmin API to display the package wiring information.
Any bundle can use this API to examine the current package wiring state.
> - the service framework provides yet-another register/lookup naming
> registry. We already have jndi and jmx, which doesn't even integrate
> between them, but the new framwork doen't look better. jmx provides a
> 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
> go back and forth between live and dead state, but with the same name.
> serialization mechanism isn't enough flexible. The javax.persistence new
> package is targeted to databases and isn't enough generalized. It should
> the framework,
> not the service provider, to instatiate objects, configure them, and
> them available to service consumer. Otherwise: suppose a bundle (for
> example an osgi adaptation of spring), is used as a general purprose
> to configure and 'install' services: how would you give it access
> dynamically to classes provided by other bundles?
I am not sure I fully understand this comment. The OSGi service registry
provides a local (intra-VM) publish/find/bind (SOA) model for loose
coupling between bundles. It is specificaly only for live objects. It is
also designed to handle the dynamism of the system by tracking the state
of the bundles which publish and bind to services. It also handles
multiple package version issues by filtering the find results based upon
the packages to which the bundle peforming the find is wired. Other
technologies like jndi and jmx can be bridged onto the OSGi service
registry. If you look at the Apache Felix project you will see that they
have a jmx subproject ongoing which utilizes OSGi. Others have also made
jndi to work in the OSGi framework. Also there is a Spring-OSGi project
underway which is defining how Spring will work with OSGi and it also uses
the OSGi service registry for inter-bundle bean wiring.
> - A service consumer should not use any api to have access to services.
> example the spring framework allows to fulfill object dependencies at
> runtime without clattering the client code with unnecessary api. An
> dependency should be declared simply (using an inject attribute on a
> an attribute in the MANIFEST.MF?) and fulfilled at runtime.
There are several IoC/DI technologies which work upon the "raw" OSGi
service API. As I mentioned above Spring is working on this. OSGi also
provides a Declarative Services spec. Felix has an iPOJO project. There is
also the older ServiceBinder work. All of these sit upon the base (raw)
OSGi service API. So one does not need to use the service API if they want
to use any of these other IoC technologies which sit on top.
> - 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
These services are specific services to expose framework functionality.
They are therefore connected to the OSGi API. This does not mean that any
arbitrarily designed service must also be so. See my comment above. Spring
can publish beans as OSGi services allowing other bundles to reference
those as beans. Thus a POJO becomes an OSGi service.
The 291 spec should not prescribe the IoC technology to use. It should
just provide the base API upon which you favorite IoC technology can be
built. Then it is up to you, the bundle programmer, to select your
favorite IoC technology of the moment.
> - suppose I wuold like to dinamically fournish a persistence service to
> objects (such as implement the new javax.persistence package). Then I
> 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
I assume you mean something like bytecode weaving? Equinox has some
support for this. We have an action item to investigate what additional
support is needed for this and dynamic class generation for 291.
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave at us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
More information about the jsr-291-eg