You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2006/05/17 12:18:24 UTC
RAD with Cocoon 2.2
Maven brings a lot of advantages to standardize the development process but also
makes development of applications more difficult as you spread your applications
over different artifacts.
In the light of this I think we should revert our removal of the per-sitemap
classloading
(http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2). As the
removal was part of a refactoring of the sitemap engine, could sombody give me a
description of what needs to be done?
--
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: RAD with Cocoon 2.2
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 17 May 2006, Daniel Fagerstrom wrote:
> Date: Wed, 17 May 2006 13:12:11 +0200
> From: Daniel Fagerstrom <da...@nada.kth.se>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: RAD with Cocoon 2.2
>
> Reinhard Poetz skrev:
>>
>> Maven brings a lot of advantages to standardize the development process
>> but also makes development of applications more difficult as you spread
>> your applications over different artifacts.
>>
>> In the light of this I think we should revert our removal of the
>> per-sitemap classloading
>> (http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2). As
>> the removal was part of a refactoring of the sitemap engine, could sombody
>> give me a description of what needs to be done?
>>
> I agree that RAD is important, but I would prefer to put the dynamic
> classloading in the block level container rather than within the sitemap.
> Component handling within the sitemap is mix of concern IMO. I know that it
> has been a must for this far, as sub sitemap has been the only mechanism for
> modularization. But with blocks we have a much better mechanism for
> modularization so I think we should focus on that and maybe even deprecate
> the sitemap component declarations.
Nah, how about a block that itself has sub-sitemaps (to modularize block
concerns)? I don't like it to be deprecated exactly because of that.
- --
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.3 (GNU/Linux)
iD8DBQFEbBzYLNdJvZjjVZARAsJcAKDH43jWAkLwYDIqJuTgHW3I7nayiQCgilgw
RZWVcTbZreufnctc1w0zSe8=
=iTTw
-----END PGP SIGNATURE-----
Re: RAD with Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz skrev:
>
>>
>> Maven brings a lot of advantages to standardize the development
>> process but also makes development of applications more difficult as
>> you spread your applications over different artifacts.
>>
>> In the light of this I think we should revert our removal of the
>> per-sitemap classloading
>> (http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2).
>> As the removal was part of a refactoring of the sitemap engine, could
>> sombody give me a description of what needs to be done?
>>
> I agree that RAD is important, but I would prefer to put the dynamic
> classloading in the block level container rather than within the
> sitemap. Component handling within the sitemap is mix of concern IMO.
I agree
> I
> know that it has been a must for this far, as sub sitemap has been the
> only mechanism for modularization. But with blocks we have a much better
> mechanism for modularization so I think we should focus on that and
> maybe even deprecate the sitemap component declarations.
With 2.2 blocks are only deployment units. Within Cocoon 2.2 there is no concept
of blocks, no blocks protocol, no shielded classloader (I know that you know but
just to speak it out)
> By separating the dynamic classloading from the sitemap and connect it
> to the container, we simplify our architecture considerably. Also
> dynamic classloading could be interesting for other Spring users, so
> maybe we could even cooperate with the Spring community about it.
hmm, not sure if I understand what you mean. IIUC each sitemap has its own
Spring bean factory (container). Do you want to make the classloader, which is
used to create the bean factory, configureable?
--
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: RAD with Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Hopefully you can use the same configuration files for both versions, so
> only the includes are at a different location.
Yes, that's already implemented in C3.
--
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: RAD with Cocoon 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>
>> Now I think that per sitemap configuration and even per sitemap class
>> loading are key features of 2.2. I see no need to deprecate them or
>> something like this.
>
> With Cocoon 3.0 and applications that are really split into blocks, we should
> only support one way of application modularization
Exactly.
> and I agree with Daniel that
> this should be at the block level.
Totally agree.
> But things like this don't need to be decided today.
>
>> With 2.2 you include your component configs from
>> the sitemap and you define your classpath in the sitemap. With real
>> blocks there are only minimal changes as you just have to remove the
>> include and the classpath definition from your sitemap and but these
>> somewhere in the block config - and that's it. Your configuration of
>> your components stays the same.
>
> right except that each block already has it's own classloader (remember, OSGi
> ;-) ...).
Yes, that was actually what I meant :)
Cocoon 2.2: Configuration at sitemap level (Includes)
Cocoon 3.0: Configuration at block level
Hopefully you can use the same configuration files for both versions, so
only the includes are at a different location.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: RAD with Cocoon 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
> Well, in this case we need to deprecate the map:mount element. Are we
> willing to do that?
>
Personally, I think, yes. A already wrote an RT about this some weeks a
go, but I'm still waiting for the right time to send it...
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: RAD with Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 17 May 2006, Reinhard Poetz wrote:
>
>> Date: Wed, 17 May 2006 15:56:23 +0200
>> From: Reinhard Poetz <re...@apache.org>
>> Reply-To: dev@cocoon.apache.org
>> To: dev@cocoon.apache.org
>> Subject: Re: RAD with Cocoon 2.2
>>
>> Carsten Ziegeler wrote:
>>
>>> Now I think that per sitemap configuration and even per sitemap class
>>> loading are key features of 2.2. I see no need to deprecate them or
>>> something like this.
>>
>>
>> With Cocoon 3.0 and applications that are really split into blocks, we
>> should only support one way of application modularization and I agree
>> with Daniel that this should be at the block level. But things like
>> this don't need to be decided today.
>
>
> Well, in this case we need to deprecate the map:mount element. Are we
> willing to do that?
na, that might be too much ;-)
What I'm concerned about is that with OSGi we're using a framework that takes
care of classloading by providing shielded classloaders and we would alter the
classloader too.
I propose that we continue our discussion when we are preparing the first C3
release.
- o -
So what do we want? IMO we should release Cocoon 2.2 very soon and not adding
<map:classloader> would lead to a major feature loss. Daniel, I understand your
concerns (see above) but without the <map:classloader> C22 development doesn't
make much fun because of the continious container restarts. WDYT?
--
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: RAD with Cocoon 2.2
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 17 May 2006, Reinhard Poetz wrote:
> Date: Wed, 17 May 2006 15:56:23 +0200
> From: Reinhard Poetz <re...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: RAD with Cocoon 2.2
>
> Carsten Ziegeler wrote:
>
>> Now I think that per sitemap configuration and even per sitemap class
>> loading are key features of 2.2. I see no need to deprecate them or
>> something like this.
>
> With Cocoon 3.0 and applications that are really split into blocks, we should
> only support one way of application modularization and I agree with Daniel
> that this should be at the block level. But things like this don't need to be
> decided today.
Well, in this case we need to deprecate the map:mount element. Are we
willing to do that?
- --
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.3 (GNU/Linux)
iD8DBQFEbB3DLNdJvZjjVZARArUrAKCCXGXUUAGBc5Mm5gNDMEz7RQtYAwCeLGMf
wr9nqaqiqvWoQqRdSwviU4Q=
=zDvQ
-----END PGP SIGNATURE-----
Re: RAD with Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Now I think that per sitemap configuration and even per sitemap class
> loading are key features of 2.2. I see no need to deprecate them or
> something like this.
With Cocoon 3.0 and applications that are really split into blocks, we should
only support one way of application modularization and I agree with Daniel that
this should be at the block level. But things like this don't need to be decided
today.
> With 2.2 you include your component configs from
> the sitemap and you define your classpath in the sitemap. With real
> blocks there are only minimal changes as you just have to remove the
> include and the classpath definition from your sitemap and but these
> somewhere in the block config - and that's it. Your configuration of
> your components stays the same.
right except that each block already has it's own classloader (remember, OSGi
;-) ...).
--
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: RAD with Cocoon 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom schrieb:
> Reinhard Poetz skrev:
>> Maven brings a lot of advantages to standardize the development
>> process but also makes development of applications more difficult as
>> you spread your applications over different artifacts.
>>
>> In the light of this I think we should revert our removal of the
>> per-sitemap classloading
>> (http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2).
>> As the removal was part of a refactoring of the sitemap engine, could
>> sombody give me a description of what needs to be done?
>>
> I agree that RAD is important, but I would prefer to put the dynamic
> classloading in the block level container rather than within the
> sitemap. Component handling within the sitemap is mix of concern IMO. I
> know that it has been a must for this far, as sub sitemap has been the
> only mechanism for modularization. But with blocks we have a much better
> mechanism for modularization so I think we should focus on that and
> maybe even deprecate the sitemap component declarations.
>
> By separating the dynamic classloading from the sitemap and connect it
> to the container, we simplify our architecture considerably. Also
> dynamic classloading could be interesting for other Spring users, so
> maybe we could even cooperate with the Spring community about it.
>
Now I think that per sitemap configuration and even per sitemap class
loading are key features of 2.2. I see no need to deprecate them or
something like this. With 2.2 you include your component configs from
the sitemap and you define your classpath in the sitemap. With real
blocks there are only minimal changes as you just have to remove the
include and the classpath definition from your sitemap and but these
somewhere in the block config - and that's it. Your configuration of
your components stays the same.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: RAD with Cocoon 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
>
> Maven brings a lot of advantages to standardize the development
> process but also makes development of applications more difficult as
> you spread your applications over different artifacts.
>
> In the light of this I think we should revert our removal of the
> per-sitemap classloading
> (http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2).
> As the removal was part of a refactoring of the sitemap engine, could
> sombody give me a description of what needs to be done?
>
I agree that RAD is important, but I would prefer to put the dynamic
classloading in the block level container rather than within the
sitemap. Component handling within the sitemap is mix of concern IMO. I
know that it has been a must for this far, as sub sitemap has been the
only mechanism for modularization. But with blocks we have a much better
mechanism for modularization so I think we should focus on that and
maybe even deprecate the sitemap component declarations.
By separating the dynamic classloading from the sitemap and connect it
to the container, we simplify our architecture considerably. Also
dynamic classloading could be interesting for other Spring users, so
maybe we could even cooperate with the Spring community about it.
/Daniel
Re: RAD with Cocoon 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>> Maven brings a lot of advantages to standardize the development
>> process but also makes development of applications more difficult as
>> you spread your applications over different artifacts.
>>
>> In the light of this I think we should revert our removal of the
>> per-sitemap classloading
>> (http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2).
>> As the removal was part of a refactoring of the sitemap engine, could
>> sombody give me a description of what needs to be done?
>
> The main idea is to create a classloader with what is defined by
> <map:classpath> in the sitemap, and use that classloader to create the
> container for components in <map:components>
>
> This is achieved by giving this classloader to the container (was
> possible with ECM, don't know with Spring) and setting it as the
> thread's default classloader before processing a request in the sitemap
> (and restoring the old one at the end).
>
Afaik, Spring has no support for own classloaders (but I might be
wrong), but I guess if we instantiate the new BeanFactory in an own
classloader everything should work from there as expected.
So, creating an own classloader, setting/restoring the thread context
classloader and creating the bean factory using this classloader should
be all.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: RAD with Cocoon 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
>
> Maven brings a lot of advantages to standardize the development
> process but also makes development of applications more difficult as
> you spread your applications over different artifacts.
>
> In the light of this I think we should revert our removal of the
> per-sitemap classloading
> (http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2).
> As the removal was part of a refactoring of the sitemap engine, could
> sombody give me a description of what needs to be done?
The main idea is to create a classloader with what is defined by
<map:classpath> in the sitemap, and use that classloader to create the
container for components in <map:components>
This is achieved by giving this classloader to the container (was
possible with ECM, don't know with Spring) and setting it as the
thread's default classloader before processing a request in the sitemap
(and restoring the old one at the end).
This allowed classes to be reloaded when the sitemap was reloaded.
Torsten later added a file monitor that tracks changes to the contents
of the classpath and triggers the sitemap reloading.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: RAD with Cocoon 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Torsten Curdt wrote:
>>> With 2.1.x you can develop your application directory from within your
>>> IDE, you don't have to invoke a build script, you don't have to copy
>>> files after you changed them etc.; And you don't have to use different
>>> configurations (like classpaths) for development. "It just works".
>
> Wait, wait, wait... what? 2.1.x? You change a class and the changes
> are reflected without restarting the servlet engine? ...sorry - but
> that sounds like a fairy tale ;-) Or I must have missed something -
> big time. (That's actually exactly what the classpath element
> provided)
>
Sure. Depends on your changes in the classs of course. But even just
restarting
Jetty from within Eclipse is going very fast and I don't have to specify
some classpath in a sitemap which I might have to remove for production
later on etc.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Re[2]: RAD with Cocoon 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> > With 2.1.x you can develop your application directory from within your
> > IDE, you don't have to invoke a build script, you don't have to copy
> > files after you changed them etc.; And you don't have to use different
> > configurations (like classpaths) for development. "It just works".
Wait, wait, wait... what? 2.1.x? You change a class and the changes
are reflected without restarting the servlet engine? ...sorry - but
that sounds like a fairy tale ;-) Or I must have missed something -
big time. (That's actually exactly what the classpath element
provided)
cheers
--
Torsten
Re: RAD with Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Jens Maukisch wrote:
> Hi,
>
>
>>With 2.1.x you can develop your application directory from within your
>>IDE, you don't have to invoke a build script, you don't have to copy
>>files after you changed them etc.; And you don't have to use different
>>configurations (like classpaths) for development. "It just works".
>>And I think this should be the way for 2.2 as well.
>
>
> Any idea how we can achieved this in 2.2?
>
<map:classpath> should do the trick.
--
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[2]: RAD with Cocoon 2.2
Posted by Jens Maukisch <co...@maukisch.net>.
Hi,
> With 2.1.x you can develop your application directory from within your
> IDE, you don't have to invoke a build script, you don't have to copy
> files after you changed them etc.; And you don't have to use different
> configurations (like classpaths) for development. "It just works".
> And I think this should be the way for 2.2 as well.
Any idea how we can achieved this in 2.2?
--
* best regards
* Jens Maukisch
Re: RAD with Cocoon 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Maven brings a lot of advantages to standardize the development process but also
> makes development of applications more difficult as you spread your applications
> over different artifacts.
>
> In the light of this I think we should revert our removal of the per-sitemap
> classloading
> (http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=114150323011155&w=2). As the
> removal was part of a refactoring of the sitemap engine, could sombody give me a
> description of what needs to be done?
>
I'm not against readding the per sitemap classloaders, but before this I
would suggest that we think about how development with 2.2 can be done.
With 2.1.x you can develop your application directory from within your
IDE, you don't have to invoke a build script, you don't have to copy
files after you changed them etc.; And you don't have to use different
configurations (like classpaths) for development. "It just works".
And I think this should be the way for 2.2 as well.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/