You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Christofer.Dutz@univativ.de" <ch...@univativ.de> on 2007/03/21 09:17:03 UTC
ReloadingClassLoader
Hi
I am currently developing a cocoon application using java-flow. One of
the really annoying things is, that I have to reload the entire context
when changing the class file containing the flow. While having a look at
the available class loaders I couldn't find any one that could do
"reloading" of classes. So I started developing one. While googling for
a small problem I stumbled over the code for a complete
ReloadingClassLoader which has one additional goodie ... not only an
addUrl-like method but also an removeUrl one.
Here the link to the Code:
http://gate.ac.uk/gate/doc/java2html/gate/util/ReloadingClassLoader.java
.html
Maybe it would be good to somehow integrate something like this? I will
definitely use it in my applications. Just thought it would be good in
general ;)
Regards,
Christofer
Re: ReloadingClassLoader
Posted by Torsten Curdt <tc...@apache.org>.
On 22.03.2007, at 11:03, Reinhard Poetz wrote:
> Torsten Curdt wrote:
>>>>> And what configuration is necessary for production so that
>>>>> classes are "only" instrumented?
>>>> For javaflow all you need is to use this store. For both -
>>>> compiling or reloading. Of course it would be good to configure
>>>> the packages that should be instrumented. I can add that to that
>>>> store directly if you want.
>>>> http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/
>>>> apache/commons/javaflow/stores/JavaflowResourceStore.html
>>>
>>>
>>> sorry, I'm a confused. What do you mean by "this" and "that"
>>> store. The current implementation is
>>>
>>> org.apache.commons.jci.listeners.ReloadingListener rl =
>>> new CocoonReloadingListener();
>>> rl.addReloadNotificationListener(classloader);
>>> fam.addListener(directory, rl);
>>>
>>> and if I look into CocoonReloadingListener() which extends
>>> org.apache.commons.jci.listeners.ReloadingListener I find that it
>>> creates stores of type MemoryResourceStore.
>>>
>>> Am I right that, in order to support instrumentation for
>>> Javaflow, I have to override the default behaviour and create
>>> stores of type JavaflowResourceStore instead?
>> Correct! ...or we always use a javaflow store and work that out
>> via configuration.
>
> I think that I understand the scope of the problem now.
>
> For now I will concentrate on the release of cocoon-rcl-plugin
> without Javaflow support. It can be added at any time later. I
> won't have much available time over the next weeks (and no use case
> that would justify to change my priorities) but if somebody else
> wants to integrate it into cocoon-rcl, I'm available for dicussing
> it on this list.
The only question is where and how to configure what is meant to be
instrumented.
...well and how people envision this to happen for non-dev mode.
The original implementation just defined the store class to use per
directory that is getting monitored. See
http://cocoongt.hippo12.castaserver.com/cocoongt/torsten-curdt-rapid-
app-development.pdf
cheers
--
Torsten
Re: ReloadingClassLoader
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>>>> And what configuration is necessary for production so that classes
>>>> are "only" instrumented?
>>> For javaflow all you need is to use this store. For both - compiling
>>> or reloading. Of course it would be good to configure the packages
>>> that should be instrumented. I can add that to that store directly if
>>> you want.
>>> http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/apache/commons/javaflow/stores/JavaflowResourceStore.html
>>>
>>
>>
>> sorry, I'm a confused. What do you mean by "this" and "that" store.
>> The current implementation is
>>
>> org.apache.commons.jci.listeners.ReloadingListener rl =
>> new CocoonReloadingListener();
>> rl.addReloadNotificationListener(classloader);
>> fam.addListener(directory, rl);
>>
>> and if I look into CocoonReloadingListener() which extends
>> org.apache.commons.jci.listeners.ReloadingListener I find that it
>> creates stores of type MemoryResourceStore.
>>
>> Am I right that, in order to support instrumentation for Javaflow, I
>> have to override the default behaviour and create stores of type
>> JavaflowResourceStore instead?
>
> Correct! ...or we always use a javaflow store and work that out via
> configuration.
I think that I understand the scope of the problem now.
For now I will concentrate on the release of cocoon-rcl-plugin without Javaflow
support. It can be added at any time later. I won't have much available time
over the next weeks (and no use case that would justify to change my priorities)
but if somebody else wants to integrate it into cocoon-rcl, I'm available for
dicussing it on this list.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: ReloadingClassLoader
Posted by Torsten Curdt <tc...@apache.org>.
>>> And what configuration is necessary for production so that
>>> classes are "only" instrumented?
>> For javaflow all you need is to use this store. For both -
>> compiling or reloading. Of course it would be good to configure
>> the packages that should be instrumented. I can add that to that
>> store directly if you want.
>> http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/
>> apache/commons/javaflow/stores/JavaflowResourceStore.html
>
>
> sorry, I'm a confused. What do you mean by "this" and "that" store.
> The current implementation is
>
> org.apache.commons.jci.listeners.ReloadingListener rl =
> new CocoonReloadingListener();
> rl.addReloadNotificationListener(classloader);
> fam.addListener(directory, rl);
>
> and if I look into CocoonReloadingListener() which extends
> org.apache.commons.jci.listeners.ReloadingListener I find that it
> creates stores of type MemoryResourceStore.
>
> Am I right that, in order to support instrumentation for Javaflow,
> I have to override the default behaviour and create stores of type
> JavaflowResourceStore instead?
Correct! ...or we always use a javaflow store and work that out via
configuration.
> This brings me to my other question: The cocoon-rcl-plugin is only
> useful at development time. What options to instrument Javaflow
> classes for production use do we have?
There is an ant task for it in javaflow atm, the maven-jci-compiler
plugin will support that (but that's still a way to go) and we could
write a quick and easy maven plugin for that. These are all options I
see.
..or just use a FileResourceStore or serialize the
MemoryResourceStore ;)
cheers
--
Torsten
Re: ReloadingClassLoader
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>
> On 21.03.2007, at 20:58, Reinhard Poetz wrote:
>
>> Torsten Curdt wrote:
>>>> I am currently developing a cocoon application using java-flow. One
>>>> of the really annoying things is, that I have to reload the entire
>>>> context when changing the class file containing the flow.
>>> You are aware of the reloading classloader plugin for cocoon? :) It
>>> is using JCI to do the reloading
>>
>> see http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html
>>
>>> ...and can auto-instrument the javaflow classes.
>>
>> @Thorsten: What needs to be done that Javaflow classes get reloaded
>> using the RCL plugin AND are being instrumented?
>
> "Torsten"!! ;)
sorry :-)
though I know what you mean (Rainhard, Reinhardt, ...)
>> And what configuration is necessary for production so that classes are
>> "only" instrumented?
>
> For javaflow all you need is to use this store. For both - compiling or
> reloading. Of course it would be good to configure the packages that
> should be instrumented. I can add that to that store directly if you want.
>
> http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/apache/commons/javaflow/stores/JavaflowResourceStore.html
sorry, I'm a confused. What do you mean by "this" and "that" store. The current
implementation is
org.apache.commons.jci.listeners.ReloadingListener rl =
new CocoonReloadingListener();
rl.addReloadNotificationListener(classloader);
fam.addListener(directory, rl);
and if I look into CocoonReloadingListener() which extends
org.apache.commons.jci.listeners.ReloadingListener I find that it creates stores
of type MemoryResourceStore.
Am I right that, in order to support instrumentation for Javaflow, I have to
override the default behaviour and create stores of type JavaflowResourceStore
instead?
This brings me to my other question: The cocoon-rcl-plugin is only useful at
development time. What options to instrument Javaflow classes for production use
do we have?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: ReloadingClassLoader
Posted by Torsten Curdt <tc...@apache.org>.
On 21.03.2007, at 20:58, Reinhard Poetz wrote:
> Torsten Curdt wrote:
>>> I am currently developing a cocoon application using java-flow.
>>> One of the really annoying things is, that I have to reload the
>>> entire context when changing the class file containing the flow.
>> You are aware of the reloading classloader plugin for cocoon? :)
>> It is using JCI to do the reloading
>
> see http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html
>
>> ...and can auto-instrument the javaflow classes.
>
> @Thorsten: What needs to be done that Javaflow classes get reloaded
> using the RCL plugin AND are being instrumented?
"Torsten"!! ;)
> And what configuration is necessary for production so that classes
> are "only" instrumented?
For javaflow all you need is to use this store. For both - compiling
or reloading. Of course it would be good to configure the packages
that should be instrumented. I can add that to that store directly if
you want.
http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/
apache/commons/javaflow/stores/JavaflowResourceStore.html
Could be there was such a store already in Cocoon though. Need to check.
cheers
--
Torsten
Re: ReloadingClassLoader
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>> I am currently developing a cocoon application using java-flow. One of
>> the really annoying things is, that I have to reload the entire
>> context when changing the class file containing the flow.
> You are aware of the reloading classloader plugin for cocoon? :) It is
> using JCI to do the reloading
see http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html
> ...and can auto-instrument the javaflow classes.
@Thorsten: What needs to be done that Javaflow classes get reloaded using the
RCL plugin AND are being instrumented?
And what configuration is necessary for production so that classes are "only"
instrumented?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: ReloadingClassLoader
Posted by Torsten Curdt <tc...@apache.org>.
> I am currently developing a cocoon application using java-flow. One
> of the really annoying things is, that I have to reload the entire
> context when changing the class file containing the flow.
You are aware of the reloading classloader plugin for cocoon? :) It
is using JCI to do the reloading
...and can auto-instrument the javaflow classes.
> While having a look at the available class loaders I couldn’t find
> any one that could do „reloading“ of classes.
http://jakarta.apache.org/commons/sandbox/jci/xref/org/apache/commons/
jci/ReloadingClassLoader.html
cheers
--
Torsten