You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/10/03 10:25:37 UTC
Components in blocks
I have continued the work that Sylvain started on ECM++ - OSGi service
bridge, and have some questions.
I start with a simpler one about component configuration. The idea is
that the block.xml have an optional component section which declares the
components that the block exports (see webapp/WEB-INF/block.xml for an
example). One can use the attribute exported="false" for private
components. The reason for not using the component section of the
sitemap for declaring the components that the block exports is that
blocks doesn't have to contain a sitemap, some are "component only" blocks.
As the "sitemap components" of a block in most cases also should be
exported, so that they can be used in other blocks, the components in
the webapp sample sitemap and in WEB-INF/sitemap-additions also need to
be included from the repective block.xml. As it is a waste of resources
to declare them again in the container of the main sitemap of the blocks
it means that I want to move all components of the main sitemap in the
sample webapp and all components inWEB-INF/sitemap-additions to the
respective WEB-INF/xconf. Is this OK, or are there any problems? If it
is OK, I do it ASAP for the webapp samples.
--- o0o ---
Another question is about ECM++ - OSGi service bridge. The idea with the
bridge, as you might remeber, is that the the block has an ECM container
that exports its components as OSGi services (see
o.a.c.core.osgi.OSGiCoreServiceManager). This container has a parent
container (o.a.c.core.osgi.OSGiServiceManager), that translates ECM
lookups for components not defined in the block to OSGi service lookups
that will get the components from another block.
The OSGi services must be singletons, so ThreadSafe components can be
exported and thanks to Carstens poolable proxy
(o.a.c.core.container.handler.PoolableComponentHandler) also Poolable
can be exported, but SingleThreadedComponents are not singltons and
cannot be exported yet. For the components in cocoon-core.xconf all
components could be exported except for FOM_JavaScriptInterpreter, the
output modules and the PartSourceFactory, who are SingleThreaded.
The question is how to solve it. Some of the SingleThreaded could
probably be made ThreadSafe or Poolable, for the rest we could maybe
have some kind of proxy. Ideas?
/Daniel
Re: Components in blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Upayavira wrote:
> Daniel Fagerstrom wrote:
...
>> Another question is about ECM++ - OSGi service bridge. The idea with
>> the bridge, as you might remeber, is that the the block has an ECM
>> container that exports its components as OSGi services (see
>> o.a.c.core.osgi.OSGiCoreServiceManager). This container has a parent
>> container (o.a.c.core.osgi.OSGiServiceManager), that translates ECM
>> lookups for components not defined in the block to OSGi service
>> lookups that will get the components from another block.
>>
>> The OSGi services must be singletons, so ThreadSafe components can be
>> exported and thanks to Carstens poolable proxy
>> (o.a.c.core.container.handler.PoolableComponentHandler) also Poolable
>> can be exported, but SingleThreadedComponents are not singltons and
>> cannot be exported yet. For the components in cocoon-core.xconf all
>> components could be exported except for FOM_JavaScriptInterpreter,
>> the output modules and the PartSourceFactory, who are SingleThreaded.
>>
>> The question is how to solve it. Some of the SingleThreaded could
>> probably be made ThreadSafe or Poolable, for the rest we could maybe
>> have some kind of proxy. Ideas?
>
>
> You export a singleton Factory that is used to get the object. I guess
> we could have the ECM++ bridge say "if this is component implements
> ThreadSafe, return it, if it implements ComponentFactory (or some
> such), return an object from its getInstance() method."
>
> That way the ThreadSafe/not ThreadSafe would remain transparent to
> users of ECM++.
>
> Reasonable? Or have I missed something?
OSGi services are identified on what interface(s) they implement and
optionally on extra properties. In the current implementation the role
is the interface and the optional selector is a property. So that mean
that the SingleThreaded would need to be identified in another way than
on their role if we just register them as a generic factory. It would
certainly be possible by having a property for the role as well for the
SingleThreaded and let the lookup start with a query based on role as
interface and if nothing was found, a query on the factory as interface
and role as property.
But after that you helped me to clear my thought, I find a proxy
solution more attractive. The proxy would implement the role interface
and work as a factory. The question is still about how it should work.
Proxies and details about the component manager is not my area of
speciality. Thoughts? Or preferably an implementation ;)
/Daniel
Re: Components in blocks
Posted by Upayavira <uv...@odoko.co.uk>.
Daniel Fagerstrom wrote:
> I have continued the work that Sylvain started on ECM++ - OSGi service
> bridge, and have some questions.
>
> I start with a simpler one about component configuration. The idea is
> that the block.xml have an optional component section which declares the
> components that the block exports (see webapp/WEB-INF/block.xml for an
> example). One can use the attribute exported="false" for private
> components. The reason for not using the component section of the
> sitemap for declaring the components that the block exports is that
> blocks doesn't have to contain a sitemap, some are "component only" blocks.
>
> As the "sitemap components" of a block in most cases also should be
> exported, so that they can be used in other blocks, the components in
> the webapp sample sitemap and in WEB-INF/sitemap-additions also need to
> be included from the repective block.xml. As it is a waste of resources
> to declare them again in the container of the main sitemap of the blocks
> it means that I want to move all components of the main sitemap in the
> sample webapp and all components inWEB-INF/sitemap-additions to the
> respective WEB-INF/xconf. Is this OK, or are there any problems? If it
> is OK, I do it ASAP for the webapp samples.
>
> --- o0o ---
>
> Another question is about ECM++ - OSGi service bridge. The idea with the
> bridge, as you might remeber, is that the the block has an ECM container
> that exports its components as OSGi services (see
> o.a.c.core.osgi.OSGiCoreServiceManager). This container has a parent
> container (o.a.c.core.osgi.OSGiServiceManager), that translates ECM
> lookups for components not defined in the block to OSGi service lookups
> that will get the components from another block.
>
> The OSGi services must be singletons, so ThreadSafe components can be
> exported and thanks to Carstens poolable proxy
> (o.a.c.core.container.handler.PoolableComponentHandler) also Poolable
> can be exported, but SingleThreadedComponents are not singltons and
> cannot be exported yet. For the components in cocoon-core.xconf all
> components could be exported except for FOM_JavaScriptInterpreter, the
> output modules and the PartSourceFactory, who are SingleThreaded.
>
> The question is how to solve it. Some of the SingleThreaded could
> probably be made ThreadSafe or Poolable, for the rest we could maybe
> have some kind of proxy. Ideas?
You export a singleton Factory that is used to get the object. I guess
we could have the ECM++ bridge say "if this is component implements
ThreadSafe, return it, if it implements ComponentFactory (or some such),
return an object from its getInstance() method."
That way the ThreadSafe/not ThreadSafe would remain transparent to users
of ECM++.
Reasonable? Or have I missed something?
Upayavira
Re: Components in blocks
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Sylvain Wallez wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> I have continued the work that Sylvain started on ECM++ - OSGi
>>> service bridge, and have some questions.
>>
>>
>> Great!
>>
>>> I start with a simpler one about component configuration. The idea
>>> is that the block.xml have an optional component section which
>>> declares the components that the block exports (see
>>> webapp/WEB-INF/block.xml for an example). One can use the attribute
>>> exported="false" for private components. The reason for not using
>>> the component section of the sitemap for declaring the components
>>> that the block exports is that blocks doesn't have to contain a
>>> sitemap, some are "component only" blocks.
>>>
>>> As the "sitemap components" of a block in most cases also should be
>>> exported, so that they can be used in other blocks, the components
>>> in the webapp sample sitemap and in WEB-INF/sitemap-additions also
>>> need to be included from the repective block.xml. As it is a waste
>>> of resources to declare them again in the container of the main
>>> sitemap of the blocks it means that I want to move all components of
>>> the main sitemap in the sample webapp and all components
>>> inWEB-INF/sitemap-additions to the respective WEB-INF/xconf. Is this
>>> OK, or are there any problems? If it is OK, I do it ASAP for the
>>> webapp samples.
>>
>>
>>
>>
>> Sounds reasonable, and won't change things much: components are kept
>> in a separate file, and it's just the include location that changes,
>> right?
>
>
> Right!
>
>>> --- o0o ---
>>>
>>> Another question is about ECM++ - OSGi service bridge. The idea with
>>> the bridge, as you might remeber, is that the the block has an ECM
>>> container that exports its components as OSGi services (see
>>> o.a.c.core.osgi.OSGiCoreServiceManager). This container has a parent
>>> container (o.a.c.core.osgi.OSGiServiceManager), that translates ECM
>>> lookups for components not defined in the block to OSGi service
>>> lookups that will get the components from another block.
>>>
>>> The OSGi services must be singletons, so ThreadSafe components can
>>> be exported and thanks to Carstens poolable proxy
>>> (o.a.c.core.container.handler.PoolableComponentHandler) also
>>> Poolable can be exported, but SingleThreadedComponents are not
>>> singltons and cannot be exported yet. For the components in
>>> cocoon-core.xconf all components could be exported except for
>>> FOM_JavaScriptInterpreter, the output modules and the
>>> PartSourceFactory, who are SingleThreaded.
>>
>>
>> I refactored PartSourceFactory it so that is is now ThreadSafe. I
>> also had a quick look at the output modules, and it seems that none
>> of them has a state, meaning they could be made ThreadSafe as well.
>
>
> They have a state, settings, in the abstract base class.
The "settings" Map is initialized in configure() which is part of the
Avalon creation methods. It's therefore not actual state, as it isn't
changed by any of the services methods. So they can be made ThreadSafe IMO.
>>> The question is how to solve it. Some of the SingleThreaded could
>>> probably be made ThreadSafe or Poolable, for the rest we could maybe
>>> have some kind of proxy. Ideas?
>>
>>
>> FOM_JavaScriptInterpreter must be kept SingleThreaded because,
>> although being actually reentrant, each sitemap must be given a
>> single instance. For this particular case, we can change to a factory
>> pattern, the factory being threadsafe.
>
>
> Can you give some more details about how?
Well, either we define a specific FlowInterpreterFactory interface, or
we define a generic factory service in ECM++, which will be analogous to
what already exists in both OSGi (ServiceFactory) and Spring (BeanFactory).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Components in blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
>
>> I have continued the work that Sylvain started on ECM++ - OSGi
>> service bridge, and have some questions.
>
> Great!
>
>> I start with a simpler one about component configuration. The idea is
>> that the block.xml have an optional component section which declares
>> the components that the block exports (see webapp/WEB-INF/block.xml
>> for an example). One can use the attribute exported="false" for
>> private components. The reason for not using the component section of
>> the sitemap for declaring the components that the block exports is
>> that blocks doesn't have to contain a sitemap, some are "component
>> only" blocks.
>>
>> As the "sitemap components" of a block in most cases also should be
>> exported, so that they can be used in other blocks, the components in
>> the webapp sample sitemap and in WEB-INF/sitemap-additions also need
>> to be included from the repective block.xml. As it is a waste of
>> resources to declare them again in the container of the main sitemap
>> of the blocks it means that I want to move all components of the main
>> sitemap in the sample webapp and all components
>> inWEB-INF/sitemap-additions to the respective WEB-INF/xconf. Is this
>> OK, or are there any problems? If it is OK, I do it ASAP for the
>> webapp samples.
>
>
>
> Sounds reasonable, and won't change things much: components are kept
> in a separate file, and it's just the include location that changes,
> right?
Right!
>> --- o0o ---
>>
>> Another question is about ECM++ - OSGi service bridge. The idea with
>> the bridge, as you might remeber, is that the the block has an ECM
>> container that exports its components as OSGi services (see
>> o.a.c.core.osgi.OSGiCoreServiceManager). This container has a parent
>> container (o.a.c.core.osgi.OSGiServiceManager), that translates ECM
>> lookups for components not defined in the block to OSGi service
>> lookups that will get the components from another block.
>>
>> The OSGi services must be singletons, so ThreadSafe components can be
>> exported and thanks to Carstens poolable proxy
>> (o.a.c.core.container.handler.PoolableComponentHandler) also Poolable
>> can be exported, but SingleThreadedComponents are not singltons and
>> cannot be exported yet. For the components in cocoon-core.xconf all
>> components could be exported except for FOM_JavaScriptInterpreter,
>> the output modules and the PartSourceFactory, who are SingleThreaded.
>
> I refactored PartSourceFactory it so that is is now ThreadSafe. I also
> had a quick look at the output modules, and it seems that none of them
> has a state, meaning they could be made ThreadSafe as well.
They have a state, settings, in the abstract base class.
>> The question is how to solve it. Some of the SingleThreaded could
>> probably be made ThreadSafe or Poolable, for the rest we could maybe
>> have some kind of proxy. Ideas?
>
> FOM_JavaScriptInterpreter must be kept SingleThreaded because,
> although being actually reentrant, each sitemap must be given a single
> instance. For this particular case, we can change to a factory
> pattern, the factory being threadsafe.
Can you give some more details about how?
/Daniel
Re: Components in blocks
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> I have continued the work that Sylvain started on ECM++ - OSGi service
> bridge, and have some questions.
Great!
> I start with a simpler one about component configuration. The idea is
> that the block.xml have an optional component section which declares
> the components that the block exports (see webapp/WEB-INF/block.xml
> for an example). One can use the attribute exported="false" for
> private components. The reason for not using the component section of
> the sitemap for declaring the components that the block exports is
> that blocks doesn't have to contain a sitemap, some are "component
> only" blocks.
>
> As the "sitemap components" of a block in most cases also should be
> exported, so that they can be used in other blocks, the components in
> the webapp sample sitemap and in WEB-INF/sitemap-additions also need
> to be included from the repective block.xml. As it is a waste of
> resources to declare them again in the container of the main sitemap
> of the blocks it means that I want to move all components of the main
> sitemap in the sample webapp and all components
> inWEB-INF/sitemap-additions to the respective WEB-INF/xconf. Is this
> OK, or are there any problems? If it is OK, I do it ASAP for the
> webapp samples.
Sounds reasonable, and won't change things much: components are kept in
a separate file, and it's just the include location that changes, right?
> --- o0o ---
>
> Another question is about ECM++ - OSGi service bridge. The idea with
> the bridge, as you might remeber, is that the the block has an ECM
> container that exports its components as OSGi services (see
> o.a.c.core.osgi.OSGiCoreServiceManager). This container has a parent
> container (o.a.c.core.osgi.OSGiServiceManager), that translates ECM
> lookups for components not defined in the block to OSGi service
> lookups that will get the components from another block.
>
> The OSGi services must be singletons, so ThreadSafe components can be
> exported and thanks to Carstens poolable proxy
> (o.a.c.core.container.handler.PoolableComponentHandler) also Poolable
> can be exported, but SingleThreadedComponents are not singltons and
> cannot be exported yet. For the components in cocoon-core.xconf all
> components could be exported except for FOM_JavaScriptInterpreter, the
> output modules and the PartSourceFactory, who are SingleThreaded.
I refactored PartSourceFactory it so that is is now ThreadSafe. I also
had a quick look at the output modules, and it seems that none of them
has a state, meaning they could be made ThreadSafe as well.
> The question is how to solve it. Some of the SingleThreaded could
> probably be made ThreadSafe or Poolable, for the rest we could maybe
> have some kind of proxy. Ideas?
FOM_JavaScriptInterpreter must be kept SingleThreaded because, although
being actually reentrant, each sitemap must be given a single instance.
For this particular case, we can change to a factory pattern, the
factory being threadsafe.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director