Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
There are two main alternatives: register the component manager as
a service or register the components as services. We found the
later alternative more atractive as OSGi allready contains a nice
and flexible service registration and service lookup mechanism.
Adding an extra layer just seemed to complicate things.
Not sure it will fly, though.
First, it means that you are managing 'fine' components with coarse
container.
To be a little bit more exact it is not actual components that are
exposed but component factories.
This does not look like a good idea at all. In many scenarios, service
(Threadsafe Component) must really be instantiated once in order to
work properly. Cron, RunnableManager, DatasourceComponent come to mind.
There is of course set of components which can be instantiated
multiple times - Poolables and SingleThreaded.
According to the OSGi specification, a service is a singleton for a
given bundle: different bundles _can_ be given different objects for the
same services, but a given bundle will always obtain the _same_ object
when it asks for a service.
What that means is that only components exposed as singletons can be
exported as OSGi service and thus between blocks. This means ThreadSafe
components that already have the singleton semantics and also poolable
components wrapped in a ThreadSafe proxy that is available in ECM+
When exporting components as OSGi services, the OSGiCoreServiceManager
registers an OSGi ServiceFactory that wraps an ECM ComponentHandler
after having controlled that this handler actually manages a singleton.
<snip/>
Hm... I think you are mixing three concerns here in one:
(1) How cocoon block obtains classes exported from non-cocoon,
pure OSGi block
Classes are obtained as usual by using them (classloader stuff).
Services are obtained by the good old
ServiceManager.lookup(ServiceInterface.class.getName()) which is
implemented as an OSGi service lookup.
(2) How cocoon block obtains *component* (not class! not factory!)
exported from another cocoon block
ServiceManager.lookup() ! The factory stuff is hidden in
OSGiConreServiceManager
(3) How non-cocoon, pure OSGi block obtains components exported by
cocoon block
Cocoon components are exported as OSGi services using their role, which
happens to be the name of the service interface, as required by OSGi.
For components having multiple implementations, the hint is stored in
the OSGi property dictionary used to register the service.
I suggest to ignore the third and concentrate on second. Third can
come later - if ever - if need arise - and can be implemented as you
describe it, by exporting each component as a 'service'. First is
necessary only if you want to package some .jar files as blocks or use
3rd party blocks, also can be ignored for the time being.
Well, it seems to me we have the 3 of them right now :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
