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/11/17 18:51:21 UTC
Changes to the deployer plugin wrt shielded classloading
Hi,
I extracted our support for shielded classloading and added a patch
to the maven war plugin, see http://jira.codehaus.org/browse/MWAR-84.
As soon as this patch is accepted by the maven community (and hopefully
they will), shielded class loading is not the concern of Cocoon anymore
and we can remove this stuff from our own plugin.
To prepare this, I committed the code I used for the war plugin to our
deployer plugin - so we are now using a simplified version if the
classloading which does not depend on the bootstrap stuff anymore.
This has the advantage of removing the bootstrap module and move the
stuff into core again. I think we should move the basic class loading
support into core while moving the reloading stuff into a separate
module to keep the core dependencies as minimal as possible.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Sub-sitemaps
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Alexander Klimetschek skrev:
> Joerg Heinicke schrieb:
>> Component inheritance is a standard functionality of Spring's
>> ApplicationContext implementations. So this should be no problem at all.
>
> Although this is not yet used in any way with the blocks. Two blocks,
> where one inherits from another, don't know that the other one uses a
> SitemapServlet, and the only interface between them is the servlet
> api. Components you define in your sitemap might be known to Spring
> but its about letting the TreeProcessor know how to resolve component
> names. So I don't think it is possible at all to integrate that into
> the blocks fw.
This is by design.
In earlier incarnations of the block architecture, the idea was to have
component inheritance (and polymorphism) as well as servlet inheritance
(or rather sitemap inheritance). We had some discussions about what this
would mean at the list, and the main conclusion is that it gets rather
complicated. You need to make sure that components always are executed
in the right context and classloader and this gets really messy when
combine with polymorphic block protocols that communicate over SAX events :/
And even if we had the energy and ability to solve these problems, I
that the concept of mixing component reuse and servlet reuse is flawed
and overly complicated anyway.
IMO, it is much better to consider component management and servlet
reuse as separate concerns as we do in the current architecture. The
blocks fw takes care about servlet reuse. For component reuse we have
Spring. Now the current mechanism for component reuse with Spring in
Cocoon is rather basic, we could get much further by using OSGi and the
OSGi-Spring bridge. But we should probably try to release 2.2, before
starting to work on that ;)
> BTW: What about those sitemap-additions directory?
Didn't we remove them?
/Daniel
Re: Sub-sitemaps
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Joerg Heinicke schrieb:
> Component inheritance is a standard functionality of Spring's
> ApplicationContext implementations. So this should be no problem at all.
Although this is not yet used in any way with the blocks. Two blocks,
where one inherits from another, don't know that the other one uses a
SitemapServlet, and the only interface between them is the servlet api.
Components you define in your sitemap might be known to Spring but its
about letting the TreeProcessor know how to resolve component names. So
I don't think it is possible at all to integrate that into the blocks fw.
BTW: What about those sitemap-additions directory?
> But I wonder if there is a replacement for "fallback to parent sitemap
> if no match was found in sub sitemap".
With the current blocks-fw implementation we put this matcher at the end
of all sitemaps that "inherit" from another block, ie. that have a
"super" block defined in the connections of the BlockServlet bean.
<match pattern="**">
<read src="block:super:/{1}" />
</match>
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Sub-sitemaps
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Joerg Heinicke schrieb:
> Component inheritance is a standard functionality of Spring's
> ApplicationContext implementations. So this should be no problem at all.
Although this is not yet used in any way with the blocks. Two blocks,
where one inherits from another, don't know that the other one uses a
SitemapServlet, and the only interface between them is the servlet api.
Components you define in your sitemap might be known to Spring but its
about letting the TreeProcessor know how to resolve component names. So
I don't think it is possible at all to integrate that into the blocks fw.
BTW: What about those sitemap-additions directory?
> But I wonder if there is a replacement for "fallback to parent sitemap
> if no match was found in sub sitemap".
With the current blocks-fw implementation we put this matcher at the end
of all sitemaps that "inherit" from another block, ie. that have a
"super" block defined in the connections of the BlockServlet bean.
<match pattern="**">
<read src="block:super:/{1}" />
</match>
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Sub-sitemaps (was: Changes to the deployer plugin wrt shielded classloading)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.11.2006 21:12, Mark Lundquist wrote:
>
> On Nov 18, 2006, at 5:46 AM, Carsten Ziegeler wrote:
>
>> So if you have two sitemaps in your block, one for /myblock and one for
>> /myblock/misc, then you add two component definitions to the spring
>> context and you don't have to mount the misc sub sitemap in the myblock
>> sitemap.
>
> One aspect of sub-sitemaps, of course, is that they inherit component
> definitions from upward in the hierarchy... does something like that
> still work in the new model?
Component inheritance is a standard functionality of Spring's
ApplicationContext implementations. So this should be no problem at all.
But I wonder if there is a replacement for "fallback to parent sitemap
if no match was found in sub sitemap".
Jörg
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Nov 18, 2006, at 5:46 AM, Carsten Ziegeler wrote:
> So if you have two sitemaps in your block, one for /myblock and one for
> /myblock/misc, then you add two component definitions to the spring
> context and you don't have to mount the misc sub sitemap in the myblock
> sitemap.
One aspect of sub-sitemaps, of course, is that they inherit component
definitions from upward in the hierarchy... does something like that
still work in the new model?
—ml—
> Removing the need of sub sitemaps would make our architecture and
> implementation *much* cleaner.
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Giacomo Pati wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> My goal is having a completly self-reloading Cocoon application that also
>>>> includes the block dispatching mechanism and not only at sitemap level. (As a
>>>> side note: We shouldn't consider sub-sitemaps as the number one way of
>>>> modularization in Cocoon anymore).
>>>>
>>> I think this side note is very important - and this remembers me about
>>> my pending proposal to remove sub sitemaps completly.
>>>
>> Hey guys, what does that mean? No more blocks?
>>
>>
> No, no, quiet the opposite. With the new block architecture and the
> dispatching stuff Daniel wrote, you can mount sitemaps in the spring
> context by just defining a sitemap servlet (I don't know the exact term,
> but I hope this gives an impression) which is configured with two
> values, the mount path and the sitemap location.
The dispatcher servlet looks for all Spring managed components that
implements the Servlet interface and has a mountPath property. The
dispatcher servlet will dispatch to the mounted servlet which mount path
is the longest prefix of the path info.
So we could have had a Spring managed sitemap servlet as with a sitemap
path and a mount path property as you describe above. Such a sitemap
servlet bean would need to have some extra code for getting the servlet
context right and geting the initialization order right.
Instead we have a special block servlet that embed an ordinary (non
managed) servlet as e.g. the sitemap servlet. It also provide some extra
functionality like the polymorphic block protocol.
> I'm not sure but I
> think we already have running examples somewhere in our tree.
>
Sure :)
Take a look at
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/META-INF/cocoon/spring/cocoon-forms-sample-blockServlet.xml,
for an example that make the forms samples available through the
dispatcher and block servlet. It should work OOTB in the
cocoon-dist-samples if you point you browser to
http://localhost:8888/blocks-test/cocoon-forms-samples/.
Some more of the features, like connecting to other blocks servlets with
DI is demonstrated in the blocks fw samples:
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/resources/META-INF/cocoon/spring/.
In the cocoon-blocks-fw-demo[1|2] there are examples using the block
servlet with other servlets than the sitemap servlet.
> By this, you mount new functionality just by adding your components to
> the spring context and that's it. These components (or servlets) are
> called "directly" from the dispatching servlet without going through the
> main sitemap.
> So if you have two sitemaps in your block, one for /myblock and one for
> /myblock/misc, then you add two component definitions to the spring
> context and you don't have to mount the misc sub sitemap in the myblock
> sitemap.
>
Exactly.
> Removing the need of sub sitemaps would make our architecture and
> implementation *much* cleaner.
>
Agree.
But isn't the main problem component configurations in sub sitemaps?
Wouldn't it be enough (from architectural cleanliness POV) to remove the
ability to define components in sub sitemaps?
/Daniel
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
>
>
> Carsten Ziegeler wrote:
>> Reinhard Poetz wrote:
>>> My goal is having a completly self-reloading Cocoon application that also
>>> includes the block dispatching mechanism and not only at sitemap level. (As a
>>> side note: We shouldn't consider sub-sitemaps as the number one way of
>>> modularization in Cocoon anymore).
>> I think this side note is very important - and this remembers me about
>> my pending proposal to remove sub sitemaps completly.
>
> Hey guys, what does that mean? No more blocks?
>
No, no, quiet the opposite. With the new block architecture and the
dispatching stuff Daniel wrote, you can mount sitemaps in the spring
context by just defining a sitemap servlet (I don't know the exact term,
but I hope this gives an impression) which is configured with two
values, the mount path and the sitemap location. I'm not sure but I
think we already have running examples somewhere in our tree.
By this, you mount new functionality just by adding your components to
the spring context and that's it. These components (or servlets) are
called "directly" from the dispatching servlet without going through the
main sitemap.
So if you have two sitemaps in your block, one for /myblock and one for
/myblock/misc, then you add two component definitions to the spring
context and you don't have to mount the misc sub sitemap in the myblock
sitemap.
Removing the need of sub sitemaps would make our architecture and
implementation *much* cleaner.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> My goal is having a completly self-reloading Cocoon application that also
>> includes the block dispatching mechanism and not only at sitemap level. (As a
>> side note: We shouldn't consider sub-sitemaps as the number one way of
>> modularization in Cocoon anymore).
> I think this side note is very important - and this remembers me about
> my pending proposal to remove sub sitemaps completly.
Hey guys, what does that mean? No more blocks?
Ciao
- --
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.5 (GNU/Linux)
iD8DBQFFXhOoLNdJvZjjVZARAgAUAJ45uYlyX3V7Hf53Ev2sMHl1pwiCfQCfbm9i
lyDDj6mc+6ykyp+BcjMHkpw=
=oDcn
-----END PGP SIGNATURE-----
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> One, to some extend, related question: Is it possible to have the
>> ReloadingClassloader in front of the ShieldingClassloader? Of course only at
>> development time.
> Hmm, yes that should work.
>
>> My goal is having a completly self-reloading Cocoon application that also
>> includes the block dispatching mechanism and not only at sitemap level. (As a
>> side note: We shouldn't consider sub-sitemaps as the number one way of
>> modularization in Cocoon anymore).
> I think this side note is very important - and this remembers me about
> my pending proposal to remove sub sitemaps completly.
I'm waiting eagerly for it :-)
>> How could this be implemented? I think a servlet filter that sets the context
>> classloader of the current thread to the reloading classloader that delegates to
>> the shielding classloader should do the trick.
> Yes, that should work.
>
>> Additionally it must be able to
>> reload the app context if any .class file has changed.
>> The reloading classloader should be configureable so that it can put the
>> target/classes directories of other blocks onto the classpath. There should also
>> be some way to auto-generate this script.
>>
>> For COB-INF resources we could create a Spring configuration file that points to
>> the src/main/resources/COB-INF directories of blocks, again based on the
>> configuration file mentioned before.
>>
>> WDYT?
> In general this should work.
ok (wanted to make sure that I'm on the right track)
> I think we should all vote for the maven
> war plugin patch,
done
> to get the shielded stuff into the war plugin and continue from there.
In the meantime I want get familiar with the ReloadingClassloader.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> One, to some extend, related question: Is it possible to have the
> ReloadingClassloader in front of the ShieldingClassloader? Of course only at
> development time.
Hmm, yes that should work.
>
> My goal is having a completly self-reloading Cocoon application that also
> includes the block dispatching mechanism and not only at sitemap level. (As a
> side note: We shouldn't consider sub-sitemaps as the number one way of
> modularization in Cocoon anymore).
I think this side note is very important - and this remembers me about
my pending proposal to remove sub sitemaps completly.
>
> How could this be implemented? I think a servlet filter that sets the context
> classloader of the current thread to the reloading classloader that delegates to
> the shielding classloader should do the trick.
Yes, that should work.
> Additionally it must be able to
> reload the app context if any .class file has changed.
> The reloading classloader should be configureable so that it can put the
> target/classes directories of other blocks onto the classpath. There should also
> be some way to auto-generate this script.
>
> For COB-INF resources we could create a Spring configuration file that points to
> the src/main/resources/COB-INF directories of blocks, again based on the
> configuration file mentioned before.
>
> WDYT?
In general this should work. I think we should all vote for the maven
war plugin patch,
to get the shielded stuff into the war plugin and continue from there.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> I extracted our support for shielded classloading and added a patch
> to the maven war plugin, see http://jira.codehaus.org/browse/MWAR-84.
> As soon as this patch is accepted by the maven community (and hopefully
> they will), shielded class loading is not the concern of Cocoon anymore
> and we can remove this stuff from our own plugin.
>
> To prepare this, I committed the code I used for the war plugin to our
> deployer plugin - so we are now using a simplified version if the
> classloading which does not depend on the bootstrap stuff anymore.
>
> This has the advantage of removing the bootstrap module and move the
> stuff into core again. I think we should move the basic class loading
> support into core while moving the reloading stuff into a separate
> module to keep the core dependencies as minimal as possible.
great!
One, to some extend, related question: Is it possible to have the
ReloadingClassloader in front of the ShieldingClassloader? Of course only at
development time.
My goal is having a completly self-reloading Cocoon application that also
includes the block dispatching mechanism and not only at sitemap level. (As a
side note: We shouldn't consider sub-sitemaps as the number one way of
modularization in Cocoon anymore).
How could this be implemented? I think a servlet filter that sets the context
classloader of the current thread to the reloading classloader that delegates to
the shielding classloader should do the trick. Additionally it must be able to
reload the app context if any .class file has changed.
The reloading classloader should be configureable so that it can put the
target/classes directories of other blocks onto the classpath. There should also
be some way to auto-generate this script.
For COB-INF resources we could create a Spring configuration file that points to
the src/main/resources/COB-INF directories of blocks, again based on the
configuration file mentioned before.
WDYT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote:
> I have added a patch for adding shielded classloading for single blocks
> (http://issues.apache.org/jira/browse/COCOON-1955). This allows you to
> shield certain blocks from other blocks inside your Cocoon application,
> which is necessary when there are conflicting versions of Java libs that
> cannot be resolved without patching external code.
>
> For that I modified the BootstrapClassLoaderManager slightly (and stuff
> from the blocks-fw). The configuration for a shielded block also uses
> the ShieldingServlet. Does this conflict with the upcoming move of the
> shielding stuff into the maven-war-plugin?
>
Sorry, I did not see your patch before I did the changes :(
Indeed, your patch does not work anymore as most of the stuff, like
the ShieldingServerlt or the BootstrapClassLoaderManager are not part of
Cocoon anymore.
In fact your touching the nerv of one of the key features of the real
blocks concept: shielded class loading between blocks. This is something
which we hoped to get with OSGi...we have a simpler solution right now,
which is the per sitemap class loader. Of course the per sitemap class
loader is only used for per sitemap components/beans which might not be
what you're looking for.
Perhaps we should discuss in a new thread what is needed and what we can
do about it?
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes to the deployer plugin wrt shielded classloading
Posted by Alexander Klimetschek <al...@mindquarry.com>.
I have added a patch for adding shielded classloading for single blocks
(http://issues.apache.org/jira/browse/COCOON-1955). This allows you to
shield certain blocks from other blocks inside your Cocoon application,
which is necessary when there are conflicting versions of Java libs that
cannot be resolved without patching external code.
For that I modified the BootstrapClassLoaderManager slightly (and stuff
from the blocks-fw). The configuration for a shielded block also uses
the ShieldingServlet. Does this conflict with the upcoming move of the
shielding stuff into the maven-war-plugin?
Alex
Carsten Ziegeler schrieb:
> Hi,
>
> I extracted our support for shielded classloading and added a patch
> to the maven war plugin, see http://jira.codehaus.org/browse/MWAR-84.
> As soon as this patch is accepted by the maven community (and hopefully
> they will), shielded class loading is not the concern of Cocoon anymore
> and we can remove this stuff from our own plugin.
>
> To prepare this, I committed the code I used for the war plugin to our
> deployer plugin - so we are now using a simplified version if the
> classloading which does not depend on the bootstrap stuff anymore.
>
> This has the advantage of removing the bootstrap module and move the
> stuff into core again. I think we should move the basic class loading
> support into core while moving the reloading stuff into a separate
> module to keep the core dependencies as minimal as possible.
>
> Carsten
--
Alexander Klimetschek
http://www.mindquarry.com