[
https://issues.apache.org/jira/browse/COCOON-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nico Verwer updated COCOON-2297:
Affects Version/s: 2.1.13
> Character encoding does not follow JTidy propert
Thank you Thorsten,
after a lot of integration hazzle,
I decided to keep the cocoon sitemap out of the Wicket application,
only using in the application a programmed pipeline returning back
wicket-conform Output.
At the moment I use a pipeline with a JAXBgenerator a Transformer and a
You find the docu about it in
http://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
specially the part
http://cocoon.apache.org/subprojects/configuration/spring-configurator/1310_1_1.html
where the properties matching is explained in detail.
In short I guess you do
the filtering and replacing the properties.
However in our latest project we have dropped a bit the configuration of
cocoon in terms of properties from
META-INF/cocoon/properties/xxx.properties and use a central place for
the configuration. This allows to use the project specific properties in
a wide range
[
https://issues.apache.org/jira/browse/COCOON-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Scherler reassigned COCOON-:
-
Assignee: Thorsten Scherler
Add SaxParser configuration properties
1381963.
Add SaxParser configuration properties
--
Key: COCOON-
URL: https://issues.apache.org/jira/browse/COCOON-
Project: Cocoon
Issue Type: Improvement
Components
On 03/02/2012 09:27 AM, Francesco Chicchiriccò wrote:
On 01/03/2012 18:41, Thorsten Scherler wrote:
Hi all,
we are using the i18n transformer in our app but now we need to add
xhtml tags in the resource bundle. However I tried with
message.test2 = This is h2message.test3/h2
message.test3 =
On 01/03/2012 18:41, Thorsten Scherler wrote:
Hi all,
we are using the i18n transformer in our app but now we need to add
xhtml tags in the resource bundle. However I tried with
message.test2 = This is h2message.test3/h2
message.test3 = This is lt;h2gt;message.test4lt;/h2gt;
but the
correct to include markup in
a language catalog? Would this mean that markup is language-dependent?
In JSTL resource bundle tags (spring:message, fmt:message) you often have
options to not XML-escape the properties. It's cleaner to separate the
markup from the message, but sometimes it can be a PITA
Hi all,
we are using the i18n transformer in our app but now we need to add
xhtml tags in the resource bundle. However I tried with
message.test2 = This is h2message.test3/h2
message.test3 = This is lt;h2gt;message.test4lt;/h2gt;
but the problem is that is does not get parsed correctly.
Can
. Sorry for the confusion.
Are there still committers for Cocoon 2.1 who are willing to pick this up?
Character encoding does not follow JTidy properties
---
Key: COCOON-2297
URL: https://issues.apache.org/jira/browse
Character encoding does not follow JTidy properties
---
Key: COCOON-2297
URL: https://issues.apache.org/jira/browse/COCOON-2297
Project: Cocoon
Issue Type: Bug
Components: Blocks
does not follow JTidy properties
---
Key: COCOON-2297
URL: https://issues.apache.org/jira/browse/COCOON-2297
Project: Cocoon
Issue Type: Bug
Components: Blocks: HTML
Affects
-context from the parent POM.
Four pom.xml files contain duplicate dependencies or deprecated properties.
---
Key: COCOON3-49
URL: https://issues.apache.org/jira/browse/COCOON3-49
duplicate dependencies or deprecated properties.
---
Key: COCOON3-49
URL: https://issues.apache.org/jira/browse/COCOON3-49
Project: Cocoon 3
Issue Type: Bug
:
---
Patch applied, except removing spring-context from the parent POM which broke
my build.
was (Author: reinh...@apache.org):
Patch applied, except removing spring-context from the parent POM.
Four pom.xml files contain duplicate dependencies or deprecated properties
Four pom.xml files contain duplicate dependencies or deprecated properties.
---
Key: COCOON3-49
URL: https://issues.apache.org/jira/browse/COCOON3-49
Project: Cocoon 3
or deprecated properties.
---
Key: COCOON3-49
URL: https://issues.apache.org/jira/browse/COCOON3-49
Project: Cocoon 3
Issue Type: Bug
Components: cocoon
.
Example:
map:generate src=file://${repository.dir.flyerdefinitions}/{1}.xml
file:///\\$%7brepository.dir.flyerdefinitions%7d\%7b1%7d.xml /
So I created following property file in
/META-INF/cocoon/properties/application.properties
repository.dir=D:/_testdata_
=file://${repository.dir.flyerdefinitions}/{1}.xml
file:///\\$%7brepository.dir.flyerdefinitions%7d\%7b1%7d.xml /
So I created following property file in
/META-INF/cocoon/properties/application.properties
repository.dir=D:/testdata
repository.dir.released=${repository.dir}/XML Repository
Add SaxParser configuration properties
--
Key: COCOON-
URL: https://issues.apache.org/jira/browse/COCOON-
Project: Cocoon
Issue Type: Improvement
Components: * Cocoon Core
Affects
[
https://issues.apache.org/jira/browse/COCOON-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Wyles updated COCOON-:
Attachment: sax-parser-config.patch
Patch adds configuration properties
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
I've just started to move the deployment of blocks into a
ServletContextListener and came across a (for me) unkown feature that
gives access to the path of blocks in Spring properties:
This feature was introduced by Carsten as part of this SVN
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
I've just started to move the deployment of blocks into a
ServletContextListener and came across a (for me) unkown feature that
gives access to the path of blocks in Spring properties:
This feature was introduced
I've just started to move the deployment of blocks into a ServletContextListener
and came across a (for me) unkown feature that gives access to the path of
blocks in Spring properties:
This feature was introduced by Carsten as part of this SVN commit
http://cocoon.markmail.org/message
Reinhard Poetz wrote:
I've just started to move the deployment of blocks into a
ServletContextListener and came across a (for me) unkown feature that
gives access to the path of blocks in Spring properties:
This feature was introduced by Carsten as part of this SVN commit
http
Giacomo Pati wrote:
On Fri, 29 Dec 2006, Carsten Ziegeler wrote:
I removed the factory :) as it is not needed anymore. We use Spring as
the factory and spring generates new FileGenerators for us. So the
FileGenerator from trunk is a spring managed bean and not an avalon
component anymore.
On Fri, 29 Dec 2006, Carsten Ziegeler wrote:
I removed the factory :) as it is not needed anymore. We use Spring as
the factory and spring generates new FileGenerators for us. So the
FileGenerator from trunk is a spring managed bean and not an avalon
component anymore.
IIRC Spring doesn't
Ralph Goers wrote:
Carsten Ziegeler wrote:
I removed the factory :) as it is not needed anymore. We use Spring as
the factory and spring generates new FileGenerators for us. So the
FileGenerator from trunk is a spring managed bean and not an avalon
component anymore.
So that means the
In the last months we changed the handling of properties and
configurations files several times.
The current implementation is a clean solution which reads configuration
files from the classpath. While this is a very nice solution, especially
for distributing components, it has the drawback
Carsten Ziegeler wrote:
In the last months we changed the handling of properties and
configurations files several times.
The current implementation is a clean solution which reads configuration
files from the classpath. While this is a very nice solution, especially
for distributing components
Reinhard Poetz schrieb:
Carsten Ziegeler wrote:
In the last months we changed the handling of properties and
configurations files several times.
The current implementation is a clean solution which reads configuration
files from the classpath. While this is a very nice solution, especially
like they are in
2.1. I see that the store sizes have been set up to do this, but
everything in 2.1's src/webapp/WEB-INF/properties/core.properties needs
to also be reflected in trunk, unless they no longer apply.
Speaking of pooling, (well, we weren't really, but I don't want to start
Carsten Ziegeler wrote:
In the last months we changed the handling of properties and
configurations files several times.
The current implementation is a clean solution which reads configuration
files from the classpath. While this is a very nice solution, especially
for distributing components
. The question is if we want to provide this
extra location or not?
I'm in the not camp. Starting with 2.2 there shouldn't be any Cocoon
applications anymore that are not developed as blocks. The only
exception from this rule of decentralization is Spring properties in
WEB-INF/cocoon/spring
Luca Morandini wrote:
Carsten Ziegeler wrote:
In the last months we changed the handling of properties and
configurations files several times.
The current implementation is a clean solution which reads configuration
files from the classpath. While this is a very nice solution, especially
. These values should all be parameterized like they are in
2.1. I see that the store sizes have been set up to do this, but
everything in 2.1's src/webapp/WEB-INF/properties/core.properties needs
to also be reflected in trunk, unless they no longer apply.
I agree, we should use the same properties from
I tend to agree with Luca on this, so I would like to add support for
reading properties from
WEB-INF/cocoon/properties/*.properties
and
WEB-INF/cocoon/spring/*.properties
again (of course with additional support of running modes).
If noone is against it, I'll add it in the next days.
I think
this is not the deal. The question is if we want to provide this
extra location or not?
I'm in the not camp. Starting with 2.2 there shouldn't be any Cocoon
applications anymore that are not developed as blocks. The only
exception from this rule of decentralization is Spring properties in
WEB-INF
Carsten Ziegeler wrote:
I tend to agree with Luca on this, so I would like to add support for
reading properties from
WEB-INF/cocoon/properties/*.properties
and
WEB-INF/cocoon/spring/*.properties
at least this works for me (otherwise the RCL plugin couldn't work).
again (of course
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
I tend to agree with Luca on this, so I would like to add support for
reading properties from
WEB-INF/cocoon/properties/*.properties
and
WEB-INF/cocoon/spring/*.properties
at least this works for me (otherwise the RCL plugin couldn't work
this is not the deal. The question is if we want to provide this
extra location or not?
I'm in the not camp. Starting with 2.2 there shouldn't be any Cocoon
applications anymore that are not developed as blocks. The only
exception from this rule of decentralization is Spring properties in
WEB-INF
Carsten Ziegeler wrote:
I removed the factory :) as it is not needed anymore. We use Spring as
the factory and spring generates new FileGenerators for us. So the
FileGenerator from trunk is a spring managed bean and not an avalon
component anymore.
So that means the components are no longer
Ralph Goers wrote:
Luca Morandini wrote:
So, the chain you propose is (sorted by order of loading):
1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff).
2) WEB-INF/classes/cocoon/properties (project-wide stuf).
In truth, I don't find the use of classes for configuration stuff
/webapp/WEB-INF/lib/cocoon-core-2.2.0-M3-SNAPSHOT.jar!/META-INF/cocoon/properties/cocoon-core-store.properties]
2) file
[C:\projects\analytics\blocks\cocoon-trunk\build\webapp\WEB-INF\classes\META-INF\cocoon\properties\core.properties]
3) URL
[jar:file:/C:/projects/analytics/blocks/cocoon-trunk
Ralph Goers schrieb:
Luca Morandini wrote:
So, the chain you propose is (sorted by order of loading):
1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff).
2) WEB-INF/classes/cocoon/properties (project-wide stuf).
In truth, I don't find the use of classes for configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Have a look at the core.properties file in the cocoon-core module. Just
put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should
Giacomo Pati wrote:
This raises the question if we need this? I think we should readd the
support for reading properties from WEB-INF/cocoon/properties.
IIRC we mentioned putting those into
WEB-INF/classes/META-INF/cocoon/properties
Yes, you're absolutely right! This brings back my
Luca Morandini wrote:
Remember to update the comments in the source code of
SettingsBeanFactoryPostProcessor.java then, because they still state
that WEB-INF/cocoon/properties is supported in the fall-back chain of
properties loading.
Yepp, thanks for the info - I'll take care
Carsten Ziegeler wrote:
Luca Morandini wrote:
One issue, though: since the property loading mechanism uses
classpath:° protocol, property files are read in alphabetical order,
which means I might have my per-project properties ruined by the
addition of a block, unless I call them
Luca Morandini schrieb:
Carsten Ziegeler wrote:
Luca Morandini wrote:
One issue, though: since the property loading mechanism uses
classpath:° protocol, property files are read in alphabetical order,
which means I might have my per-project properties ruined by the
addition of a block
Giacomo Pati wrote:
Carsten Ziegeler wrote:
Luca Morandini wrote:
This was neatly solved by the use of WEB-INF/cocoon/properties, since it
was loaded after the classpath:* chain.
Yes, you're right. Hmm, perhaps we should load properties from
WEB-INF/classes last. I'll have a look
Carsten Ziegeler wrote:
Luca Morandini schrieb:
Carsten Ziegeler wrote:
Luca Morandini wrote:
This was neatly solved by the use of WEB-INF/cocoon/properties, since it
was loaded after the classpath:* chain.
Yes, you're right. Hmm, perhaps we should load properties from
WEB-INF/classes
On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote:
In truth, I don't find the use of classes for configuration stuff
done outside JARs particularly intuitive...
+1
—ml—
Mark Lundquist wrote:
On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote:
In truth, I don't find the use of classes for configuration stuff
done outside JARs particularly intuitive...
+1
me-too/
Vadim
Luca Morandini wrote:
So, the chain you propose is (sorted by order of loading):
1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff).
2) WEB-INF/classes/cocoon/properties (project-wide stuf).
In truth, I don't find the use of classes for configuration stuff
done outside JARs
Carsten Ziegeler wrote:
Have a look at the core.properties file in the cocoon-core module. Just
put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should work.
Carsten,
Regarding loading of properties from WEB-INF - can you point out where
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Have a look at the core.properties file in the cocoon-core module. Just
put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should work.
Carsten,
Regarding loading of properties from WEB-INF - can
Daniel Fagerstrom schrieb:
Alexander Klimetschek skrev:
1) I'd like to configure the mountPath to the blocks in the webapp,
because the blocks itself are generic; I have tried it with a
properties file manually placed in WEB-INF/cocoon/properties that sets
the mountPath
in the spring-bean config XML file. Now I face two problems:
1) I'd like to configure the mountPath to the blocks in the webapp,
because the blocks itself are generic; I have tried it with a properties
file manually placed in WEB-INF/cocoon/properties that sets the mountPath
Just a follow up: blockContextURL cannot point to an absolute path in
the local file sytem yet:
b) the blockContextURL should point to the source-folder (like in the
sitemap generated by the deployer) so that reloading works on the
developer's working directory
jetty-run-ouput
...
Embedded
and the mountPath for the two blocks is
defined in the spring-bean config XML file. Now I face two problems:
1) I'd like to configure the mountPath to the blocks in the webapp,
because the blocks itself are generic; I have tried it with a
properties file manually placed in WEB-INF/cocoon/properties that sets
Alexander Klimetschek skrev:
Just a follow up: blockContextURL cannot point to an absolute path in
the local file sytem yet:
b) the blockContextURL should point to the source-folder (like in the
sitemap generated by the deployer) so that reloading works on the
developer's working directory
Leszek Gawron wrote:
My kid interrupted me in the middle of commits. Just commited that to
core. I am sorry for inconvinience.
No problem.
Hmm I seem to removed the properties at 5pm. The power of distraction.
I have also removed cocoon-core-sitemap.xmap from cocoon-webapp - seems
cocoon
Carsten Ziegeler wrote:
Leszek Gawron wrote:
My kid interrupted me in the middle of commits. Just commited that to
core. I am sorry for inconvinience.
No problem.
Hmm I seem to removed the properties at 5pm. The power of distraction.
I have also removed cocoon-core-sitemap.xmap from cocoon
Leszek Gawron wrote:
tricky question: which is the second one if both .xconfs reside in same
directory ? :)
:) I'm not sure but I think I have added the code to apply them in
alphabetical order; but I'll check that, too.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
Why are most properties residing in
cocoon-webapp/src/main/webapp/WEB-INF/cocoon/properties instead of
cocoon-core/src/main/resources/META-INF/properties? This way if anybody
changes anything also both archetypes have to be updated.
After all we have property overrides and they do not even
Leszek Gawron wrote:
Why are most properties residing in
cocoon-webapp/src/main/webapp/WEB-INF/cocoon/properties instead of
cocoon-core/src/main/resources/META-INF/properties? This way if anybody
changes anything also both archetypes have to be updated.
After all we have property
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Why are most properties residing in
cocoon-webapp/src/main/webapp/WEB-INF/cocoon/properties instead of
cocoon-core/src/main/resources/META-INF/properties? This way if anybody
changes anything also both archetypes have to be updated.
After all we
Leszek Gawron wrote:
Ok. I am going to follow what you said and migrate all possible
properties to core.
Did you remove the properties for the settings with your last commits? I
can't find any properties for logging, reloading etc.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Ok. I am going to follow what you said and migrate all possible
properties to core.
Did you remove the properties for the settings with your last commits? I
can't find any properties for logging, reloading etc.
My kid interrupted me in the middle
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Ok. I am going to follow what you said and migrate all possible
properties to core.
Did you remove the properties for the settings with your last commits? I
can't find any properties for logging, reloading etc.
My kid
Leszek Gawron wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Ok. I am going to follow what you said and migrate all possible
properties to core.
Did you remove the properties for the settings with your last commits? I
can't find any properties for logging
Daniel Fagerstrom wrote:
I don't think it should be a problem for the OSGi stuff. It is probably
easy to refactor it so that it use your new stuff.
Great :) At least in theory I have solved all problems; I hope to finish
the stuff and commit it in the next few days. Now the changes will break
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I don't think it should be a problem for the OSGi stuff. It is probably
easy to refactor it so that it use your new stuff.
Great :) At least in theory I have solved all problems; I hope to finish
the stuff and commit it in the next few
Daniel Fagerstrom wrote:
Why not expose core also with a lighter interface?
I can't follow you here, what lighter interface?
Let's define that interface and allow block that do not use spring use
instead of ApplicationContext.
Also, as you write, I do have concerns about big
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I don't think it should be a problem for the OSGi stuff. It is probably
easy to refactor it so that it use your new stuff.
Great :) At least in theory I have solved all problems; I hope to finish
the stuff and commit it in the next few days.
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I don't think it should be a problem for the OSGi stuff. It is probably
easy to refactor it so that it use your new stuff.
Great :) At least in theory I have solved all problems; I hope to finish
the stuff
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I don't think it should be a problem for the OSGi stuff. It is probably
easy to refactor it so that it use your new stuff.
Great :) At least in theory I have solved all problems; I hope to finish
the stuff and commit it
Leszek Gawron skrev:
Daniel Fagerstrom wrote:
Why not expose core also with a lighter interface?
I can't follow you here, what lighter interface?
Let's define that interface and allow block that do not use spring use
instead of ApplicationContext.
Ok, I understand.
My view on this is a
Leszek Gawron wrote:
I dislike that idea a lot, because:
1. it is error prone.
Agreed
2. It's annoying. In order to load my web application context separately
(because of the filters not finding WebApplicationContext) I had to
split META-INF/spring into META-INF/spring and
Carsten Ziegeler skrev:
Leszek Gawron wrote:
...
One VERY important question concerning cocoon core? Why is it based on
spring's BeanFactory and not on ApplicationContext?
I propose to switch from CocoonBeanFactory to CocoonApplicationContext.
WDYT?
I'm +1 for this - the original
Daniel Fagerstrom wrote:
Now, having said that, I'm completely aware about that the core still is
to complicated. IMO we need to take the consequences of our move to
Spring and try to remove as many Avalon dependencies as possible. The
ideal would be to remove all Avalon dependencies from
Carsten Ziegeler skrev:
...
Yes, that's true - now there are some problems here (as always). I
started to implement a spring 2.0 xml namespace handler which would
allow to plugin the old avalon configuration into a spring
configuration using an own xml element, like avalon:components
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Leszek Gawron wrote:
...
One VERY important question concerning cocoon core? Why is it based
on spring's BeanFactory and not on ApplicationContext? I propose to
switch from CocoonBeanFactory to CocoonApplicationContext. WDYT?
I'm +1
Carsten Ziegeler wrote:
Leszek Gawron wrote:
I dislike that idea a lot, because:
1. it is error prone.
Agreed
2. It's annoying. In order to load my web application context separately
(because of the filters not finding WebApplicationContext) I had to
split META-INF/spring into
Leszek Gawron wrote:
I mean if you want to use spring for cocoon components you put your
files into META-INF/spring/*.xml and after deployment cocoon will nicely
pick them up.
Still as most of the functionality that you are used to with
WebApplicationContext does not work you create a
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
Yes, that's true - now there are some problems here (as always). I
started to implement a spring 2.0 xml namespace handler which would
allow to plugin the old avalon configuration into a spring
configuration using an own xml element, like
Leszek Gawron skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Leszek Gawron wrote:
...
One VERY important question concerning cocoon core? Why is it based
on spring's BeanFactory and not on ApplicationContext? I propose to
switch from CocoonBeanFactory to
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
Yes, that's true - now there are some problems here (as always). I
started to implement a spring 2.0 xml namespace handler which would
allow to plugin the old avalon configuration into a spring
configuration using an
Leszek Gawron schrieb:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Yes, I like your idea. Just one simple include-config and that's it.
And the use-default-dirs can then be used to turn off including from the
default location which is on by default (If the directories do not
exists this is
Leszek Gawron schrieb:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Yes, I like your idea. Just one simple include-config and that's it.
And the use-default-dirs can then be used to turn off including from the
default location which is on by default (If the directories do not
exists this is
=myblock
-DgroupId=com.mycompany
cd myblock
mkdir src/main/resources/META-INF/properties/
echo property1=value
src/main/resources/META-INF/properties/some.properties
mvn install cocoon:deploy jetty:run
If locally testing a block the resources from src/ are not copied to
target folder
Leszek Gawron wrote:
One VERY important question concerning cocoon core? Why is it based
on spring's BeanFactory and not on ApplicationContext? I propose to
switch from CocoonBeanFactory to CocoonApplicationContext. WDYT?
I'm +1 for this - the original code I wrote actually used a
Leszek Gawron wrote:
Moreover the root context should be at least a
ConfigurableWebApplicationContext that should be registered properly in
servlet context. For now none of spring related servlet filters work
because they all rely on WebApplicationContextUtils [1] (and this one
throws not
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Moreover the root context should be at least a
ConfigurableWebApplicationContext that should be registered properly in
servlet context. For now none of spring related servlet filters work
because they all rely on WebApplicationContextUtils [1] (and
Leszek Gawron wrote:
For me the property-dir attribute smells a little bit.
Yepp.
+1 for removing
it completly. I wanted to propose some kind of map:include. That would
fix another bug I mentioned lately (mvn cocoon:deploy jetty:run does not
pick up local properties for tested block
Carsten Ziegeler wrote:
Leszek Gawron wrote:
For me the property-dir attribute smells a little bit.
Yepp.
+1 for removing
it completly. I wanted to propose some kind of map:include. That would
fix another bug I mentioned lately (mvn cocoon:deploy jetty:run does not
pick up local properties
first and then passed on as a parameter for bean factory to be
created. Building already a spring context you find that you need to
include even more properties.
One VERY important question concerning cocoon core? Why is it based on
spring's BeanFactory and not on ApplicationContext?
I
.
For now it looks a little bit like chicken egg problem: the settings are
created first and then passed on as a parameter for bean factory to be
created. Building already a spring context you find that you need to
include even more properties.
One VERY important question concerning cocoon core? Why
1 - 100 of 141 matches
Mail list logo
