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
