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 2005/03/18 14:41:59 UTC
Initial version of spring-app block
Hi,
I just committed the inital version under
https://svn.apache.org/repos/asf/cocoon/blocks/spring-app/trunk
The readme.txt explains howto include the block in the build and howto
see the nice example :)
The block is not finished yet. You currently are able to define a spring
application context on a per sitemap base and can use flow and the
service manager to lookup your beans - a simple example for flow is
included.
Currently missing is the chaining of spring contexts and some further
glue code.
I think we should use this block as a prototype and discuss/see what
else is needed/can be done. So everyone is of course invited to improve
the functionality.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Rolf Kulemann wrote:
>
> The problem here is that I haveto add an empty applicationContext.xml
> or add an empty <contextConfigLocation>, which is not nice. So, I want
> that only my parent context is used. Carsten, would it be ok, if I
> change the SpringComponentLocator to fall back to parent only, if
> applicationContext.xml is not available and
> <contextConfigLocation> is null?
>
Sure, go ahead and thanks for fixing the bug with the configuration.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Rolf Kulemann <ro...@apache.org>.
On Mon, 2005-04-25 at 00:09, Rolf Kulemann wrote:
> On Sun, 2005-04-24 at 19:48, Carsten Ziegeler wrote:
> > Rolf Kulemann wrote:
...
>
> NOTE: I found out that the <application-container> was setup using the
> configuration from <components>. That prevented e.g. to use
>
> <application-container>
> <myparam>value</myparam>
> <application-container>
>
> myparam could not be detremined in the configure method of the compoenent. I fixed that in trunk. I hope that was ok.
(Sorry for my bad english, but I'm a bit tired)
In my current Cocoon/Spring/Hibernate app, I have to use the
OpenSessionInViewFilter of Spring for several reasons. I have to decalre
the filter in web.xml as well as my configLocations. Thus I do not need
to specify any on the sitemap level via
<map:application-container
class="org.apache.cocoon.spring.SpringComponentLocator"
contextConfigLocation="test.xml">
<contextConfigLocation></contextConfigLocation>
</map:application-container>
The problem here is that I haveto add an empty applicationContext.xml
or add an empty <contextConfigLocation>, which is not nice. So, I want
that only my parent context is used. Carsten, would it be ok, if I
change the SpringComponentLocator to fall back to parent only, if
applicationContext.xml is not available and
<contextConfigLocation> is null?
--
Rolf Kulemann
Re: Initial version of spring-app block
Posted by Rolf Kulemann <ro...@apache.org>.
On Sun, 2005-04-24 at 19:48, Carsten Ziegeler wrote:
> Rolf Kulemann wrote:
...
> > What I don't like in my Spring/Cocoon apps (which is also the problem here) is:
> > Spring is great in dependency injection and I want to avoid obtaining components
> > direct via any component manager.
> >
> > So, a short idea to solve this could be to extend the flow declaration in the sitemap:
> >
> > <map:flow language="javascript">
> > <map:script src="flow.js">
> > <property name="myBean"><ref bean="spring-test"/></property>
> > </map>
> > </map:flow>
> >
> > MyBean is than automatically "injected" into the flow context so that i can simply
> > write sth. like
> >
> > function test() {
> > myBean.getAProperty();
> > }
> >
> >
> > This is not only related to flow and Spring but to flow use and dep. injection in
> > general doesn't matter what container is used.
> >
...
NOTE: I found out that the <application-container> was setup using the
configuration from <components>. That prevented e.g. to use
<application-container>
<myparam>value</myparam>
<application-container>
myparam could not be detremined in the configure method of the compoenent. I fixed that in trunk. I hope that was ok.
> Thanks. Hmm, your idea reminds me a little bit of our unified object
> model discussion. We discussed some time ago to open up the object model
> of Cocoon, so users can add their own "accessors" (or whatever you call
> them). Currently in flow you have access to the request object, to the
> parameters object etc. With own accessors you have access to some
> configured objects, so you can write:
> cocoon.myAccessor.something() in flow and configure your accessor
> "somewhere" (perhaps cocoon.xconf) as an extension to the object model.
Mmmh, would be an option, but I do not like to configure things in cocoon.xconf since it is too static imho.
On sitemap level that would be more appropriate.
> The advantage then would be that you could also use this in other parts
> of cocoon, like the sitemap or jxtg etc.
Well, if we follow my alternative idea from above, would it still be possible to use that in jxtg ?
Mhh, and looking at my various CForms apps: I do not like put pass all the beans I need in a JXTemplate
via the cocoon.sendPage("", {...}) thing. I would like to do that on a more declarative way like you do it in struts
or JSF (well Struts...) but that is too static, since I is the declaration is evaluated on servlet startup.
So, the picture I have to declare somewhere, which beans must be available for lets say a form processing in flow and templates.
> So, this is similar to your idea apart from a) a different configuration
> location and b) a slightly different part (you have to access everything
> via the cocoon object).
> Would that mechanism make you happy?
Accessing via the cocoon object woulk be ok, but cocoon.xconf is not 100%.
>
> Apart from that, I'm not sure if your approach might be too much magic.
> If you write your flow script you have to know which beans/components
> are configured in the sitemap using what names etc. That's not directly
> visible in the flow script.
Mhh, I guess this is the problem of being type free. In Spring the dep. injection works via properties.
If I transfer that to flow, I would need to write
------
var myBean;
function thisAndThat() {
myBean.doIt();
}
-----
where myBean is injected. But you are right. Another problem are changing bean names.
If I have them in a single file or two like in a sitemap, the changes would be easier to adopt.
>
> Another approach would be to use intercepted flow script (don't know the
> state yet, there is something in the scratchpad). Using this you add
> functions that are run before a flow script function is called. So, you
> define a variable myBean in this aspect and do a lookup of the
> component/bean. As this snippet is called before your own flow function,
> you can simply access myBean. Again it's a little bit different from
> your approach.
Mhh, nice idea, but that partions all the flow thingy too much for my problem.
>
> What do you think?
See above and thanks for your answers.
(My first mail went out too early :)
--
Rolf Kulemann
Re: Initial version of spring-app block
Posted by Rolf Kulemann <ma...@rolf-kulemann.com>.
On Sun, 2005-04-24 at 19:48, Carsten Ziegeler wrote:
> Rolf Kulemann wrote:
...
> > What I don't like in my Spring/Cocoon apps (which is also the problem here) is:
> > Spring is great in dependency injection and I want to avoid obtaining components
> > direct via any component manager.
> >
> > So, a short idea to solve this could be to extend the flow declaration in the sitemap:
> >
> > <map:flow language="javascript">
> > <map:script src="flow.js">
> > <property name="myBean"><ref bean="spring-test"/></property>
> > </map>
> > </map:flow>
> >
> > MyBean is than automatically "injected" into the flow context so that i can simply
> > write sth. like
> >
> > function test() {
> > myBean.getAProperty();
> > }
> >
> >
> > This is not only related to flow and Spring but to flow use and dep. injection in
> > general doesn't matter what container is used.
> >
...
NOTE: I found out that the <application-container> was setup using the
configuration from <components>. That prevented e.g. to use
> Thanks. Hmm, your idea reminds me a little bit of our unified object
> model discussion. We discussed some time ago to open up the object model
> of Cocoon, so users can add their own "accessors" (or whatever you call
> them). Currently in flow you have access to the request object, to the
> parameters object etc. With own accessors you have access to some
> configured objects, so you can write:
> cocoon.myAccessor.something() in flow and configure your accessor
> "somewhere" (perhaps cocoon.xconf) as an extension to the object model.
> The advantage then would be that you could also use this in other parts
> of cocoon, like the sitemap or jxtg etc.
> So, this is similar to your idea apart from a) a different configuration
> location and b) a slightly different part (you have to access everything
> via the cocoon object).
> Would that mechanism make you happy?
>
> Apart from that, I'm not sure if your approach might be too much magic.
> If you write your flow script you have to know which beans/components
> are configured in the sitemap using what names etc. That's not directly
> visible in the flow script.
>
> Another approach would be to use intercepted flow script (don't know the
> state yet, there is something in the scratchpad). Using this you add
> functions that are run before a flow script function is called. So, you
> define a variable myBean in this aspect and do a lookup of the
> component/bean. As this snippet is called before your own flow function,
> you can simply access myBean. Again it's a little bit different from
> your approach.
>
> What do you think?
>
> Carsten
--
Rolf Kulemann Tel. +49 (0) 5132 82 48 16
Rethmarstr. 12, 31275 Lehrte, Germany Fax +49 (0) 721 151 20 76 19
mail@rolf-kulemann.com Mobile +49 (0) 176 24 08 89 92
Re: Initial version of spring-app block
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
<snip/>
> Thanks. Hmm, your idea reminds me a little bit of our unified object
> model discussion. We discussed some time ago to open up the object model
> of Cocoon, so users can add their own "accessors" (or whatever you call
> them). Currently in flow you have access to the request object, to the
> parameters object etc. With own accessors you have access to some
> configured objects, so you can write:
> cocoon.myAccessor.something() in flow and configure your accessor
> "somewhere" (perhaps cocoon.xconf) as an extension to the object model.
> The advantage then would be that you could also use this in other parts
> of cocoon, like the sitemap or jxtg etc.
> So, this is similar to your idea apart from a) a different configuration
> location and b) a slightly different part (you have to access everything
> via the cocoon object).
<snip/>
It reminded me about that discussion also.
I wrote some code for the accessors. You can find it in
o.a.c.components.accessor in the template block. There are test code
also that illustrates confoguration.
I havn't start to use them in template yet as I wanted back compability
and didn't found any good way to implement cocoon.parameters. The
accessors have access to the object model and the service manager but
not in any natural way to the sitemap parameters. Any ideas?
/Daniel
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Rolf Kulemann wrote:
>
> first: I really appreciate work towards Spring integration into Cocoon.
> Unfortunately I'm a old Cocoon 2.1.x guy and I do not know Cocoon 2.2
> very good. However, I'm using Spring and Cocoon 2.1.x heavily and want
> to tell you some of my thoughts.
>
> I looked at the example you (Carsten) provided in the spring-app block.
> The flow.js is as follows:
>
> <snip/>
>
> What I don't like in my Spring/Cocoon apps (which is also the problem here) is:
> Spring is great in dependency injection and I want to avoid obtaining components
> direct via any component manager.
>
> So, a short idea to solve this could be to extend the flow declaration in the sitemap:
>
> <map:flow language="javascript">
> <map:script src="flow.js">
> <property name="myBean"><ref bean="spring-test"/></property>
> </map>
> </map:flow>
>
> MyBean is than automatically "injected" into the flow context so that i can simply
> write sth. like
>
> function test() {
> myBean.getAProperty();
> }
>
>
> This is not only related to flow and Spring but to flow use and dep. injection in
> general doesn't matter what container is used.
>
> Now, I will go and play with Cocoon 2.2 and Spring a bit. Thanks Carsten, nice work.
>
Thanks. Hmm, your idea reminds me a little bit of our unified object
model discussion. We discussed some time ago to open up the object model
of Cocoon, so users can add their own "accessors" (or whatever you call
them). Currently in flow you have access to the request object, to the
parameters object etc. With own accessors you have access to some
configured objects, so you can write:
cocoon.myAccessor.something() in flow and configure your accessor
"somewhere" (perhaps cocoon.xconf) as an extension to the object model.
The advantage then would be that you could also use this in other parts
of cocoon, like the sitemap or jxtg etc.
So, this is similar to your idea apart from a) a different configuration
location and b) a slightly different part (you have to access everything
via the cocoon object).
Would that mechanism make you happy?
Apart from that, I'm not sure if your approach might be too much magic.
If you write your flow script you have to know which beans/components
are configured in the sitemap using what names etc. That's not directly
visible in the flow script.
Another approach would be to use intercepted flow script (don't know the
state yet, there is something in the scratchpad). Using this you add
functions that are run before a flow script function is called. So, you
define a variable myBean in this aspect and do a lookup of the
component/bean. As this snippet is called before your own flow function,
you can simply access myBean. Again it's a little bit different from
your approach.
What do you think?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2005-03-18 at 14:41, Carsten Ziegeler wrote:
> Hi,
>
> I just committed the inital version under
> https://svn.apache.org/repos/asf/cocoon/blocks/spring-app/trunk
>
> The readme.txt explains howto include the block in the build and howto
> see the nice example :)
>
> The block is not finished yet. You currently are able to define a spring
> application context on a per sitemap base and can use flow and the
> service manager to lookup your beans - a simple example for flow is
> included.
> Currently missing is the chaining of spring contexts and some further
> glue code.
>
> I think we should use this block as a prototype and discuss/see what
> else is needed/can be done. So everyone is of course invited to improve
> the functionality.
>
> Carsten
Hi Carsten,
first: I really appreciate work towards Spring integration into Cocoon.
Unfortunately I'm a old Cocoon 2.1.x guy and I do not know Cocoon 2.2
very good. However, I'm using Spring and Cocoon 2.1.x heavily and want
to tell you some of my thoughts.
I looked at the example you (Carsten) provided in the spring-app block.
The flow.js is as follows:
function test() {
var component = cocoon.getComponent("spring-test");
var core = cocoon.getComponent("cocoon-core");
cocoon.sendPage("test", { "message" : component.getMessage(),
"configuration" : core.getSettings().getConfiguration()});
}
What I don't like in my Spring/Cocoon apps (which is also the problem here) is:
Spring is great in dependency injection and I want to avoid obtaining components direct via any component manager.
So, a short idea to solve this could be to extend the flow declaration in the sitemap:
<map:flow language="javascript">
<map:script src="flow.js">
<property name="myBean"><ref bean="spring-test"/></property>
</map>
</map:flow>
MyBean is than automatically "injected" into the flow context so that i can simply write sth. like
function test() {
myBean.getAProperty();
}
This is not only related to flow and Spring but to flow use and dep. injection in general doesn't matter what container is used.
Now, I will go and play with Cocoon 2.2 and Spring a bit. Thanks Carsten, nice work.
--
Rolf Kulemann
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Ugo Cei wrote:
> Il giorno 18/mar/05, alle 14:41, Carsten Ziegeler ha scritto:
>
>
>>I think we should use this block as a prototype and discuss/see what
>>else is needed/can be done. So everyone is of course invited to improve
>>the functionality.
>>
>
>
> All right, I finally found some time to dive in, but this is what I get
> when trying to run the sample:
>
> Unable to resolve context key: object-model
>
> cause: org.apache.avalon.framework.context.ContextException: Unable to
> resolve context key: object-model
>
>
> Any hints as to what might have gone wrong?
>
Strange exception, this might be due to some refactoring of the core,
but to be honest I'm not sure. I will look into it asap.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 24/apr/05, alle 09:02, Carsten Ziegeler ha scritto:
> I think I fixed the problem now; at least it works for me again :)
I can confirm that it works. Great!
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Source.zone: http://sourcezone.info/
Wine & Food Blog: http://www.divinocibo.it/
Re: Initial version of spring-app block
Posted by Ugo Cei <ug...@gmail.com>.
Il giorno 24/apr/05, alle 09:02, Carsten Ziegeler ha scritto:
> I think I fixed the problem now; at least it works for me again :)
I can confirm that it works. Great!
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Source.zone: http://sourcezone.info/
Wine & Food Blog: http://www.divinocibo.it/
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
I think I fixed the problem now; at least it works for me again :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 18/mar/05, alle 14:41, Carsten Ziegeler ha scritto:
> I think we should use this block as a prototype and discuss/see what
> else is needed/can be done. So everyone is of course invited to improve
> the functionality.
>
All right, I finally found some time to dive in, but this is what I get
when trying to run the sample:
Unable to resolve context key: object-model
cause: org.apache.avalon.framework.context.ContextException: Unable to
resolve context key: object-model
full exception chain stacktrace[hide]
org.apache.avalon.framework.CascadingRuntimeException: Unable to get
the object model from the context.
at
org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.
java:95)
at org.apache.cocoon.core.Core.getCurrentObjectModel(Core.java:112)
at
org.apache.cocoon.spring.SpringComponentLocator.getParentContext(SpringC
omponentLocator.java:250)
at
org.apache.cocoon.spring.SpringComponentLocator.initialize(SpringCompone
ntLocator.java:129)
at
org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHel
per.java:165)
at
org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHel
per.java:124)
at
org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage.creat
eServiceManager(SitemapLanguage.java:136)
at
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.build(Defa
ultTreeBuilder.java:372)
...
Any hints as to what might have gone wrong?
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Source.zone: http://sourcezone.info/
Wine & Food Blog: http://www.divinocibo.it/
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> Was defining a spring application context on a per sitemap base a design
> decision or the easiest way to write a prototype? Shouldn't it be the goal that
> each block (and of course Cocoon core) can provide beans via some export
> functionality and this exported beans can be reused by any other block depending
> on this block? Or for now, wouldn't we want to use Spring managed beans all over
> in our Cocoon application?
>
> (Sorry for the maybe dumb questions - don't want to criticize your work in any
> way :-) )
>
:) No problem - we discussed this briefly last week in [1]. In short,
it's design decision. We identified - for now! - the sitemap as the
central configuration place for an application (or a block): classpath,
xconfs and now "application support" through own Spring application
contexts. (The concept is open to other containers as well, you could
also use Hivemind or whatever here).
Now, using a global Spring app context is of course an alternative. But
with the context on a per sitemap base, you can have different
applications running inside Cocoon with different Spring configurations.
And they are shielded through the new classloading concept. In addition
- though not implemented yet - you can simply create a hierarchy of
spring app contexts by creating a hierarchy of sitemaps.
So with this feature, you can either use the "usual spring way" by using
the spring servlet (filter), or you can defined a spring context at the
main sitemap and the spring beans will be accessible throughout the
whole Cocoon application. But this feature is targetted for running
different applications/blocks inside Cocoon with different
Spring/container configurations.
As soon as our blocks have an export mechanism for avalon components
through a service manager, the spring beans will be exportable without
any extra work as they are now reachable through a service manager.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> I just committed the inital version under
> https://svn.apache.org/repos/asf/cocoon/blocks/spring-app/trunk
That's great news!!!
>
> The readme.txt explains howto include the block in the build and howto
> see the nice example :)
>
> The block is not finished yet. You currently are able to define a spring
> application context on a per sitemap base and can use flow and the
> service manager to lookup your beans - a simple example for flow is
> included.
> Currently missing is the chaining of spring contexts and some further
> glue code.
Was defining a spring application context on a per sitemap base a design
decision or the easiest way to write a prototype? Shouldn't it be the goal that
each block (and of course Cocoon core) can provide beans via some export
functionality and this exported beans can be reused by any other block depending
on this block? Or for now, wouldn't we want to use Spring managed beans all over
in our Cocoon application?
(Sorry for the maybe dumb questions - don't want to criticize your work in any
way :-) )
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Initial version of spring-app block
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 18 mars 05, à 17:45, Carsten Ziegeler a écrit :
> Hmm, are you using latest SVN of 2.2?
I think so, just did an svn up and build clean. But I'll check once
more...
-Bertrand
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
In my reply to Reinhard's question I forgot to include the link to the
preceding discussion:
[1] http://marc.theaimsgroup.com/?t=111056659900001&r=1&w=2
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 18 mars 05, à 18:02, Carsten Ziegeler a écrit :
> ...Can you please check which version of
> src/java/
> org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage
> you have
> I have:
> * @version CVS $Id: SitemapLanguage.java 158074 2005-03-18 14:46:39Z
> cziegeler $
hmm...for some reason I had an older release, it is updated now, after
doing an explicit svn up on that file.
I *have* run svn up on the trunk before though, very strange.
I gotta run now, will check tomorrow but it should be ok with the
correct version ;-)
sorry forr the noise,
-Bertrand
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Le 18 mars 05, à 17:45, Carsten Ziegeler a écrit :
>
>>...Hmm, are you using latest SVN of 2.2?..
>
>
> Confirmed, did svn up again, rm -rf build, rebuild, and
> http://localhost:8888/samples/blocks/spring-app/ says "Unknown
> component type 'application-container'" in
> CoreServiceManager.parseConfiguration(CoreServiceManager.java:644)
>
Hmm, I can confirm that it works. Very strange.
Can you please check which version of
src/java/org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage
you have
I have:
* @version CVS $Id: SitemapLanguage.java 158074 2005-03-18 14:46:39Z
cziegeler $
And after a build clean, build the spring sample runs nicely :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Le 18 mars 05, à 17:45, Carsten Ziegeler a écrit :
>
>>...Hmm, are you using latest SVN of 2.2?..
>
>
> Confirmed, did svn up again, rm -rf build, rebuild, and
> http://localhost:8888/samples/blocks/spring-app/ says "Unknown
> component type 'application-container'" in
> CoreServiceManager.parseConfiguration(CoreServiceManager.java:644)
>
Ok, my machine is slower than yours...grmpf...wasn't even able to
build...as soon as everything is up I will fix it. Thanks for reporting!
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 18 mars 05, à 17:45, Carsten Ziegeler a écrit :
> ...Hmm, are you using latest SVN of 2.2?..
Confirmed, did svn up again, rm -rf build, rebuild, and
http://localhost:8888/samples/blocks/spring-app/ says "Unknown
component type 'application-container'" in
CoreServiceManager.parseConfiguration(CoreServiceManager.java:644)
-Bertrand
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Le 18 mars 05, à 14:41, Carsten Ziegeler a écrit :
>
>
>>I just committed the inital version under
>>https://svn.apache.org/repos/asf/cocoon/blocks/spring-app/trunk
>
>
> yoo-hooh!
>
>
>>The readme.txt explains howto include the block in the build and howto
>>see the nice example :)
>
>
> didn't work for me ("Unknown component type 'application-manager'), I
> had to add the following role definition:
>
> <role name="org.apache.cocoon.spring.SpringComponentLocator"
> shorthand="application-container"
>
> default-class="org.apache.cocoon.spring.SpringComponentLocator"/>
>
> I've hacked it into cocoon.roles as I'm not sure where to put it in the
> spring-app tree, and the sample works now.
>
> Am I missing something, or are some files missing in svn?
>
Hmm, are you using latest SVN of 2.2?
(I will check it out right now as well - I'm now using a different
computer, so if something is missing I will notice :( )
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Initial version of spring-app block
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 18 mars 05, à 14:41, Carsten Ziegeler a écrit :
> I just committed the inital version under
> https://svn.apache.org/repos/asf/cocoon/blocks/spring-app/trunk
yoo-hooh!
> The readme.txt explains howto include the block in the build and howto
> see the nice example :)
didn't work for me ("Unknown component type 'application-manager'), I
had to add the following role definition:
<role name="org.apache.cocoon.spring.SpringComponentLocator"
shorthand="application-container"
default-class="org.apache.cocoon.spring.SpringComponentLocator"/>
I've hacked it into cocoon.roles as I'm not sure where to put it in the
spring-app tree, and the sample works now.
Am I missing something, or are some files missing in svn?
-Bertrand
Re: Initial version of spring-app block
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Cool. We'll also have to prepare an announcement for TSS. You know, "The
> Spring Side" ;-)
>
LOL
Carsten
Re: Initial version of spring-app block
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Hi,
>
>I just committed the inital version under
>https://svn.apache.org/repos/asf/cocoon/blocks/spring-app/trunk
>
>
<envy>Ooooooh, happy you that have plenty of time to work on this...</envy>
This rocks :-)
>The readme.txt explains howto include the block in the build and howto
>see the nice example :)
>
>The block is not finished yet. You currently are able to define a spring
>application context on a per sitemap base and can use flow and the
>service manager to lookup your beans - a simple example for flow is
>included.
>Currently missing is the chaining of spring contexts and some further
>glue code.
>
>
Don't worry, now that the base is there, it will grow quickly :-)
>I think we should use this block as a prototype and discuss/see what
>else is needed/can be done. So everyone is of course invited to improve
>the functionality.
>
>
Cool. We'll also have to prepare an announcement for TSS. You know, "The
Spring Side" ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director