You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/09/08 00:47:13 UTC
Real blocks - current state and next steps
Joerg Heinicke wrote:
...
> I just wanted to have answers, not new code :) But thanks very much
> for it.
> Are other things coming as fast as this time when I just ask for them?
> What about real blocks? ;)
Although there is a lot of work before we have converted everything to
real blocks and put all the infrastructure in place, we are fairly close
to get working "real blocks".
We allready have some of the main parts: the packaging and classloader
isolation is done with OSGi and we have a working Cocoon (with some
restrictions) in terms of OSGi bundles (see
http://wiki.apache.org/cocoon/osgi for references). I implemented the
sitemap part, http://marc.theaimsgroup.com/?t=111791022500004&r=1&w=2,
of it before knowing anything about OSGi. And Sylvain have implemented
component handling for blocks
http://marc.theaimsgroup.com/?t=112231957500003&r=1&w=2, but it is not
integrated yet. The main remaining work is to integrate these parts.
I just give an overview, we can discuss all the details while devloping
them.
Architecture
============
I only care for the servlet case now to not complicate things to much.
We can refactor to take care of other environments when we have
something that works.
The Blocks servlet
------------------
The main block is the blocks servlet bundle. It create the Cocoon Core
object (o.a.c.core.Core) and make it available to all other blocks as a
(OSGi) service (I committed o.a.c.core.osgi.OSGiBootstrapEnvironment
yesterday that can beused for creating a Core adapted to the OSGi
context). It also makes all components in the Cocoon core (src/java/**)
available as services. The blocks servlet does not necesarily contain
the core it might be an own library bundle that the blocks servlet just
depend on.
The blocks servlet bundle creats a servlet and register it in a (OSGi)
HttpService. The servlet dooes nothing in it self it just works as a
switch board for the blocks. When a block with sitemap functionality is
deployed in the OSGi container, it will register a Block service and the
service migth also be deployed at a certain mount point in the URI
space. The blocks servlet bundle will react (through OSGi event
handling) on the presence of a new sitemap block and redirect all http
calls to the blocks mount point to its Block service.
The blocks servlet bundle will contain part of the code from
o.a.c.components.blocks.BlocksManager. The main difference from the
BlocksManager is that the blocks servlet bundle will not be responsible
for deploy time configuration and creation of the individual blocks.
A Block
-------
An individual block will use some common BlockActivator as activator.
The BlockActivator will base its work on the block.xml file of the
block. If block.xml contains a reference to an .xconf file it will
create a parent service manager that contains all the components of the
.xconf file and exports the components as services so that other blocks
can use them. Furthermore it will translate all requests for components
that not is part of the local container to (OSGi) service requests so
that the component can be delivered from other blocks. Sylvain have
allready written most of the code for the component management and it
can befound in o.a.c.core.osgi.
The block.xml will be used for configure an
o.a.c.components.blocks.BlockManager. If there is a sitemap reference i
block.xml a Block service will be created and exposed. And if there is a
local component manager as described above, it will be used as parent
component manager for the sitemap.
One question is how to give deploy time configuration (the wiring.xml)
about mount point, block attributes, and connections to other blocks, to
a block. Maybe the block specific properties that Carsten is working on
could be used. At a later stage the configuration manager service of
OSGi could be useful.
After having implemented what is described above we have a first version
of real blocks. There are however some surrounding components and infra
stucture we need to make it really usefull.
Various
=======
Library bundles
---------------
Today all the jars that the core depend on is uncluded in the Cocoon
core bundle. It would be much more practical to package them as separate
bundles. There is a tool, Mangen
http://oscar-osgi.sourceforge.net/mangen/, that take a set of jars,
amalyze all interdependencies and generate the appropriate manifest
files with exports and imports. It is also configurable in various ways.
Using this tool would simplify the manifest creation a lot.
It wouuld be practical if the communities for the various jars supported
OSGi manifest files. We could probably do that within the Excalibur
project and maybe also in Jakarta commons.
Build system
------------
Currently we have some rather ad hoc tasks for building the bundles.
There is an ongoing OSGi Maven2 plugin project within Apache Felix (the
Apache OSGi incubator project). It would be good if we could take part
in that project so that the plugin works for us.
Block repository
----------------
The repository situation is not that clear to me. There is an Oscar
Bundle Repository (OBR)
http://oscar-osgi.sourceforge.net/repo/bundlerepository/ that has good
support for OSGi bundles. It handles dependencies among other things.
Eclipse also have bundle aware repository. OTH our build system is
connected to a M2 repository. Maybe we could work within Felix to make
it possible to use the OBR functionality on M2 repositories?
Deployement
-----------
During development it is easiest to deploy block by using an (possibly
graphical) OSGi console. Is this ok for production systems, should we
have some web gui?
Framework
---------
We are currently using the Knopflerfish OSGi framework, wich implements
release 3 of OSGi. It works well, but the licence isn't ASF compatible
(to week) and some functionality that we need is lacking (ability to
list directory content in bundles, and more advanced version handling).
OSGi R4 has a compatible licence and the features that we miss from R3.
Either we can use the OSGi R4 framework from Eclipse, it is stable and
rather complete, but not as easy to use. Or we can use the OSGi R4
framework from Felix that is under development, but it is Apache and
easier to influence.
/Daniel
Re: Real blocks - current state and next steps
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 08 September 2005 06:47, Daniel Fagerstrom wrote:
> Maybe we could work within Felix to make
> it possible to use the OBR functionality on M2 repositories?
Not sure if the M2 contains enough info, but otherwise I think it is a good
idea.
Currently, I have a live "publish" system, where you scp a bundle to a
directory and a cron job extracts the manifest data and convert to xml
snippet. A cgi script collates the snippets on requests to the expected
format.
Although this works, it is one more piece of software to maintain, and it
doesn't work for client-side-only since it is an aggregated XML file.
Don't expect a Felix Bundle Repository any time soon though... :o)
Cheers
Niclas
Re: Real blocks - current state and next steps
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Deployement
>>> -----------
>>>
>>> During development it is easiest to deploy block by using an
>>> (possibly graphical) OSGi console. Is this ok for production systems,
>>> should we have some web gui?
>>
>>
>>
>> A graphical installer is fine for development but IMHO not for
>> production. I need a reproducible state of a system.
>>
>> Suppose you have a cluster of 5 app servers running Cocoon. I don't
>> want to connect to every server and install/uninstall blocks there.
>> This is way to error-prone.
>
>
> Agree. This can still be done using the OSGi configuration service as it
> just is a API, we could have an implementation that take an XML or a set
> of XML files that describes the deployment.
>
>> What I think is some kind of block-installation descriptor[1]. I think
>> M2 will help us here but I haven't had a closer look how this could be
>> done.
>
>
> Yes, something like that. I'm not up to speed yet with M2, so I don't
> know how we could use M2 here.
´
I hope I find some time before Amsterdam to learn more about M2 and also work on
the big picture of block deployment again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Real blocks - current state and next steps
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Deployement
>> -----------
>>
>> During development it is easiest to deploy block by using an
>> (possibly graphical) OSGi console. Is this ok for production systems,
>> should we have some web gui?
>
>
> A graphical installer is fine for development but IMHO not for
> production. I need a reproducible state of a system.
>
> Suppose you have a cluster of 5 app servers running Cocoon. I don't
> want to connect to every server and install/uninstall blocks there.
> This is way to error-prone.
Agree. This can still be done using the OSGi configuration service as it
just is a API, we could have an implementation that take an XML or a set
of XML files that describes the deployment.
> What I think is some kind of block-installation descriptor[1]. I think
> M2 will help us here but I haven't had a closer look how this could be
> done.
Yes, something like that. I'm not up to speed yet with M2, so I don't
know how we could use M2 here.
/Daniel
Re: Real blocks - current state and next steps
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Deployement
> -----------
>
> During development it is easiest to deploy block by using an (possibly
> graphical) OSGi console. Is this ok for production systems, should we
> have some web gui?
A graphical installer is fine for development but IMHO not for production. I
need a reproducible state of a system.
Suppose you have a cluster of 5 app servers running Cocoon. I don't want to
connect to every server and install/uninstall blocks there. This is way to
error-prone.
What I think is some kind of block-installation descriptor[1]. I think M2 will
help us here but I haven't had a closer look how this could be done.
[1]
http://svn.apache.org/repos/asf/cocoon/whiteboard/block-deployer/test/sample-descriptors/deploy_001.xml
just to give an idea what I mean, don't want to say that this *is* the solution.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------