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 java.net.URL, 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
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114087539715696&w=2.
<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).
/Daniel
