Re: New Features for the spring configurator
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
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
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
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
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
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
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
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
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
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
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
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.
