Re: RAD with Cocoon 2.2
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: RAD with Cocoon 2.2
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?
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: RAD with Cocoon 2.2
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
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 <[EMAIL PROTECTED]>
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
would lead to a major feature loss. Daniel, I understand your
concerns (see above) but without the 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
-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 <[EMAIL PROTECTED]> 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
-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 <[EMAIL PROTECTED]> 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
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
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
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
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
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
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 > in the sitemap, and use that classloader to create the > container for components in > > 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
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/
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. 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
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 in the sitemap, and use that classloader to create the container for components in 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
