[jsr-291-eg] Fw: comment

BJ Hargrave 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 
specification.
> Thoughts?
> 
> Thanks Marchiori!
> 
> Glyn
> ----- 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 
>  
> Subject 
>                                        comment  
> Hi,
> 
> 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 
developers
> and system administrators to know the internal wirings performed by the
> framwork.

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 
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
> the framework,
> 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?

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. 
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.

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 
layer.

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 
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.
> 

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.


BJ Hargrave
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 mailing list