You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by gk...@apache.org on 2007/09/14 20:11:53 UTC
svn commit: r575768 - in /cocoon/trunk:
blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Author: gkossakowski
Date: Fri Sep 14 11:11:52 2007
New Revision: 575768
URL: http://svn.apache.org/viewvc?rev=575768&view=rev
Log:
Switched collecting of ObjectModelProviders to bean-map from Spring Configurator. It made possible to revert some changes committed in r574029.
Added:
cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml (contents, props changed)
- copied, changed from r575483, cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml
cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml (contents, props changed)
- copied, changed from r575483, cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
Removed:
cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml
Modified:
cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.spring.xml
cocoon/trunk/core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml
cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/pom.xml
cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelProviders.xml
cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml
cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/test/resources/org/apache/cocoon/environment/FOMTestCase.spring.xml
Modified: cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.spring.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.spring.xml?rev=575768&r1=575767&r2=575768&view=diff
==============================================================================
--- cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.spring.xml (original)
+++ cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.spring.xml Fri Sep 14 11:11:52 2007
@@ -31,7 +31,6 @@
<import resource="classpath:META-INF/cocoon/spring/LegacyStringTemplateParser.xml"/>
<import resource="classpath:META-INF/cocoon/spring/ObjectModelTemplate.xml"/>
- <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" class="org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl"
- parent="org.apache.cocoon.el.objectmodel.ObjectModel.template"/>
+ <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" parent="org.apache.cocoon.el.objectmodel.ObjectModel.template"/>
</beans>
Modified: cocoon/trunk/core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml?rev=575768&r1=575767&r2=575768&view=diff
==============================================================================
--- cocoon/trunk/core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml (original)
+++ cocoon/trunk/core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml Fri Sep 14 11:11:52 2007
@@ -28,7 +28,6 @@
<import resource="classpath:META-INF/cocoon/spring/RhinoScope.xml"/>
<import resource="classpath:META-INF/cocoon/spring/ObjectModelTemplate.xml"/>
- <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" class="org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl"
- parent="org.apache.cocoon.el.objectmodel.ObjectModel.template"/>
+ <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" parent="org.apache.cocoon.el.objectmodel.ObjectModel.template"/>
</beans>
Modified: cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/pom.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/pom.xml?rev=575768&r1=575767&r2=575768&view=diff
==============================================================================
--- cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/pom.xml (original)
+++ cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/pom.xml Fri Sep 14 11:11:52 2007
@@ -61,6 +61,10 @@
<artifactId>cocoon-xml-util</artifactId>
</dependency>
<dependency>
+ <groupId>org.apache.cocoon</groupId>
+ <artifactId>cocoon-spring-configurator</artifactId>
+ </dependency>
+ <dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
</dependency>
Modified: cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelProviders.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelProviders.xml?rev=575768&r1=575767&r2=575768&view=diff
==============================================================================
--- cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelProviders.xml (original)
+++ cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelProviders.xml Fri Sep 14 11:11:52 2007
@@ -21,13 +21,13 @@
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<!-- ObjectModelEntry provider for 'Packages' -->
- <bean name="org.apache.cocoon.el.impl.objectmodel.PackagesEntryObjectModelProvider"
+ <bean name="org.apache.cocoon.el.objectmodel.ObjectModelProvider/Packages"
class="org.apache.cocoon.el.impl.objectmodel.PackagesEntryObjectModelProvider">
<property name="rootScope" ref="org.mozilla.javascript.Scriptable/rootScope"/>
</bean>
<!-- ObjectModelEntry provider for 'java' -->
- <bean name="org.apache.cocoon.el.impl.objectmodel.JavaEntryObjectModelProvider"
+ <bean name="org.apache.cocoon.el.objectmodel.ObjectModelProvider/java"
class="org.apache.cocoon.el.impl.objectmodel.JavaEntryObjectModelProvider">
<property name="rootScope" ref="org.mozilla.javascript.Scriptable/rootScope"/>
</bean>
Copied: cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml (from r575483, cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml)
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml?p2=cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml&p1=cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml&r1=575483&r2=575768&rev=575768&view=diff
==============================================================================
--- cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml (original)
+++ cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml Fri Sep 14 11:11:52 2007
@@ -19,8 +19,10 @@
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
+ xmlns:configurator="http://cocoon.apache.org/schema/configurator"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
- http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">
+ http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
+ http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd">
<!-- Default implementation of ObjectModel interface. This bean definition, is a template actually because it has
abstract attribute set to "true". It enables Object Model to be defined as scoped bean elsewhere. -->
@@ -28,12 +30,8 @@
class="org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl"
abstract="true">
<property name="initialEntries">
- <map>
- <entry key="cocoon" value-ref="org.apache.cocoon.objectmodel.impl.CocoonEntryObjectModelProvider"/>
- <entry key="Packages" value-ref="org.apache.cocoon.el.impl.objectmodel.PackagesEntryObjectModelProvider"/>
- <entry key="java" value-ref="org.apache.cocoon.el.impl.objectmodel.JavaEntryObjectModelProvider"/>
- </map>
- </property>
+ <configurator:bean-map type="org.apache.cocoon.el.objectmodel.ObjectModelProvider"/>
+ </property>
</bean>
</beans>
Propchange: cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml
------------------------------------------------------------------------------
svn:keywords = Id
Copied: cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml (from r575483, cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml)
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml?p2=cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml&p1=cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml&r1=575483&r2=575768&rev=575768&view=diff
==============================================================================
--- cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml (original)
+++ cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml Fri Sep 14 11:11:52 2007
@@ -23,8 +23,8 @@
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">
<!-- Default implementation of ObjectModel interface in pipelineComponent scope. -->
- <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" class="org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl"
- scope="pipelineComponent" parent="org.apache.cocoon.el.objectmodel.ObjectModel.template">
+ <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" scope="pipelineComponent"
+ parent="org.apache.cocoon.el.objectmodel.ObjectModel.template">
<aop:scoped-proxy proxy-target-class="false"/>
</bean>
Propchange: cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
------------------------------------------------------------------------------
svn:keywords = Id
Propchange: cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
------------------------------------------------------------------------------
svn:mime-type = text/plain
Modified: cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml?rev=575768&r1=575767&r2=575768&view=diff
==============================================================================
--- cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml (original)
+++ cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml Fri Sep 14 11:11:52 2007
@@ -21,7 +21,7 @@
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<!-- ObjectModelEntry provider for 'cocoon' -->
- <bean name="org.apache.cocoon.objectmodel.impl.CocoonEntryObjectModelProvider"
+ <bean name="org.apache.cocoon.el.objectmodel.ObjectModelProvider/cocoon"
class="org.apache.cocoon.objectmodel.impl.CocoonEntryObjectModelProvider">
<property name="settings" ref="org.apache.cocoon.configuration.Settings"/>
<property name="processInfoProvider" ref="org.apache.cocoon.processing.ProcessInfoProvider"/>
Modified: cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/test/resources/org/apache/cocoon/environment/FOMTestCase.spring.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/test/resources/org/apache/cocoon/environment/FOMTestCase.spring.xml?rev=575768&r1=575767&r2=575768&view=diff
==============================================================================
--- cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/test/resources/org/apache/cocoon/environment/FOMTestCase.spring.xml (original)
+++ cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/test/resources/org/apache/cocoon/environment/FOMTestCase.spring.xml Fri Sep 14 11:11:52 2007
@@ -26,16 +26,9 @@
<import resource="classpath:META-INF/cocoon/spring/ObjectModelProviders.xml"/>
<import resource="classpath:META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml"/>
<import resource="classpath:META-INF/cocoon/spring/RhinoScope.xml"/>
+ <import resource="classpath:META-INF/cocoon/spring/ObjectModelTemplate.xml"/>
<!-- Redefining this bean instead of importing because originally it is in "call" scope -->
- <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" class="org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl">
- <property name="initialEntries">
- <map>
- <entry key="cocoon" value-ref="org.apache.cocoon.objectmodel.impl.CocoonEntryObjectModelProvider"/>
- <entry key="Packages" value-ref="org.apache.cocoon.el.impl.objectmodel.PackagesEntryObjectModelProvider"/>
- <entry key="java" value-ref="org.apache.cocoon.el.impl.objectmodel.JavaEntryObjectModelProvider"/>
- </map>
- </property>
- </bean>
+ <bean name="org.apache.cocoon.el.objectmodel.ObjectModel" parent="org.apache.cocoon.el.objectmodel.ObjectModel.template"/>
</beans>
Re: IDE support for Spring
Posted by Jorg Heymans <jh...@apache.org>.
Grzegorz Kossakowski wrote:
>
> Cartsen, can you give your configuration (plug-ins included) that makes your Eclipse supporting
> refactoring of Spring configuration files? It does not work on my Eclipse 3.3, now.
SpringIDE supports some degree of refactoring (see 'New Features' in the
2.0 release announcement, http://springide.org/blog/).
I saw this feature being demonstrated at Spring One, IIRC all it
requires is to enable the Spring nature to your project, then add your
spring configuration files in the Springide configuration part of the
project.
HTH
Jorg
Re: IDE support for Spring
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
>
> Carsten, can you give your configuration (plug-ins included) that makes your Eclipse supporting
> refactoring of Spring configuration files? It does not work on my Eclipse 3.3, now.
>
I have installed the full-blown Europa 3.3 installation with the usual
suspects like subclipse, spring ide and some others.
The built-in refactoring of eclipse has an option you just have to check
to change configuration files as well; actually it searches for all
textual occurances of the class name. When you refactor something there
is a small wizard where you can check the option.
However, I'm not happy about my 3.3 installation as it replaces to much
in big projects and makes them unusable after a refactoring! But
interestingly this is only on my installation; others having the same
setup have no problems. This must be due to the dynamic nature of OSGi :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
IDE support for Spring
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> Vadim Gritsenko wrote:
>> You can try IDEA. As a committer on apache project you can get license
>> for free for your open source work. It will refactor configuration files
>> simultaneously with java files.
Vadim, it's not the first time you encourage me to try IDEA and since, as you said, it's free for
ASF committers I'm going to give it a look, soon.
> Which does Eclipse as well :)
>
> I'm not sure, but perhaps the Spring Eclipse Plugin gives even more power?
Cartsen, can you give your configuration (plug-ins included) that makes your Eclipse supporting
refactoring of Spring configuration files? It does not work on my Eclipse 3.3, now.
Thanks.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
> Grzegorz Kossakowski wrote:
>> What annoys me the most is lack of support for refactoring of beans
>> configs in Eclipse. Currently my
>> workflow is following:
>> 1. Refactor java classes using Eclipse tools
>
> You can try IDEA. As a committer on apache project you can get license
> for free for your open source work. It will refactor configuration files
> simultaneously with java files.
Which does Eclipse as well :)
I'm not sure, but perhaps the Spring Eclipse Plugin gives even more power?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> What annoys me the most is lack of support for refactoring of beans configs in Eclipse. Currently my
> workflow is following:
> 1. Refactor java classes using Eclipse tools
You can try IDEA. As a committer on apache project you can get license for free
for your open source work. It will refactor configuration files simultaneously
with java files.
Vadim
> 2. Analyze changes and create list of commands involving grep, find, mv and awk tools
> 3. Start linux terminal and fire list of commands that will refactor Spring beans
> 4. Keep fingers crossed for not breaking anything
>
> This situation is far from being optimal and Spring IDE plug-in for Eclipse does not help (at least
> to my knowledge) anyhow, unfortunately.
>
> Can you share your experiences?
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
>> I see. Last question is about multiple bean declarations in one xml
>> file. Do we think it's good or
>> bad practise?
>
> No strong opinion about that. If a couple of beans works togther or are
> of the same "kind" it seem natural to put them together in one file.
> Otherwise not. What is your opinion?
I have no strong opinion on this topic. I agree with you that grouping closely related to each other
in one file is a good idea. However, my main reason for using camel names (following class names)
was to make it easy to find relevant config to given class.
What annoys me the most is lack of support for refactoring of beans configs in Eclipse. Currently my
workflow is following:
1. Refactor java classes using Eclipse tools
2. Analyze changes and create list of commands involving grep, find, mv and awk tools
3. Start linux terminal and fire list of commands that will refactor Spring beans
4. Keep fingers crossed for not breaking anything
This situation is far from being optimal and Spring IDE plug-in for Eclipse does not help (at least
to my knowledge) anyhow, unfortunately.
Can you share your experiences?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Number of Spring configuration files
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.09.2007 3:53 Uhr, Carsten Ziegeler wrote:
> Too many files confuse users, so I would go to put everything in a
> single file and only if it makes sense to split it, start a new file.
+1
Joerg
Re: Number of Spring configuration files
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> Grzegorz Kossakowski skrev:
>>> I see. Last question is about multiple bean declarations in one xml
>>> file. Do we think it's good or
>>> bad practise?
>>
>> No strong opinion about that. If a couple of beans works togther or
>> are of the same "kind" it seem natural to put them together in one
>> file. Otherwise not. What is your opinion?
>
> I agree with this. Also see
> http://netzooid.com/blog/2007/07/03/tips-for-improving-springs-start-up-performance/:
> Having a lot of XML files means a lot of files to parse which slows down
> the startup.
>
What's the advantage of having several small xml files compared to one?
Too many files confuse users, so I would go to put everything in a
single file and only if it makes sense to split it, start a new file.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Number of Spring configuration files
Posted by Felix Knecht <fe...@apache.org>.
Reinhard Poetz schrieb:
> Daniel Fagerstrom wrote:
>> Grzegorz Kossakowski skrev:
>>> I see. Last question is about multiple bean declarations in one xml
>>> file. Do we think it's good or
>>> bad practise?
>>
>> No strong opinion about that. If a couple of beans works togther or
>> are of the same "kind" it seem natural to put them together in one
>> file. Otherwise not. What is your opinion?
>
+1
Felix
Number of Spring configuration files
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Grzegorz Kossakowski skrev:
>> I see. Last question is about multiple bean declarations in one xml
>> file. Do we think it's good or
>> bad practise?
>
> No strong opinion about that. If a couple of beans works togther or are
> of the same "kind" it seem natural to put them together in one file.
> Otherwise not. What is your opinion?
I agree with this. Also see
http://netzooid.com/blog/2007/07/03/tips-for-improving-springs-start-up-performance/:
Having a lot of XML files means a lot of files to parse which slows down the
startup.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> I'm not so happy about "non local" use of abstract bean configurations.
>> AFAICS it doesn't work with spring-osgi where you have one application
>> context for each block. And there is no obvious way to export abstract
>> configurations between bundles. Also they make the configurations harder
>> to read and, IMO, unnecessarily abstract.
>>
>> I think that abstract bean configurations are OK, as far as they only
>> are used within the configuation file where they are defined. Otherwise
>> I prefer beeing a litle bit more verbose. And one can always use factory
>> beans and custom configurations for complicated configuration patterns.
>
> Your arguments seems to be valid. I'll take them into account when creating new code.
>
> What about integration tests? Can I use configuration templates, there?
I would restrict the use of configuration to use within the same module.
So it depends.
>>>> I also wonder
>>>> why you use camel case names for Spring config files instead of
>>>> following the name convention that all the rest of the Spring configs in
>>>> Cocoon use.
>>> I didn't know we have such convention; so what are the rules?
>> First, all configuration files are prefixed with the module name. This
>> is because they are collected from the classpath
>> (classpath*:META-INF/cocoon/spring somwhere in the configurator code),
>> to a common global Spring application context. Because of that the file
>> names needs to be unique.
>>
>> Second, smallcaps and hyphens are used. E.g. cocoon-core-generators.xml.
>
> I see. Last question is about multiple bean declarations in one xml file. Do we think it's good or
> bad practise?
No strong opinion about that. If a couple of beans works togther or are
of the same "kind" it seem natural to put them together in one file.
Otherwise not. What is your opinion?
/Daniel
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> I'm not so happy about "non local" use of abstract bean configurations.
> AFAICS it doesn't work with spring-osgi where you have one application
> context for each block. And there is no obvious way to export abstract
> configurations between bundles. Also they make the configurations harder
> to read and, IMO, unnecessarily abstract.
>
> I think that abstract bean configurations are OK, as far as they only
> are used within the configuation file where they are defined. Otherwise
> I prefer beeing a litle bit more verbose. And one can always use factory
> beans and custom configurations for complicated configuration patterns.
Your arguments seems to be valid. I'll take them into account when creating new code.
What about integration tests? Can I use configuration templates, there?
>>
>>> I also wonder
>>> why you use camel case names for Spring config files instead of
>>> following the name convention that all the rest of the Spring configs in
>>> Cocoon use.
>>
>> I didn't know we have such convention; so what are the rules?
>
> First, all configuration files are prefixed with the module name. This
> is because they are collected from the classpath
> (classpath*:META-INF/cocoon/spring somwhere in the configurator code),
> to a common global Spring application context. Because of that the file
> names needs to be unique.
>
> Second, smallcaps and hyphens are used. E.g. cocoon-core-generators.xml.
I see. Last question is about multiple bean declarations in one xml file. Do we think it's good or
bad practise?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Any reason for defining the ObjectModel bean in the pipeline-impl
>> modeule instead of in the expression-language-impl module?
>
> Yep, OM is scoped (with pipelineComponent scope) that is implement in pipeline-impl.
OK, I didn't think of the scope.
> The idea is to
> have "template" bean configuration that is marked as abstract and configures everything except scope
> and make a final declaration elsewhere.
I'm not so happy about "non local" use of abstract bean configurations.
AFAICS it doesn't work with spring-osgi where you have one application
context for each block. And there is no obvious way to export abstract
configurations between bundles. Also they make the configurations harder
to read and, IMO, unnecessarily abstract.
I think that abstract bean configurations are OK, as far as they only
are used within the configuation file where they are defined. Otherwise
I prefer beeing a litle bit more verbose. And one can always use factory
beans and custom configurations for complicated configuration patterns.
>
>> I also wonder
>> why you use camel case names for Spring config files instead of
>> following the name convention that all the rest of the Spring configs in
>> Cocoon use.
>
> I didn't know we have such convention; so what are the rules?
First, all configuration files are prefixed with the module name. This
is because they are collected from the classpath
(classpath*:META-INF/cocoon/spring somwhere in the configurator code),
to a common global Spring application context. Because of that the file
names needs to be unique.
Second, smallcaps and hyphens are used. E.g. cocoon-core-generators.xml.
/Daniel
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Any reason for defining the ObjectModel bean in the pipeline-impl
> modeule instead of in the expression-language-impl module?
Yep, OM is scoped (with pipelineComponent scope) that is implement in pipeline-impl. The idea is to
have "template" bean configuration that is marked as abstract and configures everything except scope
and make a final declaration elsewhere.
> I also wonder
> why you use camel case names for Spring config files instead of
> following the name convention that all the rest of the Spring configs in
> Cocoon use.
I didn't know we have such convention; so what are the rules?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/
core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/
core/cocoon-expression-lan...
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Any reason for defining the ObjectModel bean in the pipeline-impl
modeule instead of in the expression-language-impl module? I also wonder
why you use camel case names for Spring config files instead of
following the name convention that all the rest of the Spring configs in
Cocoon use.
/Daniel
gkossakowski@apache.org skrev:
> Author: gkossakowski
> Date: Fri Sep 14 11:11:52 2007
> New Revision: 575768
>
> URL: http://svn.apache.org/viewvc?rev=575768&view=rev
> Log:
> Switched collecting of ObjectModelProviders to bean-map from Spring Configurator. It made possible to revert some changes committed in r574029.
>
> Added:
> cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml (contents, props changed)
> - copied, changed from r575483, cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml
> cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml (contents, props changed)
> - copied, changed from r575483, cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
> Removed:
> cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
> cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelTemplate.xml
> Modified:
> cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/JXTemplateGeneratorTestCase.spring.xml
> cocoon/trunk/core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml
> cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/pom.xml
> cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/ObjectModelProviders.xml
> cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml
> cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/test/resources/org/apache/cocoon/environment/FOMTestCase.spring.xml
>