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 2006/02/04 14:26:24 UTC
svn commit: r374865 - in /cocoon/trunk/cocoon-blocks-fw:
cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/
cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/container/
cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/te...
Author: danielf
Date: Sat Feb 4 05:26:06 2006
New Revision: 374865
URL: http://svn.apache.org/viewcvs?rev=374865&view=rev
Log:
Changed from dependency based component lookup to global component registry (https://issues.apache.org/jira/browse/COCOON-1764).
Updated tests and samples to reflect that there is no need to declare component dependencies in block.xml.
Added:
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java (with props)
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistryImpl.java (with props)
Removed:
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/InterBlockServiceManager.java
Modified:
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlockManager.java
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlocksManager.java
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test1/META-INF/block.xml
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test2/META-INF/block.xml
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test3/META-INF/block.xml
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test1/META-INF/block.xml
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test2/META-INF/block.xml
cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test3/META-INF/block.xml
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlockManager.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlockManager.java?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlockManager.java (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlockManager.java Sat Feb 4 05:26:06 2006
@@ -52,7 +52,7 @@
private Servlet blockServlet;
private BlockWiring blockWiring;
private BlockContext blockContext;
- private Blocks blocks;
+ private ServiceManagerRegistry serviceManagerRegistry;
public void enableLogging(Logger logger) {
this.logger = logger;
@@ -67,11 +67,8 @@
return this.logger;
}
- // FIXME The InterBlockServiceManager need access to the BlocksManager,
- // it should preferably just need to access something more component
- // handling specific.
- public void setBlocks(Blocks blocks) {
- this.blocks = blocks;
+ public void setServiceManagerRegistry(ServiceManagerRegistry serviceManagerRegistry) {
+ this.serviceManagerRegistry = serviceManagerRegistry;
}
public void init(ServletConfig servletConfig) throws ServletException {
@@ -95,10 +92,6 @@
ServletConfig blockServletConfig =
new ServletConfigurationWrapper(this.getServletConfig(), this.blockContext);
- // Create a service manager for getting components from other blocks
- ServiceManager topServiceManager = new InterBlockServiceManager(this.blockWiring, this.blocks);
- ((InterBlockServiceManager)topServiceManager).enableLogging(this.getLogger());
-
// Set up the component manager of the block
try {
// FIXME make the component manager class configurable
@@ -114,7 +107,7 @@
LifecycleHelper.setupComponent(this.serviceManager,
this.getLogger(),
null,
- topServiceManager,
+ this.serviceManagerRegistry,
this.blockWiring.getComponentConfiguration());
} catch (Exception e) {
e.printStackTrace();
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlocksManager.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlocksManager.java?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlocksManager.java (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/BlocksManager.java Sat Feb 4 05:26:06 2006
@@ -65,6 +65,7 @@
private HashMap mountedBlocks = new HashMap();
private Logger logger;
private ClassLoader classLoader;
+ private ServiceManagerRegistry serviceManagerRegistry = new ServiceManagerRegistryImpl();
public void init(ServletConfig servletConfig) throws ServletException {
super.init(servletConfig);
@@ -151,7 +152,7 @@
" id=" + id +
" location=" + location);
BlockManager blockManager = new BlockManager();
- blockManager.setBlocks(this);
+ blockManager.setServiceManagerRegistry(this.serviceManagerRegistry);
try {
LifecycleHelper.setupComponent(blockManager,
this.getLogger(),
Added: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java?rev=374865&view=auto
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java (added)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java Sat Feb 4 05:26:06 2006
@@ -0,0 +1,40 @@
+/*
+ * Copyright 1999-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.blocks;
+
+import org.apache.avalon.framework.service.ServiceManager;
+
+/**
+ * Interface for ditributed service management.
+ *
+ * WARNING: It is rather specific for the ECM way of managing component and will probably
+ * be replaced with a more OSGi friendly strategy.
+ *
+ * In ECM the service manager contains component handlers while the OSGi service registry
+ * contains objects or factories. I didn't find any nice way to combine these strategies in
+ * one interface.
+ *
+ * @version $Id$
+ */
+public interface ServiceManagerRegistry extends ServiceManager {
+
+ /**
+ * Register what service manager that contains the component bound to a certain role
+ * @param role the component role
+ * @param manager the service manager containing the component
+ */
+ public void registerServiceManager(String role, ServiceManager manager);
+}
Propchange: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistry.java
------------------------------------------------------------------------------
svn:keywords = Id
Added: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistryImpl.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistryImpl.java?rev=374865&view=auto
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistryImpl.java (added)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistryImpl.java Sat Feb 4 05:26:06 2006
@@ -0,0 +1,67 @@
+/*
+ * Copyright 1999-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.blocks;
+
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.avalon.framework.service.ServiceException;
+import org.apache.avalon.framework.service.ServiceManager;
+
+/**
+ * @version $Id$
+ */
+public class ServiceManagerRegistryImpl implements ServiceManagerRegistry {
+
+ private Map serviceManagerMapping = Collections.synchronizedMap(new HashMap());
+
+ /* (non-Javadoc)
+ * @see org.apache.cocoon.blocks.ServiceManagerRegistry#registerServiceManager(java.lang.String, org.apache.avalon.framework.service.ServiceManager)
+ */
+ public void registerServiceManager(String role, ServiceManager manager) {
+ this.serviceManagerMapping.put(role, manager);
+ }
+
+ /* (non-Javadoc)
+ * @see org.apache.avalon.framework.service.ServiceManager#lookup(java.lang.String)
+ */
+ public Object lookup(String role) throws ServiceException {
+ ServiceManager manager = (ServiceManager) this.serviceManagerMapping.get(role);
+ if (manager == null) {
+ throw new ServiceException(role, "Could not find any manager in connected blocks that contains the role");
+ }
+ return manager.lookup(role);
+ }
+
+ /* (non-Javadoc)
+ * @see org.apache.avalon.framework.service.ServiceManager#hasService(java.lang.String)
+ */
+ public boolean hasService(String role) {
+ ServiceManager manager = (ServiceManager) this.serviceManagerMapping.get(role);
+ return manager != null && manager.hasService(role);
+ }
+
+ /* (non-Javadoc)
+ * @see org.apache.avalon.framework.service.ServiceManager#release(java.lang.Object)
+ */
+ public void release(Object role) {
+ ServiceManager manager = (ServiceManager) this.serviceManagerMapping.get(role);
+ if (manager != null)
+ manager.release(role);
+ }
+
+}
Propchange: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistryImpl.java
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/blocks/ServiceManagerRegistryImpl.java
------------------------------------------------------------------------------
svn:keywords = Id
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java Sat Feb 4 05:26:06 2006
@@ -30,7 +30,9 @@
import org.apache.avalon.framework.service.ServiceManager;
import org.apache.avalon.framework.service.Serviceable;
import org.apache.cocoon.blocks.BlockConstants;
+import org.apache.cocoon.blocks.ServiceManagerRegistry;
import org.apache.cocoon.blocks.util.CoreUtil;
+import org.apache.cocoon.components.ComponentInfo;
import org.apache.cocoon.components.LifecycleHelper;
import org.apache.cocoon.components.container.CocoonServiceManager;
import org.apache.cocoon.components.source.impl.ContextSourceFactory;
@@ -56,6 +58,7 @@
Configuration configuration;
ServiceManager parentServiceManager;
ServiceManager serviceManager;
+ ServiceManagerRegistry serviceManagerRegistry;
// Wiring
@@ -75,6 +78,7 @@
public void service(ServiceManager parentServiceManager) throws ServiceException {
this.parentServiceManager = parentServiceManager;
+ this.serviceManagerRegistry = (ServiceManagerRegistry) parentServiceManager;
}
public void initialize() throws Exception {
@@ -140,8 +144,8 @@
// The source resolver must be defined in this service
// manager, otherwise the root path will be the one from the
// parent manager, we add a resolver to get it right. If the
- // components section contain includes the CoreComponentManager
- // use the location of the configuration an the parent SourceResolver
+ // components section contain the CoreComponentManager, use the
+ // location of the configuration and the parent SourceResolver
// for resolving the include.
DefaultConfiguration sourceManagerConf =
new DefaultConfiguration("components", confLocation);
@@ -166,12 +170,35 @@
this.serviceManager =
sourceResolverSM;
- // Create a service manager with the exposed components of the block
+ // Create a service manager with the exposed components of the block and register
+ // the roles in the global registry
if (this.configuration != null) {
DefaultConfiguration componentConf =
new DefaultConfiguration("components", confLocation);
componentConf.addAll(this.configuration);
- this.serviceManager = new CocoonServiceManager(this.serviceManager);
+ this.serviceManager =
+ new CocoonServiceManager(this.serviceManager) {
+
+ /* (non-Javadoc)
+ * @see org.apache.cocoon.components.container.CocoonServiceManager#addComponent(java.lang.String, java.lang.String, org.apache.avalon.framework.configuration.Configuration, org.apache.cocoon.components.ComponentInfo)
+ */
+ public void addComponent(String role, String className, Configuration config, ComponentInfo info) throws ConfigurationException {
+ super.addComponent(role, className, config, info);
+
+ if (configuration.getAttributeAsBoolean("exported", true)) {
+ ECMBlockServiceManager.this.serviceManagerRegistry.registerServiceManager(role, this);
+ }
+ }
+
+ /* (non-Javadoc)
+ * @see org.apache.cocoon.core.container.CoreServiceManager#addInstance(java.lang.String, java.lang.Object)
+ */
+ public void addInstance(String role, Object instance) throws ServiceException {
+ super.addInstance(role, instance);
+ ECMBlockServiceManager.this.serviceManagerRegistry.registerServiceManager(role, this);
+ }
+
+ };
LifecycleHelper.setupComponent(this.serviceManager,
this.getLogger(),
newContext,
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test1/META-INF/block.xml
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test1/META-INF/block.xml?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test1/META-INF/block.xml (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test1/META-INF/block.xml Sat Feb 4 05:26:06 2006
@@ -41,9 +41,6 @@
</property>
</properties>
<requirements>
- <requires interface="http://cocoon.apache.org/blocks/core/1.0"
- name="core"
- default="http://cocoon.apache.org/blocks/core/1.0"/>
<requires interface="http://cocoon.apache.org/blocks/another-interface/1.0"
name="test2"
default="http://cocoon.apache.org/blocks/another-block/1.0"/>
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test2/META-INF/block.xml
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test2/META-INF/block.xml?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test2/META-INF/block.xml (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test2/META-INF/block.xml Sat Feb 4 05:26:06 2006
@@ -31,9 +31,4 @@
<servlet class="org.apache.cocoon.sitemap.SitemapServlet">
<sitemap file="COB-INF/block-sitemap.xmap"/>
</servlet>
- <requirements>
- <requires interface="http://cocoon.apache.org/blocks/core/1.0"
- name="core"
- default="http://cocoon.apache.org/blocks/core/1.0"/>
- </requirements>
</block>
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test3/META-INF/block.xml
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test3/META-INF/block.xml?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test3/META-INF/block.xml (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-impl/src/test/resources/org/apache/cocoon/blocks/test3/META-INF/block.xml Sat Feb 4 05:26:06 2006
@@ -40,10 +40,5 @@
<description>Still another test property</description>
</property>
</properties>
- <requirements>
- <requires interface="http://cocoon.apache.org/blocks/core/1.0"
- name="core"
- default="http://cocoon.apache.org/blocks/core/1.0"/>
- </requirements>
<extends block="http://cocoon.apache.org/blocks/anyblock/1.0"/>
</block>
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test1/META-INF/block.xml
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test1/META-INF/block.xml?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test1/META-INF/block.xml (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test1/META-INF/block.xml Sat Feb 4 05:26:06 2006
@@ -41,9 +41,6 @@
</property>
</properties>
<requirements>
- <requires interface="http://cocoon.apache.org/blocks/core/1.0"
- name="core"
- default="http://cocoon.apache.org/blocks/core/1.0"/>
<requires interface="http://cocoon.apache.org/blocks/another-interface/1.0"
name="test2"
default="http://cocoon.apache.org/blocks/another-block/1.0"/>
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test2/META-INF/block.xml
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test2/META-INF/block.xml?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test2/META-INF/block.xml (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test2/META-INF/block.xml Sat Feb 4 05:26:06 2006
@@ -31,9 +31,4 @@
<servlet class="org.apache.cocoon.sitemap.SitemapServlet">
<sitemap file="COB-INF/block-sitemap.xmap"/>
</servlet>
- <requirements>
- <requires interface="http://cocoon.apache.org/blocks/core/1.0"
- name="core"
- default="http://cocoon.apache.org/blocks/core/1.0"/>
- </requirements>
</block>
Modified: cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test3/META-INF/block.xml
URL: http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test3/META-INF/block.xml?rev=374865&r1=374864&r2=374865&view=diff
==============================================================================
--- cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test3/META-INF/block.xml (original)
+++ cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/webapp/test3/META-INF/block.xml Sat Feb 4 05:26:06 2006
@@ -40,10 +40,5 @@
<description>Still another test property</description>
</property>
</properties>
- <requirements>
- <requires interface="http://cocoon.apache.org/blocks/core/1.0"
- name="core"
- default="http://cocoon.apache.org/blocks/core/1.0"/>
- </requirements>
<extends block="http://cocoon.apache.org/blocks/anyblock/1.0"/>
</block>
Re: Global component registry
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz wrote:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> This requires a component declarations with explicit dependencies.
>>>> Unfortunately ECM doesn't support this at all as it is based on
>>>> getting the dependencies through the service manager in the program
>>>> code. But OSGi declarative services support declarative component
>>>> dependencies e.g.
>>>
>>>
>>> Unfortunatly the OSGi spec doesn't say much about declarative
>>> services. Did I overlook them or do you know of any source of
>>> information that is more helpful (e.g. show some examples)?
>>
>> They are new in R4 and part of the services specification (the R4 is
>> split into a core and a service specification). The specification
>> contains some examples, other than that I haven't found any examples.
>> There are two open source implementations, the reference
>> implementation from IBM that now is part of Eclipse/Equinox and one
>> from Knopflerfish.
>
> In the meantime I found
> http://oscar-osgi.sourceforge.net/tutorial/ex7.html and
> http://gravity.sourceforge.net/servicebinder/
It is similar but not exactly the same. The declarative services is a
development of the service binder. But IIUC, they are rather close, so
it is probably a good starting point to read about the service binder.
Standard documents are not that easy going ;) even if the OSGi ones are
well written.
>> I succeed to make a minimal example running in the Equinox framework.
>> I'll start an experimental integration in Cocoon soon. The main
>> problem is how to make all the dependencies bundles. The correct way,
>> is to make all the jars bundles separately, but that is a lot of
>> work, and we need to cooperate with other communities to be able to
>> maintain it. This has been discussed at the Felix list, and there are
>> some interest e.g. for Excalibur. But someone have to take the first
>> step.
>>
>> The other option is to package all dependent jars inside the
>> Cocoon-core bundle, but that makes startup slow, and I don't know how
>> to maintain two separate packaging of Core with Maven.
>
> Maven knows the concept of "profiles" that are helpful to use
> different build strategies
>
Ok, will take a look at that.
/Daniel
Re: Global component registry
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> This requires a component declarations with explicit dependencies.
>>> Unfortunately ECM doesn't support this at all as it is based on
>>> getting the dependencies through the service manager in the program
>>> code. But OSGi declarative services support declarative component
>>> dependencies e.g.
>>
>>
>> Unfortunatly the OSGi spec doesn't say much about declarative
>> services. Did I overlook them or do you know of any source of
>> information that is more helpful (e.g. show some examples)?
>
> They are new in R4 and part of the services specification (the R4 is
> split into a core and a service specification). The specification
> contains some examples, other than that I haven't found any examples.
> There are two open source implementations, the reference implementation
> from IBM that now is part of Eclipse/Equinox and one from Knopflerfish.
In the meantime I found http://oscar-osgi.sourceforge.net/tutorial/ex7.html and
http://gravity.sourceforge.net/servicebinder/
> I succeed to make a minimal example running in the Equinox framework.
> I'll start an experimental integration in Cocoon soon. The main problem
> is how to make all the dependencies bundles. The correct way, is to make
> all the jars bundles separately, but that is a lot of work, and we need
> to cooperate with other communities to be able to maintain it. This has
> been discussed at the Felix list, and there are some interest e.g. for
> Excalibur. But someone have to take the first step.
>
> The other option is to package all dependent jars inside the Cocoon-core
> bundle, but that makes startup slow, and I don't know how to maintain
> two separate packaging of Core with Maven.
Maven knows the concept of "profiles" that are helpful to use different build
strategies
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Global component registry
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> This requires a component declarations with explicit dependencies.
>> Unfortunately ECM doesn't support this at all as it is based on
>> getting the dependencies through the service manager in the program
>> code. But OSGi declarative services support declarative component
>> dependencies e.g.
>
> Unfortunatly the OSGi spec doesn't say much about declarative
> services. Did I overlook them or do you know of any source of
> information that is more helpful (e.g. show some examples)?
They are new in R4 and part of the services specification (the R4 is
split into a core and a service specification). The specification
contains some examples, other than that I haven't found any examples.
There are two open source implementations, the reference implementation
from IBM that now is part of Eclipse/Equinox and one from Knopflerfish.
I succeed to make a minimal example running in the Equinox framework.
I'll start an experimental integration in Cocoon soon. The main problem
is how to make all the dependencies bundles. The correct way, is to make
all the jars bundles separately, but that is a lot of work, and we need
to cooperate with other communities to be able to maintain it. This has
been discussed at the Felix list, and there are some interest e.g. for
Excalibur. But someone have to take the first step.
The other option is to package all dependent jars inside the Cocoon-core
bundle, but that makes startup slow, and I don't know how to maintain
two separate packaging of Core with Maven.
/Daniel
Re: Global component registry
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> This requires a component declarations with explicit dependencies.
> Unfortunately ECM doesn't support this at all as it is based on getting
> the dependencies through the service manager in the program code. But
> OSGi declarative services support declarative component dependencies e.g.
Unfortunatly the OSGi spec doesn't say much about declarative services. Did I
overlook them or do you know of any source of information that is more helpful
(e.g. show some examples)?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Global component registry
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> danielf@apache.org wrote:
>> Author: danielf
>> Date: Sat Feb 4 05:26:06 2006
>> New Revision: 374865
>>
>> URL: http://svn.apache.org/viewcvs?rev=374865&view=rev
>> Log:
>> Changed from dependency based component lookup to global component
>> registry (https://issues.apache.org/jira/browse/COCOON-1764).
>> Updated tests and samples to reflect that there is no need to declare
>> component dependencies in block.xml.
>
> Hmm, without block dependencies deployment becomes more difficult. How
> does the person who deploys the block know which other blocks are
> required to satisfy all requirements? Also auto-wiring that uses the
> default-value from block.xml doesn't work anymore.
You are certainly right about that the lack of dependency declaration
for dependencies on component blocks will complicate deployment. But
keeping component dependencies at the _block level_ would give us some
severe problems later. I'll try to explain.
First let us step back a little bit. The point with components is that
they are parts of your system that you (or the users) want to be able to
replace. So if it is not relevant to have several implementations for
the users to choose between (or add own ones) it shouldn't be a
component. So the key with components is that they should be replaceable.
Now, let us see what happen if you declare that your block depends on a
component block. Say that it depends on Cocoon core. Cocoon core
contains maybe 100 components
(http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp/WEB-INF/xconf/cocoon-core-sitemap.xconf,
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp/WEB-INF/xconf/cocoon-core.xconf),
now suddenly you have declared that the unit that can be replaced are
not a single component, but all these maybe 100 components together. Not
particularly flexible anymore. If you want to switch one of the
components you have to implement a new block that is a copy of the core
block but with one component changed.
We had this idea of interface block, but in this case it mean that we
have a interface that say that all these, rather unrelated, components
always should go together.
Making the dependency on the core block a contract will also create
problems for us when we want to split up core in more reasonable and
reusable blocks. Each time we do that, all Cocoon projects must change
their dependency descriptor to be able to update.
Now if we had started from scratch, block dependencies would probably
have worked. We could have designed blocks so that they contained
components that actually are supposed to be replaced together. But
needing to get to that point at once, with our legacy of 50+ blocks
would be a major pain.
--- o0o ---
So what should we do? IMO the right level of granularity for component
dependencies, is at the single component level. This means that each
component (and application) should be the responsibility for declaring
what components it depends on. Then we need tools for being able to
discover the different blocks that contain the particular component that
we depend on. This tool could then help setting up the wiring so that it
contain the right set of blocks.
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on getting
the dependencies through the service manager in the program code. But
OSGi declarative services support declarative component dependencies e.g.
My suggestion is that we just leave this question for the time being. In
practice many of the component dependencies overlap with the interface
dependencies, that will be solved by the Maven compile time dependencies
anyway. Also we have been without a solution for this since we started
with compile time blocks a couple of years ago, so even if a solution
would be nice, we don't need to panic.
Also this is a problem that is common for all service (or component
based) plugin architectures, OSGi e.g. so we don't need to solve it
ourselves. Quite the opposite would it be much better to solve it
together with Felix and Maven, so that we can have a shared infra
structure and don't need to maintain an own non-compatible set of
service lookup services.
> Something else that I don't understand is how do we manage component
> namespaces in blocks?
If you talking about map: in component declarations, it seem to just be
ignored.
> If I use <map:generate type="file"
> src="test.xml"/> it just works but what happens if the hint "file" is
> used several times in different blocks? (I guess the first or the last
> declaration wins.)
The last one will be registered in the global registry, you will still
use the local one in each block as the block sets up a local service
manager for its own components and use the global service manager as a
parent manager.
/Daniel
Global component registry
Posted by Reinhard Poetz <re...@apache.org>.
danielf@apache.org wrote:
> Author: danielf
> Date: Sat Feb 4 05:26:06 2006
> New Revision: 374865
>
> URL: http://svn.apache.org/viewcvs?rev=374865&view=rev
> Log:
> Changed from dependency based component lookup to global component registry (https://issues.apache.org/jira/browse/COCOON-1764).
> Updated tests and samples to reflect that there is no need to declare component dependencies in block.xml.
Hmm, without block dependencies deployment becomes more difficult. How does the
person who deploys the block know which other blocks are required to satisfy all
requirements? Also auto-wiring that uses the default-value from block.xml
doesn't work anymore.
Something else that I don't understand is how do we manage component namespaces
in blocks? If I use <map:generate type="file" src="test.xml"/> it just works but
what happens if the hint "file" is used several times in different blocks? (I
guess the first or the last declaration wins.)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------