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
