Why not? How expensive is it to reload all the implementations?
On Wed, Aug 11, 2010 at 11:04 PM, Howard Lewis Ship <hls...@gmail.com>wrote:
> Isolation. If one service impl changes, I don't want to have to throw
> away all the other service implementations that didn't.
>
> On Wed, Aug 11, 2010 at 2:01 PM, Igor Drobiazko
> <igor.drobia...@gmail.com> wrote:
> > 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
> >
>
>
>
> --
> 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
