Re: ReloadingClassloader events

[Torsten Curdt <tc...@apache.org>]

> Sounds like an Observer pattern is needed so that whichever code needs
> the info can subscribe to "class XY was reloaded" events.

Exactly ...but one thing I am still thinking of:
How do I get hold of that instance of the classloader
so I can you can subscribe to the events?

One idea...

  class ReloadingHelper {
    public void static addListener(ReloadingListener object) {
      ClassLoader cl = object.getClass().getClassLoader();
      if (cl instanceof ReloadingClassLoader) {
        ((ReloadingClassLoader)cl).addListener(object);
      }
    }
  }

So after every object creation (that need to
be aware of reloading) you would need to do:

   MyObject a = new MyObject();
   ReloadingHelper.addListener(a);

As for having a classloader per sitemap ...I am not
quite sure if this is feasible. I mean: usually you
don't want to have a class repository (aka eclipse
project) per sitemap!

Let's say class org.apache.Bla is being changed
...how do we know what sitemap is using it? We
would also need to somehow use the observer pattern
for that. ...I am not sure if this really simplifies
things.

Although... maybe we need this for the kernel
anyway. (Pier?)

cheers
--
Torsten

Re: ReloadingClassloader events

[Torsten Curdt <tc...@apache.org>]

> Looks too complicated, and probably will be way too slow or way too
> memory hungry in the end.

Hm... maybe true

> I'm with Stefano: keep it simple, reload everything. If sitemap has own
> class repository you don't have to think twice what to reload on class
> change: whole sitemap whose class is updated and all its subsitemaps.

...but do you guys really think a repository per sitemap is really
feasible?

cheers
--
Torsten

Re: ReloadingClassloader events

[Vadim Gritsenko <va...@reverycodes.com>]

Torsten Curdt wrote:
>> Sounds like an Observer pattern is needed so that whichever code needs
>> the info can subscribe to "class XY was reloaded" events.
> 
> 
> Exactly ...but one thing I am still thinking of:
> How do I get hold of that instance of the classloader
> so I can you can subscribe to the events?
> 
> One idea...
> 
>  class ReloadingHelper {
>    public void static addListener(ReloadingListener object) {
>      ClassLoader cl = object.getClass().getClassLoader();
>      if (cl instanceof ReloadingClassLoader) {
>        ((ReloadingClassLoader)cl).addListener(object);
>      }
>    }
>  }
> 
> So after every object creation (that need to
> be aware of reloading) you would need to do:
> 
>   MyObject a = new MyObject();
>   ReloadingHelper.addListener(a);

Looks too complicated, and probably will be way too slow or way too memory 
hungry in the end.

I'm with Stefano: keep it simple, reload everything. If sitemap has own class 
repository you don't have to think twice what to reload on class change: whole 
sitemap whose class is updated and all its subsitemaps.

Vadim

Re: ReloadingClassloader events

[Bertrand Delacretaz <bd...@apache.org>]

Le 21 févr. 05, à 21:56, Torsten Curdt a écrit :

> ...How do I get hold of that instance of the classloader
> so I can you can subscribe to the events?...

> ...     if (cl instanceof ReloadingClassLoader) {
>        ((ReloadingClassLoader)cl).addListener(object);...

Sounds right, the reloading is dependent on a given ClassLoader anyway, 
so it seems to make sense for the ClassLoader to be the (maybe 
indirect) source of events.

Also, I think the event must include the Class object that is being 
reloaded, or at least its fully qualified name, so that subscribers can 
filter out events if needed.

I don't know if cascading events are needed - does a ClassLoader need 
to listen to events from its parent ClassLoader and fire them to its 
listeners as well? I'd tend to say yes but don't have a specific use 
case to back this up ATM (it's only 7:20 AM here though ;-)

-Bertrand