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 2007/02/23 14:23:04 UTC
New Features for the spring configurator
Hi,
in the last days while converting the portal block from spring to avalon
I added two features to our spring configurator:
1. It's now possible to define default values for properties directly in
the property reference, so you can write a reference to the property
"myproperty" like this: ${myproperty:DEFAULT_VALUE}. If no definition
for the property is found, the default value is used. Of course, it's
possible to use ${myproperty} as well.
2. A new map implementation that collects all defined spring beans
implementing a specified type, so you configure a managing component
like this:
<bean id="mycomponent" class="myclass">
<property name="widgets">
<configurator:bean-map type="o.a.c.Widget"/>
</property>
</bean>
The bean-map element collects all beans for the specified type
(o.a.c.Widget) in this case and creates a Map with the id's of the beans
as keys and the beans itself as the value.
In addition if the bean name starts with the type, like
"o.a.c.Widget/button", the bean will be put under the key "button" into
the Map. (This behaviour can be controlled via an additional attribute).
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: New Features for the spring configurator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>
>> The perfect situation for me would be to have a
>> ProfileAwarePropertyPlaceholderConfigurer that could be used like that:
>>
>>> <bean id="placeholderConfig" class="org.apache.cocoon.spring.ProfileAwarePropertyPlaceholderConfigurer">
>>> <property name="runningMode" value="${org.apache.cocoon.mode}"/>
>>> </bean>
>> and running the application with -Dorg.apache.cocoon.mode=dev
>>
>> Is there any chance that this functionality could be separated? It would
>> be even better if this code was directly ported to spring framework.
>>
> Ah, ok I see, this is possible:
>
> <bean id="placeholderConfig"
> class="org.apache.cocoon.spring.configurator.SettingsBeanFactoryPostProcessor"
> init-method="init">
> <property name="runningMode" value="${org.apache.cocoon.mode}"/>
> </bean>
>
> You can even skip the runningMode property, it uses the system property
> by default.
Don't I have to create a Settings bean somewhere?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: New Features for the spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>
> The perfect situation for me would be to have a
> ProfileAwarePropertyPlaceholderConfigurer that could be used like that:
>
>> <bean id="placeholderConfig" class="org.apache.cocoon.spring.ProfileAwarePropertyPlaceholderConfigurer">
>> <property name="runningMode" value="${org.apache.cocoon.mode}"/>
>> </bean>
> and running the application with -Dorg.apache.cocoon.mode=dev
>
> Is there any chance that this functionality could be separated? It would
> be even better if this code was directly ported to spring framework.
>
Ah, ok I see, this is possible:
<bean id="placeholderConfig"
class="org.apache.cocoon.spring.configurator.SettingsBeanFactoryPostProcessor"
init-method="init">
<property name="runningMode" value="${org.apache.cocoon.mode}"/>
</bean>
You can even skip the runningMode property, it uses the system property
by default.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: New Features for the spring configurator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
>> So my idea was to start simple and extend the functionality if needed.
>> First step was to always include all configurations, the next step will
>> be to disable this. I'll update the code today.
>>
> Ok, forget most of the stuff I said above, you can disable the inclusion
> by specifying the "readFromClasspath" attribute on the settings element:
>
> <configurator:settings readFromClasspath="false"/>
I was thinking about something different:
1. Sometimes I do not need to automatically include all application
contexts from META-INF/cocoon/spring/*, because I do specify them
manually...
2. ... Still I would like to use property overrider and it's running modes.
Example: unit tests, I do not need any cocoon components (even do not
want to instantiate them because of prolonged test runs). Even so my
beans need properties and running profiles.
I am using a separate context file outside META-INF/cocoon/spring for
unit tests:
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> <bean id="placeholderConfig" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> <property name="locations" value="classpath*:META-INF/cocoon/properties/*.properties"/>
> </bean>
> </beans>
I cannot use running mode like this, and even trying to emulate it:
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> <bean id="placeholderConfig" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> <property name="locations" value="classpath*:META-INF/cocoon/properties/*.properties"/>
> </bean>
> <bean id="placeholderConfigDev" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> <property name="locations" value="classpath*:META-INF/cocoon/properties/dev/*.properties"/>
> </bean>
> </beans>
simply does not work. Spring behaves like the second
PropertyPlaceholderConfigurer is not there.
The perfect situation for me would be to have a
ProfileAwarePropertyPlaceholderConfigurer that could be used like that:
> <bean id="placeholderConfig" class="org.apache.cocoon.spring.ProfileAwarePropertyPlaceholderConfigurer">
> <property name="runningMode" value="${org.apache.cocoon.mode}"/>
> </bean>
and running the application with -Dorg.apache.cocoon.mode=dev
Is there any chance that this functionality could be separated? It would
be even better if this code was directly ported to spring framework.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: New Features for the spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
> controlled via an additional attribute).
>> I have been trying to use configurator outside cocoon for my other
>> spring based projects. Thing is the configurator automatically imports
>> property files and contexts in META-INF/cocoon/spring. What should I do
>> to have limit it's functionality to properties?
>>
> Currently, you have no way to specify this. You can exclude reading the
> properties from the various locations, but not the beans.
>
> I was always wondering if we need such a configuration or not. If we
> would have a clean separation between api and impl, you would never
> include a jar containing an impl (and META-INF/cocoon/spring
> configuration files) if you don't need these components. At least we
> could argue that this is a good theory. In addition, as soon as you
> think about disabling the automatic include of spring configuration
> files, you will have the use case were you want to include most of them
> automatically but not a specific one. Which of course leads to a
> configuration possibility of excludes and includes.
>
> So my idea was to start simple and extend the functionality if needed.
> First step was to always include all configurations, the next step will
> be to disable this. I'll update the code today.
>
Ok, forget most of the stuff I said above, you can disable the inclusion
by specifying the "readFromClasspath" attribute on the settings element:
<configurator:settings readFromClasspath="false"/>
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: New Features for the spring configurator
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>>> Hmm, yes and no :) Our xslt transformer implementation uses an xslt
>>> processor. So we can define a "static" xalan xslt processor together
>>> with a "static" xalan xslt transformer.
>> And this works because when the processor bean is created by Spring there is no
>> need to have Xalan on the classpath. Right?
>>
> Hmm, no :) If Xalan would not be on the classpath I guess the xslt
> processor would fail. But as Xalan is always included in the jdk, it's
> always available (of course this might be different with different jdks).
> So, if we provide a "static" xalan xslt processor/xslt transformer
> combo, Xalan has to be on the classpath. However, we could implement
> these beans in a way that they don't fail during
> initialization/configuration if Xalan is not available. They would fail
> when they're used. But I'm in favour of fail early here.
I was mislead by the Saxon configuration which is already part of
cocoon-pipeline-components. I overlooked that it is commented out.
And, agreed to "fail early" here.
>>> And we can define a "dynamic" xslt processor (configured through
>>> properties) with an xslt transformer always using this "dynamic" xslt
>>> processor.
>> If it was a Spring bean we could even use the PropertyOverrideConfigurer instead
>> of introducing a new property.
>>
>> Would it be difficult to convert the TraxProcessor into a Spring bean? As it
>> hasn't been done yet I guess that there is this or that difficulty involved,
>> isn't it.
> The TraxProcessor uses the source resolver to resolve included/imported
> stuff and to
> handle xslt changes checks. We could convert the processor to a spring
> bean and simply
> referene the source resolver. It shouldn't be that hard.
> I think I'll have a look at this.
Thanks Carsten. My next item on my Cocoon 2.2 list is working on the
documentation again but then I think I will factor out Xalan into a separate
core module in order to avoid shipping a 2.7mb library with my applications that
would be unused.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: New Features for the spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>> Hmm, yes and no :) Our xslt transformer implementation uses an xslt
>> processor. So we can define a "static" xalan xslt processor together
>> with a "static" xalan xslt transformer.
>
> And this works because when the processor bean is created by Spring there is no
> need to have Xalan on the classpath. Right?
>
Hmm, no :) If Xalan would not be on the classpath I guess the xslt
processor would fail. But as Xalan is always included in the jdk, it's
always available (of course this might be different with different jdks).
So, if we provide a "static" xalan xslt processor/xslt transformer
combo, Xalan has to be on the classpath. However, we could implement
these beans in a way that they don't fail during
initialization/configuration if Xalan is not available. They would fail
when they're used. But I'm in favour of fail early here.
>> And we can define a "dynamic" xslt processor (configured through
>> properties) with an xslt transformer always using this "dynamic" xslt
>> processor.
>
> If it was a Spring bean we could even use the PropertyOverrideConfigurer instead
> of introducing a new property.
>
> Would it be difficult to convert the TraxProcessor into a Spring bean? As it
> hasn't been done yet I guess that there is this or that difficulty involved,
> isn't it.
The TraxProcessor uses the source resolver to resolve included/imported
stuff and to
handle xslt changes checks. We could convert the processor to a spring
bean and simply
referene the source resolver. It shouldn't be that hard.
I think I'll have a look at this.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: New Features for the spring configurator
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> Carsten Ziegeler wrote:
>>> Reinhard Poetz wrote:
>>>> I wanted to write a mail about this today, funny. My usecase is that I want to
>>>> replace Xalan by Saxon.
>>>>
>>>> Am I right that creating a cocoon-xalan module would be the best solution for
>>>> this because it would make it possible to exclude it at POM level.
>>>>
>>> Yes, this is one solution :) Making an own module for both, Xalan and
>>> Saxon, has the advantage that this module would depend on Xalan or Saxon
>>> and then you get these libraries automatically in your project as well.
>>>
>>> If it's just a configuration issue, like setting a specific value for a
>>> bean, then we could just provide a property reference. Which means, if
>>> switching from Xalan to Saxon is just changing the name of the factory,
>>> we could just make the factory configurable through a well-defined property.
>> This would work if we hadn't the "xalan" transformer, wouldn't it?
>>
> Hmm, yes and no :) Our xslt transformer implementation uses an xslt
> processor. So we can define a "static" xalan xslt processor together
> with a "static" xalan xslt transformer.
And this works because when the processor bean is created by Spring there is no
need to have Xalan on the classpath. Right?
> And we can define a "dynamic" xslt processor (configured through
> properties) with an xslt transformer always using this "dynamic" xslt
> processor.
If it was a Spring bean we could even use the PropertyOverrideConfigurer instead
of introducing a new property.
Would it be difficult to convert the TraxProcessor into a Spring bean? As it
hasn't been done yet I guess that there is this or that difficulty involved,
isn't it.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: New Features for the spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Reinhard Poetz wrote:
>>> I wanted to write a mail about this today, funny. My usecase is that I want to
>>> replace Xalan by Saxon.
>>>
>>> Am I right that creating a cocoon-xalan module would be the best solution for
>>> this because it would make it possible to exclude it at POM level.
>>>
>> Yes, this is one solution :) Making an own module for both, Xalan and
>> Saxon, has the advantage that this module would depend on Xalan or Saxon
>> and then you get these libraries automatically in your project as well.
>>
>> If it's just a configuration issue, like setting a specific value for a
>> bean, then we could just provide a property reference. Which means, if
>> switching from Xalan to Saxon is just changing the name of the factory,
>> we could just make the factory configurable through a well-defined property.
>
> This would work if we hadn't the "xalan" transformer, wouldn't it?
>
Hmm, yes and no :) Our xslt transformer implementation uses an xslt
processor. So we can define a "static" xalan xslt processor together
with a "static" xalan xslt transformer.
And we can define a "dynamic" xslt processor (configured through
properties) with an xslt transformer always using this "dynamic" xslt
processor.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: New Features for the spring configurator
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> I wanted to write a mail about this today, funny. My usecase is that I want to
>> replace Xalan by Saxon.
>>
>> Am I right that creating a cocoon-xalan module would be the best solution for
>> this because it would make it possible to exclude it at POM level.
>>
> Yes, this is one solution :) Making an own module for both, Xalan and
> Saxon, has the advantage that this module would depend on Xalan or Saxon
> and then you get these libraries automatically in your project as well.
>
> If it's just a configuration issue, like setting a specific value for a
> bean, then we could just provide a property reference. Which means, if
> switching from Xalan to Saxon is just changing the name of the factory,
> we could just make the factory configurable through a well-defined property.
This would work if we hadn't the "xalan" transformer, wouldn't it?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: New Features for the spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> I wanted to write a mail about this today, funny. My usecase is that I want to
> replace Xalan by Saxon.
>
> Am I right that creating a cocoon-xalan module would be the best solution for
> this because it would make it possible to exclude it at POM level.
>
Yes, this is one solution :) Making an own module for both, Xalan and
Saxon, has the advantage that this module would depend on Xalan or Saxon
and then you get these libraries automatically in your project as well.
If it's just a configuration issue, like setting a specific value for a
bean, then we could just provide a property reference. Which means, if
switching from Xalan to Saxon is just changing the name of the factory,
we could just make the factory configurable through a well-defined property.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: New Features for the spring configurator
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
> controlled via an additional attribute).
>> I have been trying to use configurator outside cocoon for my other
>> spring based projects. Thing is the configurator automatically imports
>> property files and contexts in META-INF/cocoon/spring. What should I do
>> to have limit it's functionality to properties?
>>
> Currently, you have no way to specify this. You can exclude reading the
> properties from the various locations, but not the beans.
>
> I was always wondering if we need such a configuration or not. If we
> would have a clean separation between api and impl, you would never
> include a jar containing an impl (and META-INF/cocoon/spring
> configuration files) if you don't need these components. At least we
> could argue that this is a good theory. In addition, as soon as you
> think about disabling the automatic include of spring configuration
> files, you will have the use case were you want to include most of them
> automatically but not a specific one. Which of course leads to a
> configuration possibility of excludes and includes.
>
> So my idea was to start simple and extend the functionality if needed.
> First step was to always include all configurations, the next step will
> be to disable this. I'll update the code today.
I wanted to write a mail about this today, funny. My usecase is that I want to
replace Xalan by Saxon.
Am I right that creating a cocoon-xalan module would be the best solution for
this because it would make it possible to exclude it at POM level.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: New Features for the spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
controlled via an additional attribute).
>
> I have been trying to use configurator outside cocoon for my other
> spring based projects. Thing is the configurator automatically imports
> property files and contexts in META-INF/cocoon/spring. What should I do
> to have limit it's functionality to properties?
>
Currently, you have no way to specify this. You can exclude reading the
properties from the various locations, but not the beans.
I was always wondering if we need such a configuration or not. If we
would have a clean separation between api and impl, you would never
include a jar containing an impl (and META-INF/cocoon/spring
configuration files) if you don't need these components. At least we
could argue that this is a good theory. In addition, as soon as you
think about disabling the automatic include of spring configuration
files, you will have the use case were you want to include most of them
automatically but not a specific one. Which of course leads to a
configuration possibility of excludes and includes.
So my idea was to start simple and extend the functionality if needed.
First step was to always include all configurations, the next step will
be to disable this. I'll update the code today.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: New Features for the spring configurator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Hi,
>
> in the last days while converting the portal block from spring to avalon
> I added two features to our spring configurator:
>
> 1. It's now possible to define default values for properties directly in
> the property reference, so you can write a reference to the property
> "myproperty" like this: ${myproperty:DEFAULT_VALUE}. If no definition
> for the property is found, the default value is used. Of course, it's
> possible to use ${myproperty} as well.
>
> 2. A new map implementation that collects all defined spring beans
> implementing a specified type, so you configure a managing component
> like this:
>
> <bean id="mycomponent" class="myclass">
> <property name="widgets">
> <configurator:bean-map type="o.a.c.Widget"/>
> </property>
> </bean>
>
> The bean-map element collects all beans for the specified type
> (o.a.c.Widget) in this case and creates a Map with the id's of the beans
> as keys and the beans itself as the value.
> In addition if the bean name starts with the type, like
> "o.a.c.Widget/button", the bean will be put under the key "button" into
> the Map. (This behaviour can be controlled via an additional attribute).
I have been trying to use configurator outside cocoon for my other
spring based projects. Thing is the configurator automatically imports
property files and contexts in META-INF/cocoon/spring. What should I do
to have limit it's functionality to properties?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.