You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by da...@apache.org on 2005/09/28 23:15:58 UTC
svn commit: r292305 - in /cocoon/trunk: ./ src/java/
src/java/org/apache/cocoon/core/ src/java/org/apache/cocoon/core/osgi/
src/osgi-servlet/org/apache/cocoon/service/servlet/impl/
Author: danielf
Date: Wed Sep 28 14:15:47 2005
New Revision: 292305
URL: http://svn.apache.org/viewcvs?rev=292305&view=rev
Log:
Moving Core and Cocoon creation to from osgi-servlet to core but the osgi-servlet doesn't use them yet. Added CoreBlockActivator that create the Core. Refactored ServiceManagerActivator to be modifyable by extension and take the Avalon cContext from Core. Added getContext to core to make the global Avalon Context available.
Added:
cocoon/trunk/src/java/org/apache/cocoon/core/osgi/CoreBlockActivator.java (with props)
Modified:
cocoon/trunk/init.xargs
cocoon/trunk/src/java/Manifest.mf
cocoon/trunk/src/java/org/apache/cocoon/core/Core.java
cocoon/trunk/src/java/org/apache/cocoon/core/osgi/ServiceManagerActivator.java
cocoon/trunk/src/osgi-servlet/org/apache/cocoon/service/servlet/impl/Activator.java
Modified: cocoon/trunk/init.xargs
URL: http://svn.apache.org/viewcvs/cocoon/trunk/init.xargs?rev=292305&r1=292304&r2=292305&view=diff
==============================================================================
--- cocoon/trunk/init.xargs (original)
+++ cocoon/trunk/init.xargs Wed Sep 28 14:15:47 2005
@@ -68,4 +68,5 @@
-start lib/core/knopflerfish-frameworkcommands-1.0.0.jar
-start lib/core/knopflerfish-logcommands-1.0.0.jar
-start lib/core/knopflerfish-http_all-1.1.0.jar
+-start build/osgi/org.apache.cocoon_1.0.0.jar
-start build/osgi/org.apache.cocoon_servlet_1.0.0.jar
Modified: cocoon/trunk/src/java/Manifest.mf
URL: http://svn.apache.org/viewcvs/cocoon/trunk/src/java/Manifest.mf?rev=292305&r1=292304&r2=292305&view=diff
==============================================================================
--- cocoon/trunk/src/java/Manifest.mf (original)
+++ cocoon/trunk/src/java/Manifest.mf Wed Sep 28 14:15:47 2005
@@ -9,7 +9,8 @@
Bundle-Vendor: Apache
Bundle-DocURL: http://cocoon.apache.org
Bundle-ContactAddress: http://cocoon.apache.org
-Bundle-Category: library
+Bundle-Activator: org.apache.cocoon.core.osgi.CoreBlockActivator
+Bundle-Category: block
Bundle-Classpath:
.,
avalon-framework-api-4.3.jar,
Modified: cocoon/trunk/src/java/org/apache/cocoon/core/Core.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/src/java/org/apache/cocoon/core/Core.java?rev=292305&r1=292304&r2=292305&view=diff
==============================================================================
--- cocoon/trunk/src/java/org/apache/cocoon/core/Core.java (original)
+++ cocoon/trunk/src/java/org/apache/cocoon/core/Core.java Wed Sep 28 14:15:47 2005
@@ -145,6 +145,14 @@
}
/**
+ * Return the Avalon context.
+ * @return The Avalon context.
+ */
+ public Context getContext() {
+ return this.context;
+ }
+
+ /**
* Return the current object model
* @return The object model.
*/
Added: cocoon/trunk/src/java/org/apache/cocoon/core/osgi/CoreBlockActivator.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/src/java/org/apache/cocoon/core/osgi/CoreBlockActivator.java?rev=292305&view=auto
==============================================================================
--- cocoon/trunk/src/java/org/apache/cocoon/core/osgi/CoreBlockActivator.java (added)
+++ cocoon/trunk/src/java/org/apache/cocoon/core/osgi/CoreBlockActivator.java Wed Sep 28 14:15:47 2005
@@ -0,0 +1,76 @@
+/*
+ * Copyright 2005 The Apache Software Foundation
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ * implied.
+ *
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cocoon.core.osgi;
+
+import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.avalon.framework.configuration.ConfigurationException;
+import org.apache.avalon.framework.configuration.DefaultConfiguration;
+import org.apache.avalon.framework.context.Context;
+import org.apache.avalon.framework.service.ServiceException;
+import org.apache.cocoon.Cocoon;
+import org.apache.cocoon.Processor;
+import org.apache.cocoon.core.BootstrapEnvironment;
+import org.apache.cocoon.core.Core;
+import org.apache.cocoon.core.CoreUtil;
+import org.apache.cocoon.core.container.CoreServiceManager;
+import org.osgi.framework.BundleContext;
+
+public class CoreBlockActivator extends ServiceManagerActivator {
+
+ private ClassLoader classLoader = getClass().getClassLoader();;
+ private Core core;
+ private Processor processor;
+
+ public void start(final BundleContext ctx) throws Exception {
+
+ BootstrapEnvironment env = new OSGiBootstrapEnvironment(this.classLoader, ctx);
+ env.log("OSGiBootstrapEnvironment created");
+ CoreUtil coreUtil = new CoreUtil(env);
+ env.log("CoreUtil created");
+ this.core = coreUtil.getCore();
+ this.processor = coreUtil.createCocoon();
+
+ super.start(ctx);
+ }
+
+ public void stop(BundleContext ctx) throws Exception {
+ super.stop(ctx);
+ }
+
+ protected Context getContext() throws Exception {
+ return this.core.getContext();
+ }
+
+ /**
+ * This method may be overwritten by subclasses to provide an own
+ * configuration
+ */
+ protected Configuration getConfiguration() {
+ DefaultConfiguration config = new DefaultConfiguration("cocoon", "CoreBlockActivator");
+ return config;
+ }
+
+ /**
+ * This method may be overwritten by subclasses to add aditional
+ * components.
+ */
+ protected void addComponents(CoreServiceManager manager)
+ throws ServiceException, ConfigurationException {
+ manager.addInstance(Core.ROLE, this.core);
+ manager.addInstance(Cocoon.class.getName(), this.processor);
+ }
+}
Propchange: cocoon/trunk/src/java/org/apache/cocoon/core/osgi/CoreBlockActivator.java
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/src/java/org/apache/cocoon/core/osgi/CoreBlockActivator.java
------------------------------------------------------------------------------
svn:keywords = Id
Modified: cocoon/trunk/src/java/org/apache/cocoon/core/osgi/ServiceManagerActivator.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/src/java/org/apache/cocoon/core/osgi/ServiceManagerActivator.java?rev=292305&r1=292304&r2=292305&view=diff
==============================================================================
--- cocoon/trunk/src/java/org/apache/cocoon/core/osgi/ServiceManagerActivator.java (original)
+++ cocoon/trunk/src/java/org/apache/cocoon/core/osgi/ServiceManagerActivator.java Wed Sep 28 14:15:47 2005
@@ -19,9 +19,14 @@
import java.net.URL;
import org.apache.avalon.excalibur.logger.LoggerManager;
+import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.configuration.DefaultConfiguration;
-import org.apache.avalon.framework.context.DefaultContext;
+import org.apache.avalon.framework.context.Context;
+import org.apache.avalon.framework.service.ServiceException;
import org.apache.avalon.framework.service.ServiceManager;
+import org.apache.cocoon.core.Core;
+import org.apache.cocoon.core.container.CoreServiceManager;
import org.apache.cocoon.components.container.ComponentContext;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
@@ -32,6 +37,7 @@
// Registering services must go through the ServiceFactory class wrapping the componentHandler
+ private ServiceManager parentManager;
private OSGiCoreServiceManager manager;
public void start(final BundleContext ctx) throws Exception {
@@ -41,17 +47,17 @@
LoggerManager logManager = new OSGiLoggerManager(ctx, LogService.LOG_DEBUG);
// Create a parent manager that will lookup registered OSGi services
- ServiceManager parentManager = new OSGiServiceManager(ctx);
+ this.parentManager = new OSGiServiceManager(ctx);
// Create a regular manager
this.manager = new OSGiCoreServiceManager(parentManager, this.getClass().getClassLoader(), ctx) {
};
-
+
//---- LogEnabled
this.manager.enableLogging(logManager.getDefaultLogger());
//---- Contextualizable
- DefaultContext avalonCtx = new ComponentContext();
+ //DefaultContext avalonCtx = new ComponentContext();
// Context entries defined in CocoonServlet/CoreUtil:
// "servlet-config"
// "servlet-context"
@@ -66,7 +72,7 @@
// Core.ROLE (???)
// Constants.CONTEXT_CLASSPATH
- this.manager.contextualize(avalonCtx);
+ this.manager.contextualize(this.getContext());
//---- LoggerManager
this.manager.setLoggerManager(logManager);
@@ -76,14 +82,8 @@
this.manager.setRoleManager(null);
//---- Configurable
- // Create a configuration object with one include directive. ECM++ will do the rest!
- DefaultConfiguration config = new DefaultConfiguration("cocoon");
- DefaultConfiguration include = new DefaultConfiguration("include");
- URL confURL = ctx.getBundle().getResource("/BLOCK-INF/block.xconf");
- include.setAttribute("src", confURL.toExternalForm());
- config.addChild(include);
-
- this.manager.configure(config);
+ this.manager.configure(this.getConfiguration());
+ this.addComponents(this.manager);
//---- Initializable
this.manager.initialize();
@@ -93,5 +93,34 @@
public void stop(BundleContext ctx) throws Exception {
// Dispose the ServiceManager
this.manager.dispose();
+ }
+
+ protected Context getContext() throws Exception {
+ Core core = (Core)this.parentManager.lookup(Core.ROLE);
+ return core.getContext();
+ }
+
+ /**
+ * This method may be overwritten by subclasses to provide an own
+ * configuration
+ */
+ protected Configuration getConfiguration() {
+ // Create a configuration object with one include directive. ECM++ will do the rest!
+ DefaultConfiguration config = new DefaultConfiguration("cocoon", "ServiceManagerActivator");
+// DefaultConfiguration include = new DefaultConfiguration("include");
+// URL confURL = ctx.getBundle().getResource("/BLOCK-INF/block.xconf");
+// include.setAttribute("src", confURL.toExternalForm());
+// config.addChild(include);
+
+ return config;
+ }
+
+ /**
+ * This method may be overwritten by subclasses to add aditional
+ * components.
+ */
+ protected void addComponents(CoreServiceManager manager)
+ throws ServiceException, ConfigurationException {
+ // subclasses can add components here
}
}
Modified: cocoon/trunk/src/osgi-servlet/org/apache/cocoon/service/servlet/impl/Activator.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/src/osgi-servlet/org/apache/cocoon/service/servlet/impl/Activator.java?rev=292305&r1=292304&r2=292305&view=diff
==============================================================================
--- cocoon/trunk/src/osgi-servlet/org/apache/cocoon/service/servlet/impl/Activator.java (original)
+++ cocoon/trunk/src/osgi-servlet/org/apache/cocoon/service/servlet/impl/Activator.java Wed Sep 28 14:15:47 2005
@@ -27,7 +27,6 @@
import org.apache.cocoon.core.osgi.OSGiLoggerManager;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
-import org.osgi.framework.BundleException;
import org.osgi.framework.ServiceEvent;
import org.osgi.framework.ServiceListener;
import org.osgi.framework.ServiceReference;
@@ -50,22 +49,18 @@
private Core core;
private Processor processor;
- public void start(BundleContext bc) throws BundleException {
+ public void start(BundleContext bc) throws Exception {
Activator.bc = bc;
- try {
- BootstrapEnvironment env = new OSGiBootstrapEnvironment(this.classLoader, Activator.bc);
- env.log("OSGiBootstrapEnvironment created");
- CoreUtil coreUtil = new CoreUtil(env);
- env.log("CoreUtil created");
- LoggerManager logManager = new OSGiLoggerManager(bc, LogService.LOG_DEBUG);
- this.logger = logManager.getDefaultLogger();
- this.core = coreUtil.getCore();
- this.processor = coreUtil.createCocoon();
- } catch (Exception e) {
- e.printStackTrace();
- throw new BundleException("Failed to create core util", e);
- }
+
+ BootstrapEnvironment env = new OSGiBootstrapEnvironment(this.classLoader, Activator.bc);
+ env.log("OSGiBootstrapEnvironment created");
+ CoreUtil coreUtil = new CoreUtil(env);
+ env.log("CoreUtil created");
+ LoggerManager logManager = new OSGiLoggerManager(bc, LogService.LOG_DEBUG);
+ this.logger = logManager.getDefaultLogger();
+ this.core = coreUtil.getCore();
+ this.processor = coreUtil.createCocoon();
ServiceListener listener = new ServiceListener() {
public void serviceChanged(ServiceEvent ev) {
@@ -97,7 +92,7 @@
}
}
- public void stop(BundleContext bc) throws BundleException {
+ public void stop(BundleContext bc) throws Exception {
}
private void setRoot(ServiceReference sr) {
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Niclas Hedhman wrote:
>On Sunday 02 October 2005 00:40, Daniel Fagerstrom wrote:
>
>
>>The metatype service in R4 is schema driven like the Knopflerfish one,
>>don't know if there are any open source implementations yet.
>>
>>
>Ok. Then I need to take a look at that.
>
>
>>For server use it is impractical with interactive parameter
>>modification. Here we could develop a configuration file driven
>>configuration service implementation. That either use a large
>>configuration file that configures everything in the app or a set of
>>configuration snippets, for making configuration less monolithic.
>>
>>
>This is an area I am struggling with conviction at the moment.
>OSGi is built on the premise that a platform restart will bring back the last
>"known state", including the Configuration set for a ManagedService.
>
>
The key issue is the form of the "known state". If it is in some obscure
binary format, I wouldn't trust it for my interactvely added data. If it
instead was in some explicit and readable form, like XML. Then I might
belive that I could restart the framework from an inconsistent state
after having tweaked the state description, or after having resumed an
earlier one from backup.
I think this is an important point for the Felix project to find a way
to handle persistance that we can use in enterprise systems.
>If I dared to make this a reality, the interactive config actually makes
>sense;
> 1. The ManagedService exposes its expected configuration in its registration,
> by publishing the defaults for everything.
>
> 2. The Config service manages the persistence.
>
> 3. One or many Config Admin services can be created to modify the
> configuration in runtime, and the Config service will track it correctly.
>
>I guess a "Export" functionality in the Config Admin service would be needed
>to allow to restore the configuration after a real "cold start" (removal of
>OSGi cache directories).
>
>
Exactly!
>I am just not comfortable at the moment to let OSGi start from 'previously
>known state'... Guess I don't have faith in my own bundles. :o)
>
>
Neither have I, yet. And if I had to put faith in that all third party
bundles are good citisens as well for being able to restart the system,
it rather shows that the mechanism is to fragile. So we need explicit
state as discussed above.
/Daniel
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Niclas Hedhman <ni...@apache.org>.
On Sunday 02 October 2005 00:40, Daniel Fagerstrom wrote:
> The metatype service in R4 is schema driven like the Knopflerfish one,
> don't know if there are any open source implementations yet.
Ok. Then I need to take a look at that.
> For server use it is impractical with interactive parameter
> modification. Here we could develop a configuration file driven
> configuration service implementation. That either use a large
> configuration file that configures everything in the app or a set of
> configuration snippets, for making configuration less monolithic.
This is an area I am struggling with conviction at the moment.
OSGi is built on the premise that a platform restart will bring back the last
"known state", including the Configuration set for a ManagedService.
If I dared to make this a reality, the interactive config actually makes
sense;
1. The ManagedService exposes its expected configuration in its registration,
by publishing the defaults for everything.
2. The Config service manages the persistence.
3. One or many Config Admin services can be created to modify the
configuration in runtime, and the Config service will track it correctly.
I guess a "Export" functionality in the Config Admin service would be needed
to allow to restore the configuration after a real "cold start" (removal of
OSGi cache directories).
I am just not comfortable at the moment to let OSGi start from 'previously
known state'... Guess I don't have faith in my own bundles. :o)
Cheers
Niclas
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Niclas Hedhman wrote:
>On Saturday 01 October 2005 20:11, Daniel Fagerstrom wrote:
>
>
...
>>Yes we talk about block deploy time parameters. These should IMO be
>>handled with a OSGi configuration service. But that might be something
>>that we implement later.
>>
>>
>Ok. Then a I agree with your conclusion.
>And this area is for me very important for non-Cocoon reasons. If you have any
>generic thoughts of how to for server apps, I am all ears. Have thought
>myself to go via a http/html interface, but that seems so hacky and would
>only do for a in-house solution.
>
>
My thoughts in this area is rather schetchy. My idea is to use a
configuration service together with the metatype service. Knopflerfish
have an implementation of the metatype service that declares the
configurable properties with XML Schema
http://www.knopflerfish.org/XMLMetatype/, then you can put the schema
and an XML document fullfilling the schema in a bundle and use special
manifest attributes for pointing at the schema and the default values.
The metatype service in R4 is schema driven like the Knopflerfish one,
don't know if there are any open source implementations yet.
Knopflerfish desktop and console have support for configuration that is
based on the schema and the default values. If you use the desktop you
can modify the parameters through the GUI. This could be usefull when
developing an app.
For server use it is impractical with interactive parameter
modification. Here we could develop a configuration file driven
configuration service implementation. That either use a large
configuration file that configures everything in the app or a set of
configuration snippets, for making configuration less monolithic.
/Daniel
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Niclas Hedhman <ni...@apache.org>.
On Saturday 01 October 2005 20:11, Daniel Fagerstrom wrote:
> >I am not sure what you mean by "passing parameters into the block". I have
> > an eirie feeling you are refering to "management" concerns about setting
> > up the service from the outside, and not runtime concerns during the
> > service call.
>
> Yes we talk about block deploy time parameters. These should IMO be
> handled with a OSGi configuration service. But that might be something
> that we implement later.
Ok. Then a I agree with your conclusion.
And this area is for me very important for non-Cocoon reasons. If you have any
generic thoughts of how to for server apps, I am all ears. Have thought
myself to go via a http/html interface, but that seems so hacky and would
only do for a in-house solution.
Cheers
Niclas
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Niclas Hedhman wrote:
>On Friday 30 September 2005 04:55, Vadim Gritsenko wrote:
>
>
>>Also, I'm not convinced that blocks should be active (i.e. contain
>>activator) at all.
>>
>>
>
>Without active participation it is no more than a shared library, and as such
>it is very difficult to swap out and replace with a new implementation
>without restarting the entire application.
>
>
Exactly, it is much easier to stop a service and replace it with a new
implementation but with the same interface.
>>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 have a hard time following this discussion, as "block" is somewhat undefined
>in OSGi terms, and _I_ don't feel I understand with it is exactly.
>Now, that said, I have assumed that a block bundle consists of 0..n block
>services.
>
That is right. The block service(s) is what defines a block. For now the
block service will use o.a.c.components.blocks.BlockManager as API, but
we should strive for finding something much simpler and less Cocoon
specific.
From an implementation POV a Cocoon block will use a BlockActivator
that reads COB-INF/block.xml that contains a sitemap reference,
component configuration, a sitemap reference, definition of deploy time
parameters and definition of connections to other blocks. It will expose
its components as OSGi services.
...
>I am not sure what you mean by "passing parameters into the block". I have an
>eirie feeling you are refering to "management" concerns about setting up the
>service from the outside, and not runtime concerns during the service call.
>
>
Yes we talk about block deploy time parameters. These should IMO be
handled with a OSGi configuration service. But that might be something
that we implement later.
/Daniel
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Niclas Hedhman <ni...@apache.org>.
On Friday 30 September 2005 04:55, Vadim Gritsenko wrote:
> Also, I'm not convinced that blocks should be active (i.e. contain
> activator) at all.
Without active participation it is no more than a shared library, and as such
it is very difficult to swap out and replace with a new implementation
without restarting the entire application.
> 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 have a hard time following this discussion, as "block" is somewhat undefined
in OSGi terms, and _I_ don't feel I understand with it is exactly.
Now, that said, I have assumed that a block bundle consists of 0..n block
services. In OSGi, it is very straight forward to hand different service
instances to different client bundles. It is also possible to register the
same "service code" with many instances, each different in its setup. One
could! have a ROLE attribute in the registration that the client use for the
lookup. And so on.
I am not sure what you mean by "passing parameters into the block". I have an
eirie feeling you are refering to "management" concerns about setting up the
service from the outside, and not runtime concerns during the service call.
Cheers
Niclas
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> 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.
:)
A usual Cocoon installation contains very often more than one
application, and you might want to log messages of one app to one target
while logging the messages of another app to another target.
Now, you can do this my providing one single logging configuration file
(being it logkit.xconf or something different), but this requires to
patch the configuration during the deployment of your app.
So basically it's the same problem as you have with the cocoon.xconf. We
agreed that patching is bad and therefore created the nice configuration
inclusion mechanism. I think it's just natural to use this for logging
configuration as well.
With real blocks, I think you might want to configure logging on the
block level (application = block).
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: OSGi Bundles, Re: svn commit: r292305
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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