cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: OSGi Bundles, Re: svn commit: r292305
Date Sat, 01 Oct 2005 11:50:00 GMT
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


Mime
View raw message