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 2006/02/07 20:41:51 UTC
[RT] Using Spring instead of ECM++
What about replacing ECM++ with Spring? I've a prototype on my harddisk
which sets up a Spring BeanFactory based on our current Avalon
configuration files (roles and xconf with includes and property
replacements). This makes all of our components real spring beans while
allowing a smooth migration path.
The benefit of this is that you can simply use Spring without any
bridging stuff or tricks. And your Spring beans can depend on the Avalon
components (and vice versa) without any problems (as there are only
Spring beans). And the container is then final no longer our business,
we just use the most used/known one.
The prototype supports all Avalon lifecycle interfaces right now - with
the exception of Poolable/Recyclable as Spring does not have a way to
release a bean. We could use our Proxy based approach for thread safe
poolables for compatibility while trying to bann all poolable components
anyway.
So what do people think?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
>
> Uh, what's a "thread safe poolable"??
>
If a thread safe component uses a poolable with ECM, you need to know
this when implementing the thread safe component. The implementation
will lookup/release the poolable whenever it needs one. Now this is of
course against the encapsulation pattern. When implementing a component
you shouldn't need to know how your dependencies are implemented.
In ECM++ I created a special handler for poolable's which creates a
proxy for the poolable component allowing to lookup a poolable inside a
thread safe component once and then simply using it. The proxy looks up
the real component whenever required and stores it in a thread local for
further access within this thread. WHen the request/response cycle
finishes, all looked up poolable components for this thread are released.
>>> anyway.
>>>
>>> So what do people think?
>
> Icannot see the implication ATM. What about stuff like ParentAware (or
> somehow) or those with Thread affinity?
We removed ParentAware and all the other stuff in 2.2 already.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote
> On Tue, 7 Feb 2006, Giacomo Pati wrote:
>
>>> On Tue, 7 Feb 2006, Carsten Ziegeler wrote:
>
>>>> So what do people think?
>
> If it is as easy and backward compatible as you say, sure +1 from here
>
I think it is - the only piece missing right now are Poolable's and the
tree processor needs to be tweaked a little bit to use this new one -
but that should be fairly easy as well.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 7 Feb 2006, Giacomo Pati wrote:
> On Tue, 7 Feb 2006, Carsten Ziegeler wrote:
>> So what do people think?
If it is as easy and backward compatible as you say, sure +1 from here
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD6QZfLNdJvZjjVZARArjOAJ9Plr2hWjp8Zwhc/56nj3BxHtEAvwCfV5QP
6M7Ci7g9gf6Ei8pqmOjQRis=
=s9SY
-----END PGP SIGNATURE-----
Re: [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 7 Feb 2006, Carsten Ziegeler wrote:
> Date: Tue, 07 Feb 2006 20:41:51 +0100
> From: Carsten Ziegeler <cz...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: Cocoon-Dev <de...@cocoon.apache.org>
> Subject: [RT] Using Spring instead of ECM++
>
> What about replacing ECM++ with Spring? I've a prototype on my harddisk
> which sets up a Spring BeanFactory based on our current Avalon
> configuration files (roles and xconf with includes and property
> replacements). This makes all of our components real spring beans while
> allowing a smooth migration path.
Haha, you're soo funny. I've had to dig deep into Spring recently and
found that almost all Avalonmight be replaceable by a Spring
BeanFactory. But I didn't had the courage to step up for now :-)
> The benefit of this is that you can simply use Spring without any
> bridging stuff or tricks. And your Spring beans can depend on the Avalon
> components (and vice versa) without any problems (as there are only
> Spring beans). And the container is then final no longer our business,
> we just use the most used/known one.
Yes.
> The prototype supports all Avalon lifecycle interfaces right now - with
> the exception of Poolable/Recyclable as Spring does not have a way to
> release a bean. We could use our Proxy based approach for thread safe
> poolables for compatibility while trying to bann all poolable components
Uh, what's a "thread safe poolable"??
> anyway.
>
> So what do people think?
Icannot see the implication ATM. What about stuff like ParentAware (or
somehow) or those with Thread affinity?
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD6QVxLNdJvZjjVZARAiImAJ9b9ldg06kNjScKoI52ciXSVzAEqQCgmC3H
C5I1tXJUbwSIbSZ7hDobQaw=
=jlm9
-----END PGP SIGNATURE-----
Re: [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Ralph Goers schrieb:
>
>
>>And if we can ban poolables once and for all then this will greatly
>>simplify things. However, I'd love to see some performance comparisons
>>on some of the sample pages (including logging into the portal) before
>>buying off on this. I'd really like to make sure that our "theory" that
>>pooling doesn't buy much is really true.
>>
>>
>>
>If it doesn't buy is performance it will buy is simplicity.
>
>
True. But if it comes with a big price tag I'd like to know it.
Ralph
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers schrieb:
> If you really can pull this off then a big +1. However....
>
> Can you post a sample configuration? I'd love to see what the mixture
> of spring and avalon-style configuration looks like.
Oh, the avalon configuration is exactly the same as we have today in
trunk and the spring configuration is the default spring one. Which
means we have (or can have) *two* configuration files (xconf + spring
xml) which are merged by the container.
>
> And if we can ban poolables once and for all then this will greatly
> simplify things. However, I'd love to see some performance comparisons
> on some of the sample pages (including logging into the portal) before
> buying off on this. I'd really like to make sure that our "theory" that
> pooling doesn't buy much is really true.
>
If it doesn't buy is performance it will buy is simplicity.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
If you really can pull this off then a big +1. However....
Can you post a sample configuration? I'd love to see what the mixture
of spring and avalon-style configuration looks like.
And if we can ban poolables once and for all then this will greatly
simplify things. However, I'd love to see some performance comparisons
on some of the sample pages (including logging into the portal) before
buying off on this. I'd really like to make sure that our "theory" that
pooling doesn't buy much is really true.
Ralph
Carsten Ziegeler wrote:
>What about replacing ECM++ with Spring? I've a prototype on my harddisk
>which sets up a Spring BeanFactory based on our current Avalon
>configuration files (roles and xconf with includes and property
>replacements). This makes all of our components real spring beans while
>allowing a smooth migration path.
>The benefit of this is that you can simply use Spring without any
>bridging stuff or tricks. And your Spring beans can depend on the Avalon
>components (and vice versa) without any problems (as there are only
>Spring beans). And the container is then final no longer our business,
>we just use the most used/known one.
>The prototype supports all Avalon lifecycle interfaces right now - with
>the exception of Poolable/Recyclable as Spring does not have a way to
>release a bean. We could use our Proxy based approach for thread safe
>poolables for compatibility while trying to bann all poolable components
>anyway.
>
>So what do people think?
>
>Carsten
>
>
Re: [RT] Using Spring instead of ECM++
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> If we want to go down this road I can commit the code to the scratchpad
> in the next days.
Please add it to trunk so that integration with blocks-fw and deployer becomes
simpler. (Otherwise we have to run Maven twice in order to get all projects
updated.)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> What about replacing ECM++ with Spring? I've a prototype on my harddisk
>> which sets up a Spring BeanFactory based on our current Avalon
>> configuration files (roles and xconf with includes and property
>> replacements). This makes all of our components real spring beans while
>> allowing a smooth migration path.
>> The benefit of this is that you can simply use Spring without any
>> bridging stuff or tricks. And your Spring beans can depend on the Avalon
>> components (and vice versa) without any problems (as there are only
>> Spring beans). And the container is then final no longer our business,
>> we just use the most used/known one.
>> The prototype supports all Avalon lifecycle interfaces right now - with
>> the exception of Poolable/Recyclable as Spring does not have a way to
>> release a bean. We could use our Proxy based approach for thread safe
>> poolables for compatibility while trying to bann all poolable components
>> anyway.
>>
>> So what do people think?
>
> It would be great to get rid of ECM++.
>
> What kind of dependencies will Cocoon get on Spring?
>
It'll depend on the springframework (core) and will not work without it.
> As we are in the process of finally getting the real blocks usable it
> would be painful to need to integrate it with a new component system
> right now. Could you make your code available somewhere so that I have
> the possibility to evaluate the consequences of it, before you start to
> commit it?
>
The current code is just a prototype. Setting up the spring bean factory
is just a "new Factory('LOCATION OF XCONF')" (this is not the exact
code, but it's near to that). This sets up the factory and provides a
service manager. For compatibility it requires a valid Context and a Logger.
If we want to go down this road I can commit the code to the scratchpad
in the next days.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> What about replacing ECM++ with Spring? I've a prototype on my harddisk
> which sets up a Spring BeanFactory based on our current Avalon
> configuration files (roles and xconf with includes and property
> replacements). This makes all of our components real spring beans while
> allowing a smooth migration path.
> The benefit of this is that you can simply use Spring without any
> bridging stuff or tricks. And your Spring beans can depend on the Avalon
> components (and vice versa) without any problems (as there are only
> Spring beans). And the container is then final no longer our business,
> we just use the most used/known one.
> The prototype supports all Avalon lifecycle interfaces right now - with
> the exception of Poolable/Recyclable as Spring does not have a way to
> release a bean. We could use our Proxy based approach for thread safe
> poolables for compatibility while trying to bann all poolable components
> anyway.
>
> So what do people think?
It would be great to get rid of ECM++.
What kind of dependencies will Cocoon get on Spring?
As we are in the process of finally getting the real blocks usable it
would be painful to need to integrate it with a new component system
right now. Could you make your code available somewhere so that I have
the possibility to evaluate the consequences of it, before you start to
commit it?
/Daniel
Re: [RT] Using Spring instead of ECM++
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.02.2006 20:41, Carsten Ziegeler wrote:
> So what do people think?
Sounds promising.
Jörg
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Reinhard Poetz <re...@apache.org>.
Upayavira wrote:
> Bertrand Delacretaz wrote:
>
>>Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
>>
>>
>>>Giacomo Pati wrote:
>>>
>>>
>>>>...What about also getting rid of logkit and use what we already have in
>>>>our dependency lists (log4J, commons-logging, ...)?
>>>>
>>>
>>>Yes, please :) I would suggest log4j as commons-logging has problems
>>>with classloading (afair) and noone is using jdk14 logging....
>>
>>
>>+1 for log4j
>
>
> +1 too.
I agree with you. log4j is the defacto-standard (at least in all my Java
projects it is used).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Upayavira <uv...@odoko.co.uk>.
Bertrand Delacretaz wrote:
> Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
>
>> Giacomo Pati wrote:
>>
>>> ...What about also getting rid of logkit and use what we already have in
>>> our dependency lists (log4J, commons-logging, ...)?
>>>
>> Yes, please :) I would suggest log4j as commons-logging has problems
>> with classloading (afair) and noone is using jdk14 logging....
>
>
> +1 for log4j
+1 too.
Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
> Giacomo Pati wrote:
>> ...What about also getting rid of logkit and use what we already have
>> in
>> our dependency lists (log4J, commons-logging, ...)?
>>
> Yes, please :) I would suggest log4j as commons-logging has problems
> with classloading (afair) and noone is using jdk14 logging....
+1 for log4j
-Bertrand
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Torsten Curdt <tc...@apache.org>.
On 14.02.2006, at 00:50, Carsten Ziegeler wrote:
> Giacomo Pati wrote:
>> On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
>>
>>>> Once we use the Spring based container we can simplify the whole
>>>> setup
>>>> process and clean up things like the CoreUtil and the Cocoon class.
>>
>> While we are at discussing cleanups.
>>
>> What about also getting rid of logkit and use what we already have in
>> our dependency lists (log4J, commons-logging, ...)?
>>
> Yes, please :) I would suggest log4j as commons-logging has problems
> with classloading (afair) and noone is using jdk14 logging.
As a side note:
There is a new release of commons-logging coming out (rc is already
available) Simon and Robert claim that most of the classloading
problems have been solved. JCL has now extensive tests for classloading.
But as long as all libraries log into the same log file I don't care
anymore ...sorry, the logging discussion finally make me go "whatever!"
cheers
--
Torsten
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Upayavira <uv...@odoko.co.uk>.
Niklas Therning wrote:
> Carsten Ziegeler wrote:
>
>>
> ...
>
>>
>> Yes, please :) I would suggest log4j as commons-logging has problems
>> with classloading (afair) and noone is using jdk14 logging.
>
>
> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
> facade for other logging frameworks but it doesn't suffer from the
> classloading problems of commons-logging. It's used by the Apache
> directory project. I think it's being developed by the guy behind log4j.
We have discussed that before. Personally, just using the de-facto
standard of Log4J, if it is capable of meeting our requirements, keeps
things simple. And simple is something that Cocoon seriously needs to be
moving towards. We've been there and done that in relation to lots of
dependencies.
Regards, Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Niklas Therning <ni...@trillian.se>.
Berin Loritsch wrote:
> Niklas Therning wrote:
>
>> Carsten Ziegeler wrote:
>>
>>>
>>> Yes, please :) I would suggest log4j as commons-logging has problems
>>> with classloading (afair) and noone is using jdk14 logging.
>>
>>
>> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's
>> a facade for other logging frameworks but it doesn't suffer from the
>> classloading problems of commons-logging. It's used by the Apache
>> directory project. I think it's being developed by the guy behind log4j.
>
>
> Given the Avalon framework interfaces, we already have a log abstraction
> using the LogEnabled and Logger interfaces. Proper wrappers are also
> provided for Log4J and have been for years. There's no value add in
> introducing YALF (Yet Another Logging Facade).
>
>
> In the future when your components have no ties to Avalon, just use
> Log4J directly.
Yes, I wouldn't have a problem with that. Just wanted to mention slf4j
for those who hadn't heard of it before. But it seem like you guys
already been discussing these thing in the past (I wouldn't know since
I'm quite new to the list).
/Niklas
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Berin Loritsch wrote:
> Date: Mon, 13 Feb 2006 09:58:06 -0500
> From: Berin Loritsch <bl...@d-haven.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
>
> Niklas Therning wrote:
>> Carsten Ziegeler wrote:
>> >
>> > Yes, please :) I would suggest log4j as commons-logging has problems
>> > with classloading (afair) and noone is using jdk14 logging.
>>
>> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
>> facade for other logging frameworks but it doesn't suffer from the
>> classloading problems of commons-logging. It's used by the Apache
>> directory project. I think it's being developed by the guy behind log4j.
>
> Given the Avalon framework interfaces, we already have a log abstraction
> using the LogEnabled and Logger interfaces. Proper wrappers are also
> provided for Log4J and have been for years. There's no value add in
> introducing YALF (Yet Another Logging Facade).
And we do have to maintain the contract mentioned interface requires for
backward compatability to the dozends of component we already have.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD8KHDLNdJvZjjVZARAlaeAKCW4kkKDFgPq+v8NKVyWT6Q1LQ6jwCfec0w
cHmzs1ofZIwV5oHP8baHbLw=
=hG9K
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Berin Loritsch <bl...@d-haven.org>.
Niklas Therning wrote:
> Carsten Ziegeler wrote:
>>
>> Yes, please :) I would suggest log4j as commons-logging has problems
>> with classloading (afair) and noone is using jdk14 logging.
>
> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's
> a facade for other logging frameworks but it doesn't suffer from the
> classloading problems of commons-logging. It's used by the Apache
> directory project. I think it's being developed by the guy behind log4j.
Given the Avalon framework interfaces, we already have a log abstraction
using the LogEnabled and Logger interfaces. Proper wrappers are also
provided for Log4J and have been for years. There's no value add in
introducing YALF (Yet Another Logging Facade).
In the future when your components have no ties to Avalon, just use
Log4J directly.
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Niklas Therning <ni...@trillian.se>.
Carsten Ziegeler wrote:
>
...
>
> Yes, please :) I would suggest log4j as commons-logging has problems
> with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
facade for other logging frameworks but it doesn't suffer from the
classloading problems of commons-logging. It's used by the Apache
directory project. I think it's being developed by the guy behind log4j.
Regards,
Niklas Therning
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
> On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
>
>>> Once we use the Spring based container we can simplify the whole setup
>>> process and clean up things like the CoreUtil and the Cocoon class.
>
> While we are at discussing cleanups.
>
> What about also getting rid of logkit and use what we already have in
> our dependency lists (log4J, commons-logging, ...)?
>
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
> I think we definitively need to get a smaller footprint and also get
> committed to fewer alternatives (of which we do have too many now IMHO,
Exactly :)
> not mentioning other stuff we carry with us just because we do have them
> since years).
So true!
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati schrieb:
>>> Now, with Spring I would suggest the following approach:
>>> Cocoon uses an own application context which can be compared (by
>>> simplifying) with a service manager. So we have an application context
>>> for the core of Cocoon (again simplified). Now you can define a root
>>> Spring application context using the usual Spring context listener and
>>> this one (if present) will be the parent context of our Cocoon core context.
>>> If you define your own logger bean in this spring application context,
>>> Cocoon will use that logger instead. If the spring app context is
>>> missing or does not define a logger bean we will define a log4j logger
>>> in the core application context. So it would be possible to use your own
>>> logging abstraction while Cocoon does nearly nothing to support it.
>
> This is meant for traditional Avalon Components implementing LogEnabled,
> right?
>
Yes.
> Anyway here's my +1 for it.
>
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 15 Feb 2006, Carsten Ziegeler wrote:
> Date: Wed, 15 Feb 2006 14:20:12 +0100
> From: Carsten Ziegeler <cz...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
>
> Ralph Goers wrote:
>> If that is the case then I'm -1 on this. We use our own logging framework
>> with Cocoon.
> I knew this would happen :) Ok, anyway, I would like to get rid off
> excalibur
> logging and logkit. Which means, we only use the o.a.a.logging.Logger
> abstraction which is passed to a component through LogEnabled. And we
> configure a Log4J logger by default for this abstraction.
>
> Now, with Spring I would suggest the following approach:
> Cocoon uses an own application context which can be compared (by
> simplifying) with a service manager. So we have an application context
> for the core of Cocoon (again simplified). Now you can define a root
> Spring application context using the usual Spring context listener and
> this one (if present) will be the parent context of our Cocoon core context.
> If you define your own logger bean in this spring application context,
> Cocoon will use that logger instead. If the spring app context is
> missing or does not define a logger bean we will define a log4j logger
> in the core application context. So it would be possible to use your own
> logging abstraction while Cocoon does nearly nothing to support it.
This is meant for traditional Avalon Components implementing LogEnabled,
right?
Anyway here's my +1 for it.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD84DLLNdJvZjjVZARAjIqAKDmSaZJp+Ulj5r5edAbe7dNDot/HQCgoztp
nC3wMxOtnN103AF7Wju6Dgc=
=HhsQ
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> I knew this would happen :) Ok, anyway, I would like to get rid off
> excalibur
> logging and logkit. Which means, we only use the o.a.a.logging.Logger
> abstraction which is passed to a component through LogEnabled. And we
> configure a Log4J logger by default for this abstraction.
>
> Now, with Spring I would suggest the following approach:
> Cocoon uses an own application context which can be compared (by
> simplifying) with a service manager. So we have an application context
> for the core of Cocoon (again simplified). Now you can define a root
> Spring application context using the usual Spring context listener and
> this one (if present) will be the parent context of our Cocoon core context.
> If you define your own logger bean in this spring application context,
> Cocoon will use that logger instead. If the spring app context is
> missing or does not define a logger bean we will define a log4j logger
> in the core application context. So it would be possible to use your own
> logging abstraction while Cocoon does nearly nothing to support it.
>
> WDYT?
This works great for me! If the LogManager implementation can be
configured in Spring that would be awesome.
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> If that is the case then I'm -1 on this. We use our own logging framework
> with Cocoon.
I knew this would happen :) Ok, anyway, I would like to get rid off
excalibur
logging and logkit. Which means, we only use the o.a.a.logging.Logger
abstraction which is passed to a component through LogEnabled. And we
configure a Log4J logger by default for this abstraction.
Now, with Spring I would suggest the following approach:
Cocoon uses an own application context which can be compared (by
simplifying) with a service manager. So we have an application context
for the core of Cocoon (again simplified). Now you can define a root
Spring application context using the usual Spring context listener and
this one (if present) will be the parent context of our Cocoon core context.
If you define your own logger bean in this spring application context,
Cocoon will use that logger instead. If the spring app context is
missing or does not define a logger bean we will define a log4j logger
in the core application context. So it would be possible to use your own
logging abstraction while Cocoon does nearly nothing to support it.
WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Giacomo Pati wrote:
> -
> Can you explain how you use your own under Cocoon? Separate LogEnabled
> impls? CommonsLogging?
I implement org.apache.avalon.excalibur.logging.LoggerManager and
org.apache.avalon.excalibur.logging.Logger. These then interface with
my logging framework.
Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Ralph Goers wrote:
> Date: Mon, 13 Feb 2006 13:16:37 -0800 (PST)
> From: Ralph Goers <Ra...@dslextreme.com>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
>
> Carsten Ziegeler said:
>> Ralph Goers wrote:
>>> Carsten Ziegeler said:
>>> What do you mean by "always"? I thought that we switched the default
>>> from
>>> logkit to log4j a while ago? What more is needed?
>>>
>> This switch never happened - the idea behind this is to remove the
>> support for other logging frameworks completly. No more "you can use
>> this or you can use that or you can implement your own", but a simple
>> "use log4j".
>>
> If that is the case then I'm -1 on this. We use our own logging framework
> with Cocoon.
Can you explain how you use your own under Cocoon? Separate LogEnabled
impls? CommonsLogging?
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD8Q4hLNdJvZjjVZARAp62AJ92Hg0ekydAdKmzdwnZiG+dMQ4RCQCfYXsw
W/ed3irPnhqg09jTL9D9BvY=
=9wQc
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler said:
> Ralph Goers wrote:
>> Carsten Ziegeler said:
>> What do you mean by "always"? I thought that we switched the default
>> from
>> logkit to log4j a while ago? What more is needed?
>>
> This switch never happened - the idea behind this is to remove the
> support for other logging frameworks completly. No more "you can use
> this or you can use that or you can implement your own", but a simple
> "use log4j".
>
If that is the case then I'm -1 on this. We use our own logging framework
with Cocoon.
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> Carsten Ziegeler said:
>> Giacomo Pati wrote:
>>
>>> If the logger abstraction you mentioned is the Avalon LogEnabled one
>>> than yes, we will still have to support that for backward compatability.
>>>
>> Of course we will support LogEnabled - with the only difference that you
>> always get a wrapper around a Log4J (or whatever we decide) logger.
>
> What do you mean by "always"? I thought that we switched the default from
> logkit to log4j a while ago? What more is needed?
>
This switch never happened - the idea behind this is to remove the
support for other logging frameworks completly. No more "you can use
this or you can use that or you can implement your own", but a simple
"use log4j".
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler said:
> Giacomo Pati wrote:
>
>>
>> If the logger abstraction you mentioned is the Avalon LogEnabled one
>> than yes, we will still have to support that for backward compatability.
>>
> Of course we will support LogEnabled - with the only difference that you
> always get a wrapper around a Log4J (or whatever we decide) logger.
What do you mean by "always"? I thought that we switched the default from
logkit to log4j a while ago? What more is needed?
Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
>
> If the logger abstraction you mentioned is the Avalon LogEnabled one
> than yes, we will still have to support that for backward compatability.
>
Of course we will support LogEnabled - with the only difference that you
always get a wrapper around a Log4J (or whatever we decide) logger.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Ralph Goers wrote:
> Date: Mon, 13 Feb 2006 07:07:58 -0800
> From: Ralph Goers <Ra...@dslextreme.com>
> Reply-To: dev@cocoon.apache.org, rgoers@apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
>
> Giacomo Pati wrote:
>>
>> While we are at discussing cleanups.
>>
>> What about also getting rid of logkit and use what we already have in our
>> dependency lists (log4J, commons-logging, ...)?
>>
>> I think we definitively need to get a smaller footprint and also get
>> committed to fewer alternatives (of which we do have too many now IMHO,
>> not mentioning other stuff we carry with us just because we do have them
>> since years).
> I thought we already discussed this and made log4j the default? If that is
> the proposal, I'm fine with it. If the proposal means getting rid of our
> Logger abstraction layer I'm -1 on that.
If the logger abstraction you mentioned is the Avalon LogEnabled one
than yes, we will still have to support that for backward compatability.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD8KJ6LNdJvZjjVZARAulkAJ0Td8xAWkSHgVvdBrS+QbiLy8RbuQCfdrV4
SRnldYHsPL4ohOutML/9h2k=
=zl97
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Giacomo Pati wrote:
>
> While we are at discussing cleanups.
>
> What about also getting rid of logkit and use what we already have in
> our dependency lists (log4J, commons-logging, ...)?
>
> I think we definitively need to get a smaller footprint and also get
> committed to fewer alternatives (of which we do have too many now
> IMHO, not mentioning other stuff we carry with us just because we do
> have them since years).
I thought we already discussed this and made log4j the default? If that
is the proposal, I'm fine with it. If the proposal means getting rid of
our Logger abstraction layer I'm -1 on that.
Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Sylvain Wallez <sy...@apache.org>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
>
>> Once we use the Spring based container we can simplify the whole setup
>> process and clean up things like the CoreUtil and the Cocoon class.
>
> While we are at discussing cleanups.
>
> What about also getting rid of logkit and use what we already have in
> our dependency lists (log4J, commons-logging, ...)?
>
> I think we definitively need to get a smaller footprint and also get
> committed to fewer alternatives (of which we do have too many now
> IMHO, not mentioning other stuff we carry with us just because we do
> have them since years).
+0.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
> Once we use the Spring based container we can simplify the whole setup
> process and clean up things like the CoreUtil and the Cocoon class.
While we are at discussing cleanups.
What about also getting rid of logkit and use what we already have in
our dependency lists (log4J, commons-logging, ...)?
I think we definitively need to get a smaller footprint and also get
committed to fewer alternatives (of which we do have too many now IMHO,
not mentioning other stuff we carry with us just because we do have them
since years).
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD8IrdLNdJvZjjVZARAoi+AKCDTGanvWO2Hkz0nPOmRrw78qevKwCgnqft
fxZ9hMImd577AtnyHF1pYrA=
=gP3Y
-----END PGP SIGNATURE-----
Re: [RT] Using Spring instead of ECM++
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Ralph Goers schrieb:
>> Carsten Ziegeler said:
>>> Daniel Fagerstrom wrote:
>>>> It depends on how long time you think that it will take. If you think
>>>> that it take a week or so I suggest that you branch cocoon-core, and
>>>> work on the branch until it works again and merge it back then. In the
>>>> meantime the rest of us try to avoid doing larger changes in cocoon-core
>>>> trunk.
>>>>
>>>> If it takes like a month or so, it is better to try to do some splitting
>>>> of cocoon-core first, so that you only need to branch the tree-processor
>>>> and the top layer that contain the Cocoon object.
>>> Ok, I think this will take one or two days until Cocoon runs again while
>>> it might take a little bit longer to polish everything.
>> Really? I haven't been able to get a running portal on trunk in a while,
>> so I'll look forward to being able to have that back in a couple of days.
>>
> Ah, sorry, again one of my too short sentences: no, I'm not able to run
> the portal or any other block right now and I don't have a clue how to
> fix this. I meant that I need one or two days to replace ECM++ with
> Spring and then Cocoon runs again in the same way it runs today. Getting
> the blocks/samples run again is currently out of my scope for the Spring
> integration.
> But I really would love to have running stuff again :)
I think everything run today, it is only that no one have cared to try.
AFAIK, we hadn't made any changes of core that should affect anything
since the M10N. All blocks work have been done in separate projects.
So the cocoon-webapp when I tried it the last time (mvn war:inplace
jetty6:run). That is without blocks. To add blocks it should be enough
to 1) add them to the dependencies in the cocoon-webapp POM. 2) copy the
content of src/main/resources/WEB-INF to the
cocoon-webapp/src/main/webapp/WEB-INF. AFAICS, the only thing that would
be required to make Cocoon trunk work as before the M10N, would be to
write a Maven plugin that does this copying automatically for the
configuration files in blocks.
I haven't done it because I'm more thrilled about getting the real
blocks to work. But for those of you that work on blocks like the
portal, it would certainly be worthwhile.
/Daniel
Re: [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler said:
>>
> Ah, sorry, again one of my too short sentences: no, I'm not able to run
> the portal or any other block right now and I don't have a clue how to
> fix this. I meant that I need one or two days to replace ECM++ with
> Spring and then Cocoon runs again in the same way it runs today. Getting
> the blocks/samples run again is currently out of my scope for the Spring
> integration.
> But I really would love to have running stuff again :)
I guess you are braver than me. I haven't checked in my change to
EncodeURLTransformer into trunk because I don't know how to test it.
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers schrieb:
> Carsten Ziegeler said:
>> Daniel Fagerstrom wrote:
>>> It depends on how long time you think that it will take. If you think
>>> that it take a week or so I suggest that you branch cocoon-core, and
>>> work on the branch until it works again and merge it back then. In the
>>> meantime the rest of us try to avoid doing larger changes in cocoon-core
>>> trunk.
>>>
>>> If it takes like a month or so, it is better to try to do some splitting
>>> of cocoon-core first, so that you only need to branch the tree-processor
>>> and the top layer that contain the Cocoon object.
>> Ok, I think this will take one or two days until Cocoon runs again while
>> it might take a little bit longer to polish everything.
>
> Really? I haven't been able to get a running portal on trunk in a while,
> so I'll look forward to being able to have that back in a couple of days.
>
Ah, sorry, again one of my too short sentences: no, I'm not able to run
the portal or any other block right now and I don't have a clue how to
fix this. I meant that I need one or two days to replace ECM++ with
Spring and then Cocoon runs again in the same way it runs today. Getting
the blocks/samples run again is currently out of my scope for the Spring
integration.
But I really would love to have running stuff again :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler said:
> Daniel Fagerstrom wrote:
>> It depends on how long time you think that it will take. If you think
>> that it take a week or so I suggest that you branch cocoon-core, and
>> work on the branch until it works again and merge it back then. In the
>> meantime the rest of us try to avoid doing larger changes in cocoon-core
>> trunk.
>>
>> If it takes like a month or so, it is better to try to do some splitting
>> of cocoon-core first, so that you only need to branch the tree-processor
>> and the top layer that contain the Cocoon object.
> Ok, I think this will take one or two days until Cocoon runs again while
> it might take a little bit longer to polish everything.
Really? I haven't been able to get a running portal on trunk in a while,
so I'll look forward to being able to have that back in a couple of days.
Re: [RT] Using Spring instead of ECM++
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> It depends on how long time you think that it will take. If you think
>> that it take a week or so I suggest that you branch cocoon-core, and
>> work on the branch until it works again and merge it back then. In the
>> meantime the rest of us try to avoid doing larger changes in cocoon-core
>> trunk.
>>
>> If it takes like a month or so, it is better to try to do some splitting
>> of cocoon-core first, so that you only need to branch the tree-processor
>> and the top layer that contain the Cocoon object.
> Ok, I think this will take one or two days until Cocoon runs again while
> it might take a little bit longer to polish everything.
A branch of cocoon-core then.
>> In any case it must be done in a branch. We are making good progress
>> with the blocks work, and having a cocoon-core that doesn't would be a
>> far to large disruption.
>>
> I'm wondering if I'm changing the right place. Now the switch to Spring
> is finished cocoon-core will look different (less use of Avalon). Now,
> has this any influence on the blocks implementation like block-fw?
Probably ;)
Take a look at the BlockManager. It first set up a container which for
the moment is hardwired to o.a.c.container.ECMBlockServiceManager, but
could be another container. The container is supposed to register the
components that it want to make available to other block in a
ServiceManagerRegistry, and it get components from other container
through it parent manager (also the ServiceManagerRegsitry).
Then a block servlet (typically o.a.c.sitemap.SitemapServlet that
contains the tree processor) is set up and is given the component
manager of the block.
The contract for the Container is probably not the best possible, but I
needed something to be able to continue. Comments are welcome.
> I looked there briefly and saw that for example ServiceManager is used
> there for getting components from a block. We should change that as well
> and perhaps use our own interface?
Maybe, it was first idea as well. But the ServiceManager is a rather
generic interface, so I don't see that we would find something
different, so I don't see what it would by us to change.
And in the somewhat longer perspective I would prefer using the OSGi
interfaces for service management.
> And if the cocoon-core uses Spring what has to be done in the blocks-fw?
I don't know how you are planning to integrate Spring, so it is hard to
answer.
If we think about it, the main reason for having a component manager
within the sitemap and even in subsitemaps, is that 1)
sitemap-components and ordinary components was supposed to be different
concern in early Cocoon designs, and 2) that subsitemaps has been the
major mechanism for modularizing large applications.
We don't care about the difference between sitemap-components and
ordinary components anymore and with blocks there is a better
modularization mechanism than subsitemaps. So question is why we should
configure components within sitemaps anymore. IMO it is a mix of concern
and makes the tree-processor unnecessarily complicated.
So I don't know if the tree-processor should use Spring (or any other
component manager) anymore, it would be enough to just feed it a service
manager.
The Cocoon object and the CocoonServlet are not used anymore in the
blocks fw. I tried to adapt to them early on but it required to much
work to integrate the blocks within them without risking to disturb the
rest of the system. Besides that, the setup sequence tended to give me
severe headache, so I rewrote it to something less flexible and less
complicated.
/Daniel
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> It depends on how long time you think that it will take. If you think
> that it take a week or so I suggest that you branch cocoon-core, and
> work on the branch until it works again and merge it back then. In the
> meantime the rest of us try to avoid doing larger changes in cocoon-core
> trunk.
>
> If it takes like a month or so, it is better to try to do some splitting
> of cocoon-core first, so that you only need to branch the tree-processor
> and the top layer that contain the Cocoon object.
Ok, I think this will take one or two days until Cocoon runs again while
it might take a little bit longer to polish everything.
>
> In any case it must be done in a branch. We are making good progress
> with the blocks work, and having a cocoon-core that doesn't would be a
> far to large disruption.
>
I'm wondering if I'm changing the right place. Now the switch to Spring
is finished cocoon-core will look different (less use of Avalon). Now,
has this any influence on the blocks implementation like block-fw?
I looked there briefly and saw that for example ServiceManager is used
there for getting components from a block. We should change that as well
and perhaps use our own interface?
And if the cocoon-core uses Spring what has to be done in the blocks-fw?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
> Ok, I just committed the initial prototyp. The spring based container is
> setup in the Cocoon class (in initialize). I think I've covered most of
> the Avalon stuff including pooled components (but have not tested this).
> The remaining part would be to use the spring based container instead of
> ECM++ which requires changes in the Cocoon class and in the tree
> processor. Changing the Cocoon class should be fairly easy while the
> tree processor is more work. Now, this work can't be done without
> possibly breaking Cocoon until the work is finished. So how do we proceed?
>
> Once we use the Spring based container we can simplify the whole setup
> process and clean up things like the CoreUtil and the Cocoon class.
>
It depends on how long time you think that it will take. If you think
that it take a week or so I suggest that you branch cocoon-core, and
work on the branch until it works again and merge it back then. In the
meantime the rest of us try to avoid doing larger changes in cocoon-core
trunk.
If it takes like a month or so, it is better to try to do some splitting
of cocoon-core first, so that you only need to branch the tree-processor
and the top layer that contain the Cocoon object.
In any case it must be done in a branch. We are making good progress
with the blocks work, and having a cocoon-core that doesn't would be a
far to large disruption.
/Daniel
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Ok, I just committed the initial prototyp. The spring based container is
setup in the Cocoon class (in initialize). I think I've covered most of
the Avalon stuff including pooled components (but have not tested this).
The remaining part would be to use the spring based container instead of
ECM++ which requires changes in the Cocoon class and in the tree
processor. Changing the Cocoon class should be fairly easy while the
tree processor is more work. Now, this work can't be done without
possibly breaking Cocoon until the work is finished. So how do we proceed?
Once we use the Spring based container we can simplify the whole setup
process and clean up things like the CoreUtil and the Cocoon class.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> Leszek Gawron wrote:
>>> Carsten Ziegeler wrote:
>>>> So what do people think?
>>> I haven't read any other replies yet but my small brain tells me to be
>>> +100 on this one.
>> I don't have any objections either - especially since it is backward compatible
>> both from component and configuration POV.
>>
> I'll try to commit some parts of it tomorrow, so others can pick it up
> and perhaps help polishing it.
>
Damn, I just noticed that I left my usb stick with the code on it at my
company, so I'll commit it on monday or tuesday then. Grmpf.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>> So what do people think?
>> I haven't read any other replies yet but my small brain tells me to be
>> +100 on this one.
>
> I don't have any objections either - especially since it is backward compatible
> both from component and configuration POV.
>
I'll try to commit some parts of it tomorrow, so others can pick it up
and perhaps help polishing it.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>> So what do people think?
> I haven't read any other replies yet but my small brain tells me to be
> +100 on this one.
I don't have any objections either - especially since it is backward compatible
both from component and configuration POV.
Vadim
Re: [RT] Using Spring instead of ECM++
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> What about replacing ECM++ with Spring? I've a prototype on my harddisk
> which sets up a Spring BeanFactory based on our current Avalon
> configuration files (roles and xconf with includes and property
> replacements). This makes all of our components real spring beans while
> allowing a smooth migration path.
> The benefit of this is that you can simply use Spring without any
> bridging stuff or tricks. And your Spring beans can depend on the Avalon
> components (and vice versa) without any problems (as there are only
> Spring beans). And the container is then final no longer our business,
> we just use the most used/known one.
> The prototype supports all Avalon lifecycle interfaces right now - with
> the exception of Poolable/Recyclable as Spring does not have a way to
> release a bean. We could use our Proxy based approach for thread safe
> poolables for compatibility while trying to bann all poolable components
> anyway.
>
> So what do people think?
I haven't read any other replies yet but my small brain tells me to be
+100 on this one. I already am in uncomfortable situation of configuring
my own spring xml parser just because I cannot use cocoon's one in spring.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Ugo Cei wrote:
> Il giorno 07/feb/06, alle ore 20:41, Carsten Ziegeler ha scritto:
>
>> What about replacing ECM++ with Spring?
>
> I don't think I have to tell you how much I would love that. However,
> I'm a bit confused, but it's really my fault, as I haven't been
> following at all the recent realblocks/osgi/2.2 talk and
> developments. Is this for 2.1, 2.2, 3.0? How does it relate to OSGi
> and "Real Blocks" (TM)?
>
I would like to do this for 2.2. I actually don't know how this relates to
real blocks and all this stuff as I currently have no idea how that will
work. So for me this is just a replacement for our ECM++.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 07/feb/06, alle ore 20:41, Carsten Ziegeler ha scritto:
> What about replacing ECM++ with Spring?
I don't think I have to tell you how much I would love that. However,
I'm a bit confused, but it's really my fault, as I haven't been
following at all the recent realblocks/osgi/2.2 talk and
developments. Is this for 2.1, 2.2, 3.0? How does it relate to OSGi
and "Real Blocks" (TM)?
Ugo
--
Ugo Cei
Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Evil or Not?: http://evilornot.info/
Company: http://www.sourcesense.com/
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> You mean these are separate files each using their own format that are
> merged in a single DOM for the ApplicationContext?
>
Yes, exactly (though technically I'm not using a DOM for this)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> A few questions that quickly popped up:
>> - is it implemented as a BeanPostProcessor that implements the Avalon
>> lifecycle interfaces?
>>
> Yupp, it's a DestructionAwareBeanPostProcessor to support Dispose and
> Startable#stop.
>
>> - how is defined the configuration of a Configurable?
>>
> Configurable is still used by the Avalon components of course and this
> used the same old xconf - so if you define Avalon components, use the
> xconf, if you define "real" beans use the application context
> definition. Both are merged into one big configuration file for spring.
>
You mean these are separate files each using their own format that are
merged in a single DOM for the ApplicationContext?
>> - how can a POJO access the Context: does it still have to implement
>> Contexualizable, or is the context available as a regular bean?
>>
> It's available as a bean, like the service manager or the logger are as
> well.
>
Great.
>> - what is the format of the configuration file?
>>
> Two options: either old xconf/roles style (where old means 2.2 version
> with included) and default spring xml configuration.
>
>> - what about ServiceSelectors?
>>
> Are simply wrappers around the bean factory which forward the lookup. So
> looking up a "GeneratorSelector" and then select component "file" is the
> same as looking up "Generator/file" from the bean factory or the
> provided service manager. The service manager is a wrapper around the
> bean factory as well.
>
Ah yes. I forgot that we already had flattened selectors in ECM++ :-)
Sounds good!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> A few questions that quickly popped up:
> - is it implemented as a BeanPostProcessor that implements the Avalon
> lifecycle interfaces?
Yupp, it's a DestructionAwareBeanPostProcessor to support Dispose and
Startable#stop.
> - how is defined the configuration of a Configurable?
Configurable is still used by the Avalon components of course and this
used the same old xconf - so if you define Avalon components, use the
xconf, if you define "real" beans use the application context
definition. Both are merged into one big configuration file for spring.
> - how can a POJO access the Context: does it still have to implement
> Contexualizable, or is the context available as a regular bean?
It's available as a bean, like the service manager or the logger are as
well.
> - what is the format of the configuration file?
Two options: either old xconf/roles style (where old means 2.2 version
with included) and default spring xml configuration.
> - what about ServiceSelectors?
Are simply wrappers around the bean factory which forward the lookup. So
looking up a "GeneratorSelector" and then select component "file" is the
same as looking up "Generator/file" from the bean factory or the
provided service manager. The service manager is a wrapper around the
bean factory as well.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> What about replacing ECM++ with Spring? I've a prototype on my harddisk
> which sets up a Spring BeanFactory based on our current Avalon
> configuration files (roles and xconf with includes and property
> replacements). This makes all of our components real spring beans while
> allowing a smooth migration path.
> The benefit of this is that you can simply use Spring without any
> bridging stuff or tricks. And your Spring beans can depend on the Avalon
> components (and vice versa) without any problems (as there are only
> Spring beans). And the container is then final no longer our business,
> we just use the most used/known one.
> The prototype supports all Avalon lifecycle interfaces right now - with
> the exception of Poolable/Recyclable as Spring does not have a way to
> release a bean. We could use our Proxy based approach for thread safe
> poolables for compatibility while trying to bann all poolable components
> anyway.
>
> So what do people think?
>
A few questions that quickly popped up:
- is it implemented as a BeanPostProcessor that implements the Avalon
lifecycle interfaces?
- how is defined the configuration of a Configurable?
- how can a POJO access the Context: does it still have to implement
Contexualizable, or is the context available as a regular bean?
- what is the format of the configuration file?
- what about ServiceSelectors?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Using Spring instead of ECM++
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 7 févr. 06, à 20:41, Carsten Ziegeler a écrit :
> ...So what do people think?
IIUC one would be able to recompile existing code, including
Avalon-based components, with no or minor changes?
Sounds like a dream come true: big +1 here.
-Bertrand