Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Moving Core and Cocoon creation to from osgi-servlet to core
but the osgi-servlet doesn't use them yet.
I might be wrong, but it seems to me this is move in wrong direction.
My thought process is...
In order to create functioning Core, you need to have several things:
* Several configuration parameters (currently in web.xml or
properties),
such as where your work directory is.
* cocoon.xconf configuration file
* logkit.xconf configuration file (or log4j - whatever)
cocoon bundle does not have any of this, and should not have any of
this, as it should contain only things which can be shared among any
applications - and all these things are application specific.
All these things are located in the cocoon_webapp bundle - which is a
root of an application. So it makes sense to place activator and
create Core within cocoon_webapp bundle itself, and make it dependent
on cocoon bundle. This also opens up possibility of deploying multiple
applications within single OSGi container.
Then, cocoon_servlet or cocoon_cli bundles can access (one of)
cocoon_webapp bundles for request processing. wdyt?
This are important questions, for me it breaks down into some
subquestions: how do we configure the components and logging of a block,
how do we configure core (and what is core)? and how do we handle
multiple applications?
Blocks
======
Components within blocks was not discussed in the same level of detail
as the sitemap functionality, IIRC, when blocks where designed a couple
of years ago. My idea about it is mainly to build incrementally on what
we have right now. The block.xml will contain an optional component
section that can include the configuraion files in WEB-INF/xconf and
WEB-INF/sitemap-additions that we have today. The open question is how
the user can modify these default configurations, I wrote a little bit
about that in the end of
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112592719413686&w=2.
The log configuration of a block could also be refered to from the
block.xml.
Core
====
From my perspective, the Cocoon core bundle also a block with own
component configurations and log configurations that we take from the
current sample webapp (I proposed that in
http://marc.theaimsgroup.com/?t=112765695900001&r=1&w=2). So for
configuration of the components of core we have the same problem that we
have to solve for all of the other blocks.
What is special with the Cocoon core bundle is that it exports the
"core" APIs for Cocoon and that it makes the Core component available
for all other blocks. The Core component contain the global Settings and
what is needed to create a Avalon context. All other blocks need to
access the Core component to be able to create there own Avalon Context,
which in turn is needed to create there comonent manager.
For configuration of core it is done through the Settings, and there are
allready several options to web.xml, Ralph and Carsten talked about
making the configuration mechanism pluggable. I would assume that it
will be possible to configure it through web.xml in the case of an
embeding servlet. In the case when we have a standalone OSGi container,
it is better to configure through a property file or through some
implementation of OSGi's configuration service.
Applications
============
We allready have a mechanism for handling multiple applications: blocks.
Each block will have an own BlockManager, the BlockManager does the same
thing as the Cocoon object (or should do, I didn't implement everything
from the Cocoon component to get something that work with a reasonable
amount of work), besides that it also take care of inter block
communication, extension, block properties and some other things.
A user application will also be a block. So a user can deploy several
applications by writing several blocks and deploy them at suitable root
URIs.
I have this far assumed that Cocoon Core is a singleton that all blocks
connect to. We could have several Core if that is needed, although it
increases complexity as all blocks must tell which Core they should
connect to. If there are properties of Core that need to be configured
at application level, we can make these properties configurable at block
level instead of (or as an alternativ to) globally.
The cocoon_servlet will use something similar to the BlocksManager to
send the incomming requests to the right BlockManager.
--- o0o ---
So we have an important problem to solve: how do we configure blocks in
an user friendly and flexible way? As described in one of the references
there are a number of different approaches to this: deploy time
configuration of properties that are used in the (fixed) component
configuration of the block. Move configurations outside the block and
configure through e.g. the configuration service. Replace all (or part)
of the default configuration using the fragment mechanism of R4 (from
Eclipse). Or combinations of the previous.
If we want to make blocks easy to reuse we have to think about component
configurations in blocks irrespectively of which approach we take.
--- o0o ---
Does the architecture that I work towards seem more reasonable now?
/Daniel
