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
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
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
