Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
...
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.
Forms and Portal have own logkit snippets that are included in the
global logkit. I just wanted to support that, I have no strong opinion
about if it is important or not, ask Carsten.
...
I snip away most of the discussion to keep this thread readable. I'll
try to adress most of the issues you addressed, below.
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) +--------+ +--------+ +----
This architecture makes sense to me, I fill some details about involved
components, configuration and dynamics. We also need to think
evolutionary to get somewhere, so I both describe a first step that is
easy to achive but not optimal and where we IMO should be heading.
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.
"The app"-bundle is responsible for the Core and the BlocksManager. The
BlocksManager replaces the Cocoon component of today, based on the the
mount points in wiring.xml it redirects the calls to the right block. It
also handles block inter communication and deploy time parameters to blocks.
The BlocksManager have an event listener that detects when a block is
installed and started. If it is a block in its wiring.xml, it will
connect to it. At a later stage the wiring.xml should IMO be moved to an
implementation of the OSGi configuration service. Using the
configuration service we get more flexible block deployment, one can use
an interactive console or GUI based tool like the Knopflerfish console
or desktop and we can have more batch oriented configuration and have a
configuration service that use a static file like wiring.xml.
"The app" makes it BlocksManager available as a service, so that an
servlet connector, cli connector etc can connect to it. It also makes
the Core avaliable as a service. This might not be ideal, but as the
service manager is designed and used in Cocoon it is the simplest way to
get something that work. The srvice manager need information from the
core to be able to create the Avalon Context object. Also the
osgi-servlet that is based on the CoconServlet needs info from the Core.
At alater stage we can refacor the blocks so that just makes register
their BlockManager as a sevice, then they get a Core first then "the
app" connects to them.
From configuration POV, "the app" need global configuration info for
setting up the Core, logging and wiring i
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.
nfo. But it doesn't contain any sitemaps or components that is part of
the blocks.
For now we can use webapp as "the app", and as it contains component
configurations and a samples it will be a block as well. But we should
IMO move the cocoon.xconf to the place where the components in it is
implemented i.e. to src/java. Also should the component section of the
main sitemap be moved to src/java. The samples should either be moved to
src/java or to a core-sample block. Furthermore src/java should IMO be
splitted into a number of blocks with different responsibilities: e.g.
API, Core, component management, sitemap, a number of blocks with
components and sitemap components, separate environment blocks, or
whatever split we find natural. But that is a later question.
(2) Connector between external world and an application;
accepts requests and passes it on to the application.
Based on some deploy time info, (at a later stage preferably from a
configuration service), the connector connects to the right "the app"
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...
Agree, we assume one "the app" and connector for now to keep it simple,
and can add more flexibilty later.
[Moved this issue]
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.
I don't think your conclusion holds, a block can register several
instances of its BlockManager service each one with a different
configuration.
Having active blocks gives several advantages, one is that they don't
need to export the packages of their implementations. Another is that
the BlocksManager and othe blocks doesn't need to know anything about
the structure of it internals, the only thing that matters is the APIs
and registration info of the component and BlockManager services. This
means that you can use several kinds of component managers and deveral
versions of Cocoon sitemaps at the same time. The loose couplig between
blocks makes the architecture more flexible and scalable. It will it
make it easier to co exist with non Cocoon OSGi services, and maybe even
Eclipse plugins.
WDYT?
/Daniel
