Daniel Fagerstrom wrote:
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.
IMHO, and we overlap here in opinion, block.xml should have
* list of required blocks,
* block.xconf, containing block component declarations
* sitemap.xmap, containing block sitemap
The log configuration of a block could also be refered to from the
block.xml.
Log configuration *should not* be part of a block. Logging should be configured
globally in a single place - it is logkit.xconf right now.
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.
I do not think it makes sense to separate application's xconf from xmap. These
are two parts of the single entity: an application built on top of Cocoon.
Moreover, you can (as of now) place contents of xconf into the xmap, and it will
work.
In this light, I'd suggest to keep cocoon.xconf, (root) sitemap.xmap, and
logkit.xconf within one entity.
In my view, this should be "The Application Bundle", currently it is
cocoon_webapp, which can use passive (i.e. classes/libs only) Cocoon Core
Bundle, which is created only for convinience, but as well could be part of "The
Application Bundle" as well.
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.
Passive Cocoon Core bundle would export only classes, no other things. Reason
for this is that it can't really create neither settings not avalon context, as
it has no application specific information of its own.
<thinking aloud>
... another option though is change in naming: Cocoon Core is really not a
Cocoon Core, but rather Application Core, with knowlegde of your configuration
(xconf/xmap/xlog).
... and for convinience, we can extract libs and classes from it into Cocoon
Libs bundle, and we are back at square one with passive Cocoon Libs bundle :-)
</thinking aloud>
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.
Property file or something else - currently not a priority to me, this can be
decided later on when we have a working architecture :-)
Applications
============
We allready have a mechanism for handling multiple applications: blocks.
Application is overloaded word. Let's distinguish small applications within
single Cocoon instance - let's call them "SitemapApps" - and large applications
each containing own Cocoon instance - I called this one "The Application Bundle"
above.
Yes, SitemapApps *are* blocks. But "The Application" in my POV, is a bundle
which creates Cocoon instance, loads up (and/or wires) all necessary cocoon
blocks, together with all required SitemapApps.
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.
For SitemapApps - yes.
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.
Depending on what 'user application' is.
I have this far assumed that Cocoon Core is a singleton that all blocks
connect to.
I don't think it's possible. Each of "The Application"s will have unique
configuration.
... Not sure it makes sense at this point talk about multiple "The Application"s
- hence "The Application", not "An Application" - it will make sense later on
when industry will support OSGi as a deployment platform of choice - if that
ever happens. We should keep our options open, though.
We could have several Core if that is needed, although it
increases complexity as all blocks must tell which Core they should
connect to.
No, blocks should not 'tell': blocks should be 'wired' *by* the application
which uses it, and they can not *attach* to an application on their will - and
it is a security concern too - you only get the code you explicitly configured
in wiring.
What they can tell though is which version of passive Cocoon Core bundle they
require: i.e., one block might depend on Cocoon 2.2, while another block can
require Cocoon 2.5.
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.
cocoon_servlet is, IMHO, a 'connector' to the application, thus we can finally
separate environment (http / command line / jms / mail / etc) from application code.
--- 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.
I would not worry at all about configuration at this moment - need to get right
architecture first.
Partially, this problem can be solved by means of extending a block. So, if you
have some block with default config, you should create own block extending this
other block, and instead of using default config, override with your own.
Note that such extension will not be required in all cases: many sitemap
components take run-time configuration parameters from the sitemap, so no need
to override default config.
And second thought is, some block configuration parameters should be passed from
the wiring.
If we want to make blocks easy to reuse we have to think about component
configurations in blocks irrespectively of which approach we take.
Correct. But it takes 2nd priority, IMHO.
--- o0o ---
Does the architecture that I work towards seem more reasonable now?
It misses ascii art :-) Really, nice diagram tells more than thousand words.
Also, I'm not convinced that blocks should be active (i.e. contain activator) at
all. We should probably separate block's code from block's instance. It is
especially important if you have an ability to pass parameters into the block.
Two Cocoon Applications will not be able to share single instance of a block if
its configuration differs - hence, block itself is passive and is instantiated
by the application.
Which brings following architecture to the table:
Active +---------+ +-------------+
OSGi | The App | | Cocoon |
Bundles | (1) | | Servlet (2) |
(Services) +---------+ +-------------+
/ \
/ \
Dummy +--------+ +--------+ +----
OSGi | Cocoon | | Cocoon | | ...
Bundles | Core | | Forms | |
(Code Reuse) +--------+ +--------+ +----
Where,
(1) Bundle contains (or refers to) xconf/xmap/xlog and activator
creates Core corresponding to those. Wiring is loaded, blocks
are found, instantiated and wired.
(2) Connector between external world and an application;
accepts requests and passes it on to the application.
I'm not convinced though exactly how (2) above should work. Is it single
instance or many? What if there are more than one app? How it is configured? I
guess we can go back and forth on this one - not so important at this point...
If you attempt to move xconf/xmap/xlog into the Cocoon Core bundle, all you
really do is a rename, and clump cocoon libraries into The App:
Active +---------+
OSGi | Cocoon |
Bundles | Core |
(Services) +---------+
\
\
Dummy +--------+ +----
OSGi | Cocoon | | ...
Bundles | Forms | |
(Code Reuse) +--------+ +----
(which I was already tried to explain above but without graphics :) )
Hope above has some sense in it... So, WDYT?
Vadim
