You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2006/12/28 08:48:55 UTC
Problems with writing sitemap components as spring beans
In the last days I converted our FileGenerator from an Avalon based
component to a spring managed bean. With spring we have the advantage
that we don't need a special GeneratorFactory interface anymore. Spring
supports several ways of instantiation which is totally transparent to
the client code.
While implementing the FileGenerator I noticed a problem: how can we
configure sitemap specific stuff like the label or the mime-type for
spring managed beans?
The current avalon implementation has a special handling for sitemap
components and stores the label/mime-type information which is then
later used by the tree processor.
With spring we don't have such a mechanism.
Has anyone a good idea how to solve this?
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problems with writing sitemap components as spring beans
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.12.2006 10:41, Carsten Ziegeler wrote:
> Hmm, perhaps we could use the spring authoring functionality (like we do
> for setting up Cocoon) and provide some element (don't quote me on the
> syntax right now, this is just a rough idea):
> <bean name="my.pac.kage.NiceGenerator">
> ..<!-- Configuration -->..
> <cocoon:sitemap-component name="nice" label="content"/>
> </bean>
>
> I think this is possible by creating a proxy around the generator with
> the special sitemap support.
Something like this I had in mind :)
Jörg
Re: Problems with writing sitemap components as spring beans
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> After having looked at I think that the simplest solution would be to
> just provide one (singleton) info bean for each component. Something like:
>
> <util:map name="org.apache.cocoon.serialization.Serializer/xml/info">
> <entry key="mime-type" value="text/xml"/>
> <entry key="label" value="output"/>
> </util:map>
>
> <bean name="org.apache.cocoon.serialization.Serializer/xml"
> class="org.apache.cocoon.serialization.XMLSerializer"
> scope="prototype"
> parent="org.apache.cocoon.serialization.AbstractTextSerializer"/>
>
> Then the ProcessorComponentInfo can just look up the info from the
> container using <ComponentType>.ROLE/<hint>/info as key.
>
> If it is better to store the info in the ProcessorComponentInfo, we
> could have a bean factory that looks up the ProcessorComponentInfo (or
> create it if needed), and store the info there instead:
>
> <bean name="org.apache.cocoon.serialization.Serializer/xml/info"
>
> class="org.apache.cocoon.core.apropriate_sub_package.ProcessorComponentInfoBeanFactory">
> <property name="mimeType" value="text/xml"/>
> <property name="label" value="output"/>
> </bean/>
>
> In this case the bean name is parsed for finding out what sitemap the
> component info is about. We could combine any of the above solutions
> with a custom xml format if we like to get a "prettier"notation.
>
I think the first solution is the a little bit easier to implement and
does not require to much coding in xml for the configuration, so I think
we should go for the first solution.
If anyone has time to imlement it, we could think about adding our own
tags for this configuration, so this could look like this:
<bean name="org.apache.cocoon.serialization.Serializer/xml"
class="org.apache.cocoon.serialization.XMLSerializer"
scope="prototype">
<namespace:sitemap-component label="gg" mime-type="..."/>
This shouldn't be too hard.
> Whatever solution we use, the mechanism for being able to store the info
> must be part of the pipeline layer, so that we can configure the
> pipeline components there.
Yes, it would be good if we could move this stuff out of the current
avalon bridge!
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problems with writing sitemap components as spring beans
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>
>> Carsten Ziegeler skrev:
>>
>>> I think this is possible by creating a proxy around the generator with
>>> the special sitemap support.
>>>
>> Seem like a good solution.
>>
>> I've tried to find out how label handling for sitemap components is
>> solved now. But didn't found where in the code it is done, can you give
>> me a pointer?
>>
>>
> The avalon bridge provides a ProcessorComponentInfo for the tree
> processor. This bean is created in the AvalonElementParser in the
> registerComponentInfo method. It loops through all registered components
> and gets the label etc. configuration from the sitemap components and
> registers them in the processor component info bean.
>
> The tree processor looks up the ProcessorComponentInfo bean and provides
> the informationen to the various parts in the tree processor
>
Thanks for the info.
After having looked at I think that the simplest solution would be to
just provide one (singleton) info bean for each component. Something like:
<util:map name="org.apache.cocoon.serialization.Serializer/xml/info">
<entry key="mime-type" value="text/xml"/>
<entry key="label" value="output"/>
</util:map>
<bean name="org.apache.cocoon.serialization.Serializer/xml"
class="org.apache.cocoon.serialization.XMLSerializer"
scope="prototype"
parent="org.apache.cocoon.serialization.AbstractTextSerializer"/>
Then the ProcessorComponentInfo can just look up the info from the
container using <ComponentType>.ROLE/<hint>/info as key.
If it is better to store the info in the ProcessorComponentInfo, we
could have a bean factory that looks up the ProcessorComponentInfo (or
create it if needed), and store the info there instead:
<bean name="org.apache.cocoon.serialization.Serializer/xml/info"
class="org.apache.cocoon.core.apropriate_sub_package.ProcessorComponentInfoBeanFactory">
<property name="mimeType" value="text/xml"/>
<property name="label" value="output"/>
</bean/>
In this case the bean name is parsed for finding out what sitemap the
component info is about. We could combine any of the above solutions
with a custom xml format if we like to get a "prettier"notation.
Whatever solution we use, the mechanism for being able to store the info
must be part of the pipeline layer, so that we can configure the
pipeline components there.
WDYT?
/Daniel
Re: Problems with writing sitemap components as spring beans
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> I think this is possible by creating a proxy around the generator with
>> the special sitemap support.
>
> Seem like a good solution.
>
> I've tried to find out how label handling for sitemap components is
> solved now. But didn't found where in the code it is done, can you give
> me a pointer?
>
The avalon bridge provides a ProcessorComponentInfo for the tree
processor. This bean is created in the AvalonElementParser in the
registerComponentInfo method. It loops through all registered components
and gets the label etc. configuration from the sitemap components and
registers them in the processor component info bean.
The tree processor looks up the ProcessorComponentInfo bean and provides
the informationen to the various parts in the tree processor
HTH
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problems with writing sitemap components as spring beans
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Joerg Heinicke wrote:
>> The label has nothing to do with component configuration, so I'd avoid
>> putting it into the components.
>>
> Yes, you're right.
>
>>>> and the label is the name after the slash, in this case "mySerializer". It's not
>>>> the most elegant way but with C3 we can reconsider it.
>>>>
>>> The label is not the component name (or type) - the label is used for
>>> the cocoon-view feature, e.g. the file generator has the label "content".
>> Exactly. Isn't it possible to add some additional attribute cocoon:label
>> (or similar) and handle this in a special Cocoon BeanFactory? If there
>> is nothing like that I wonder how you want to manage pipeline specific
>> data at all. It would probably be necessary to extend the component
>> interfaces with additional methods for retrieving such attributes (e.g.
>> getLabel()).
>>
> Hmm, perhaps we could use the spring authoring functionality (like we do
> for setting up Cocoon) and provide some element (don't quote me on the
> syntax right now, this is just a rough idea):
> <bean name="my.pac.kage.NiceGenerator">
> ..<!-- Configuration -->..
> <cocoon:sitemap-component name="nice" label="content"/>
> </bean>
>
> I think this is possible by creating a proxy around the generator with
> the special sitemap support.
Seem like a good solution.
I've tried to find out how label handling for sitemap components is
solved now. But didn't found where in the code it is done, can you give
me a pointer?
/Daniel
Re: Problems with writing sitemap components as spring beans
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke wrote:
>
> The label has nothing to do with component configuration, so I'd avoid
> putting it into the components.
>
Yes, you're right.
>>> and the label is the name after the slash, in this case "mySerializer". It's not
>>> the most elegant way but with C3 we can reconsider it.
>>>
>> The label is not the component name (or type) - the label is used for
>> the cocoon-view feature, e.g. the file generator has the label "content".
>
> Exactly. Isn't it possible to add some additional attribute cocoon:label
> (or similar) and handle this in a special Cocoon BeanFactory? If there
> is nothing like that I wonder how you want to manage pipeline specific
> data at all. It would probably be necessary to extend the component
> interfaces with additional methods for retrieving such attributes (e.g.
> getLabel()).
>
Hmm, perhaps we could use the spring authoring functionality (like we do
for setting up Cocoon) and provide some element (don't quote me on the
syntax right now, this is just a rough idea):
<bean name="my.pac.kage.NiceGenerator">
..<!-- Configuration -->..
<cocoon:sitemap-component name="nice" label="content"/>
</bean>
I think this is possible by creating a proxy around the generator with
the special sitemap support.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problems with writing sitemap components as spring beans
Posted by Joerg Heinicke <jo...@gmx.de>.
On 28.12.2006 09:36, Carsten Ziegeler wrote:
>> What's wrong with property injection?
>
> The current sitemap features do not require the component implementation
> to have support for a mime-type (or a label), so they don't need to have
> a property for that.
> We could use properties for that, with the (minimal) cost of forcing
> each implementation to take care of it.
The label has nothing to do with component configuration, so I'd avoid
putting it into the components.
>> and the label is the name after the slash, in this case "mySerializer". It's not
>> the most elegant way but with C3 we can reconsider it.
>>
> The label is not the component name (or type) - the label is used for
> the cocoon-view feature, e.g. the file generator has the label "content".
Exactly. Isn't it possible to add some additional attribute cocoon:label
(or similar) and handle this in a special Cocoon BeanFactory? If there
is nothing like that I wonder how you want to manage pipeline specific
data at all. It would probably be necessary to extend the component
interfaces with additional methods for retrieving such attributes (e.g.
getLabel()).
Jörg
Re: Problems with writing sitemap components as spring beans
Posted by Simone Gianni <si...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>
>> we could provide an abstract parent bean definition
>> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-child-bean-definitions).
>>
>>
> Yes, but this would also mean that all implementations inherit from an
> abstract class we provide. This is not a big deal, I guess we can live
> with that.
>
IIRC this is not *required* (thought is convenient in many cases). In an
abstract bean definition you can declare only a property, only the
class, only a factory method or any mix of the preceding and something
more. Obviously if you say that there is a property named "thatStuff",
it will search for setThatStuff, but that could be in a common interface
and does not require that every subclass extends the same abstract base
class.
Simone
Re: Problems with writing sitemap components as spring beans
Posted by Carsten Ziegeler <cz...@apache.org>.
Simone Gianni wrote:
> Carsten Ziegeler wrote:
>> So far, I've only seen people using labels for debugging pipelines which
>> is really not what it was intended for (I think we should provide a
>> better alternative for debugging pipelines anyway). If it would be me,
>> we could forget about views completly (they are not inherited to sub
>> sitemaps, can easily be a security problem etc.)
>>
> +1 for dropping views, they are only used for debugging or for other
> small tricks for which writing another matcher is better, they introduce
> some security risks, and also have some strange behaviors with cocoon://
> calls and subsitemaps.
>
> Anyway, for debugging, is the great profiling processing pipeline dead?
> because for debugging that was by far better than views, and was in
> general a very good piece of software and among the most useful and less
> used features in cocoon!!
>
It's still there and should work.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problems with writing sitemap components as spring beans
Posted by Simone Gianni <si...@apache.org>.
Carsten Ziegeler wrote:
> So far, I've only seen people using labels for debugging pipelines which
> is really not what it was intended for (I think we should provide a
> better alternative for debugging pipelines anyway). If it would be me,
> we could forget about views completly (they are not inherited to sub
> sitemaps, can easily be a security problem etc.)
>
+1 for dropping views, they are only used for debugging or for other
small tricks for which writing another matcher is better, they introduce
some security risks, and also have some strange behaviors with cocoon://
calls and subsitemaps.
Anyway, for debugging, is the great profiling processing pipeline dead?
because for debugging that was by far better than views, and was in
general a very good piece of software and among the most useful and less
used features in cocoon!!
Simone
Re: Problems with writing sitemap components as spring beans
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> we could provide an abstract parent bean definition
> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-child-bean-definitions).
>
Yes, but this would also mean that all implementations inherit from an
abstract class we provide. This is not a big deal, I guess we can live
with that.
>>> and the label is the name after the slash, in this case "mySerializer". It's not
>>> the most elegant way but with C3 we can reconsider it.
>>>
>> The label is not the component name (or type) - the label is used for
>> the cocoon-view feature, e.g. the file generator has the label "content".
>
> argh, right. I could live without it as I always define labels within pipelines.
> But I guess that in more complicated setups this could be impractical, right?
>
So far, I've only seen people using labels for debugging pipelines which
is really not what it was intended for (I think we should provide a
better alternative for debugging pipelines anyway). If it would be me,
we could forget about views completly (they are not inherited to sub
sitemaps, can easily be a security problem etc.)
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problems with writing sitemap components as spring beans
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> What's wrong with property injection? (I'm asking because you certainly know
>> about it ;-) ):
>>
>> <bean name="o.a.c.s.s/mySerializer">
>> <property name="mime-type" value="text/xml"/>
>> </bean>
>
> The current sitemap features do not require the component implementation
> to have support for a mime-type (or a label), so they don't need to have
> a property for that.
> We could use properties for that, with the (minimal) cost of forcing
> each implementation to take care of it.
we could provide an abstract parent bean definition
(http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-child-bean-definitions).
>> and the label is the name after the slash, in this case "mySerializer". It's not
>> the most elegant way but with C3 we can reconsider it.
>>
> The label is not the component name (or type) - the label is used for
> the cocoon-view feature, e.g. the file generator has the label "content".
argh, right. I could live without it as I always define labels within pipelines.
But I guess that in more complicated setups this could be impractical, right?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Problems with writing sitemap components as spring beans
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> What's wrong with property injection? (I'm asking because you certainly know
> about it ;-) ):
>
> <bean name="o.a.c.s.s/mySerializer">
> <property name="mime-type" value="text/xml"/>
> </bean>
The current sitemap features do not require the component implementation
to have support for a mime-type (or a label), so they don't need to have
a property for that.
We could use properties for that, with the (minimal) cost of forcing
each implementation to take care of it.
>
> and the label is the name after the slash, in this case "mySerializer". It's not
> the most elegant way but with C3 we can reconsider it.
>
The label is not the component name (or type) - the label is used for
the cocoon-view feature, e.g. the file generator has the label "content".
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problems with writing sitemap components as spring beans
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> In the last days I converted our FileGenerator from an Avalon based
> component to a spring managed bean. With spring we have the advantage
> that we don't need a special GeneratorFactory interface anymore. Spring
> supports several ways of instantiation which is totally transparent to
> the client code.
>
> While implementing the FileGenerator I noticed a problem: how can we
> configure sitemap specific stuff like the label or the mime-type for
> spring managed beans?
>
> The current avalon implementation has a special handling for sitemap
> components and stores the label/mime-type information which is then
> later used by the tree processor.
>
> With spring we don't have such a mechanism.
>
> Has anyone a good idea how to solve this?
What's wrong with property injection? (I'm asking because you certainly know
about it ;-) ):
<bean name="o.a.c.s.s/mySerializer">
<property name="mime-type" value="text/xml"/>
</bean>
and the label is the name after the slash, in this case "mySerializer". It's not
the most elegant way but with C3 we can reconsider it.
--
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