Why actually creating a class loader per service? Why not creating a single
class loader which is used to load all classes? This service can be thrown
away if one of the classes has been changed. This would solve the problem of
class and package identity.
On Wed, Aug 11, 2010 at 10:20 PM, Howard Lewis Ship <hls...@gmail.com>wrote:
> Perhaps there's a way we can analyze the service and determine that it
> is not compatible with live service implementation reloading.
> However, part of this should be addressed by an existing bug, which
> indicates that Tapestry should automatically load the base class of a
> service implementation class in the same class loader.
>
> On Wed, Aug 11, 2010 at 1:07 PM, Kalle Korhonen
> <kalle.o.korho...@gmail.com> wrote:
> > On Wed, Aug 11, 2010 at 12:32 PM, Thiago H. de Paula Figueiredo
> > <thiag...@gmail.com> wrote:
> >> In which package the proxy is created? If it's just a matter or putting
> them
> >> in the same package, just name the proxy ${className}___TapestryIoCProxy
> or
> >> something like that. Is this possible?
> >
> > Do read what Howard's saying. Classes in Java are only uniquely
> > identified by the fully qualified class name and the loading
> > classloader. I wonder if providing a global flag for controlling the
> > service reloading and .enableReloading() would make matters worse?
> > Probably, more configuration typically causes only more mess. What
> > about disabling service reloading automatically if there's even one
> > protected/package-private operation and logging a warning?
> >
> > I doubt that common abstract classes for services are that typical.
> > I'd personally live with the restrictions live service reloading
> > imposes but I can see how it might make many others unhappy. Had this
> > been in place from the beginning, I doubt it would have caused much of
> > a fuzz, but now it just might. Damned if you do, damned if you
> > don't...
> >
> > Kalle
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: dev-h...@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
