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
