Is service construction really so expensive? After all, we're doing exactly
that for page/component reloading (throw away all loaded pages/components if a
change to any of them occur), and I suspect that pages and components are
considerably more expensive to construct than services? Given that service
reloading will primarily be occurring in development environments, this seems
like it may be a premature optimization. Or is there some reason other than
performance that you don't want to have to throw away the other services?
Robert
On Aug 11, 2010, at 8/114:04 PM , Howard Lewis Ship 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
