cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] OSGi based blocks
Date Wed, 15 Mar 2006 22:29:03 GMT
Sylvain Wallez skrev:
> Daniel Fagerstrom wrote:
>> I have worked on implementing the blocks framework in terms of OSGi
>> for some time. Not everything is working yet, but I think it is time
>> to start discussing the involved ideas.
> <snip/>
>> A Servlet Service
>> -----------------
>> A bundle that provides a servlet, can register it as a service with a
>> declaration like [5]:
>>   <scr:component name="cocoon.servlet3">
>>     <scr:implementation
>> class="org.apache.cocoon.blocks.osgi.TestServlet"/>
>>     <scr:service>
>>       <scr:provide interface="javax.servlet.Servlet"/>
>>     </scr:service>
>>     <scr:property name="path" value="/test3"/>
>>   </scr:component>
>> compared to the whiteboard adapter we can see some new things, here we
>> provide a service to the framework and it can be refered to by the
>> name "cocoon.servlet3" (we should use a better naming scheme, I just
>> adapted some examples from the specification while implementing the
>> above).
>> The declaration also contains a property: path=/test3, that is looked
>> up by the whiteboard adapter and used for mounting the servlet at that
>> URI context.
> I'm wondering about who's concern it is to define the path where a
> bundle is mounted. If it's in the bundle, it is totally self-contained,
> but that may lead to name clashes if two bundles have the same name
> built in. Isn't the path the responsibility of the hosting environment,
> i.e. defined by the people that assemble bundles to create an
> application (just like WARs actually)?

I completely agree that it is the deployer that should be responsible 
for the choice of mount point. The value of properties (and reference 
targets) in the DS configurations should just be considered default 
values (and a convenience in the way that you can test a block without 
configuring it further).

The deploy time configuration can be performed with a OSGi configuration 
service (CS). In the CS you can register (persistently) a dictionary 
with a service PID (persistent identity).

So for the example above you could register a dictionary {path: 
"/mytest"} with the PID "cocoon.sevlet3". Then when the DS creates the 
service component, the values from the dictionary in the CS will 
override the values from the DS configuration.

For factories, there are factory configurations. In the CS one can 
register a set of PID - dictionary associations with a *factory* PID. 
Then one product service will be created for each PID - directionary 
association, when the factory is registred.

AFAICS the CS should be able to take care of most of the information in 
wiring.xml. The question is how to use it, one idea would be to let the 
deployer fill the CS with the content from a wiring.xml.

Another idea would be to use the meta service, that in R4 contains a 
small schema language for describing a property schema. The Knopflerfish 
implementation instead use a small subset of XML schema.

I haven't done any implementation experiments on this part. I'd like to 
hear Reinhard's opinion about how to integrate it with the deployer first.

> <snip/>
>> The Block Protocol
>> ------------------
>> OSGi have an URL service that make it possible to dynamically add
>> protocols that are available through, much like the
>> Excalibur sources. I have reimplemented the block source as an
>> URLConnection that is registered as a protocol and can be used like in
>> [9] (still buggy code).
> What about the JVM-wide static URLStreamHandlerFactory problem? Did
> Equinox and/or Felix come up with a solution for this (didn't had time
> to catch up lately)?

Equinox is supposed to have a solution for it and Richard S. Hall says 
that it could be implemented in Felix if there is enough need for it

> <snip/>
>> Deployment
>> ==========
>> I have not thought that much about deployment of OSGi based blocks,
>> and assume Reinhard will have ideas about that.
>> For packaging the OSGi framework together with needed service bundles
>> and an init configuration it is best to see what the Felix and
>> Eclipse/Equinox communities have come up with.
>> Most OSGi implementations provide both telnet and http based consoles
>> for installing, starting and stopping bundles. Deploy time
>> configuration (wiring.xml) seem to have less well developed tool support.
>> There is a configuration service that can be used for deploy time
>> configuration. With the configuration service one can override the
>> properties and target attributes for references that is given in the
>> DS files in the bundles.
>> The wiring.xml could be used for setting up the configuration service.
> A *very* important point IMO for the acceptance of all this by
> developers is to be able do deploy a directory. This to have fast
> roundtrips, without having to go through the compile/package/deploy cycle.

Equinox supports all four combinations of packed/exploded and 
installed/referenced bundles (bundles are normally "installed" by 
copying their content into an internal DB like structure, a referenced 
bundle is used as is from without copying).

Felix supports the same as Richard reports in the above mail (or 
actually the three combinations that make sense, IIRC).


View raw message