You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Igor Drobiazko <ig...@gmail.com> on 2010/08/11 20:58:25 UTC
Re: Another IllegalAccessError in 5.2 alpha [bug?]
I'm concerned about the solution you propose. The most apps based on 5.1
will be broken after the upgrade. It's very common to have common abstract
super classes for services. Tapestry has been know for adapting the code of
app developers. With the proposed solution Tapestry would dictate app
developers how they code should look like: namely no package private or
protected methods in any of the classes inside reloadable packages. This is
a huge regression that will annoy too many developers. I believe we need a
solution for this issue.
On Wed, Aug 11, 2010 at 6:54 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> You can see these kinds of exceptions for a service implementation
> that accesses protected or package private members of another class.
> Because the service implementation class is loaded in a new
> ClassLoader (to support live class reloading), it is considered to be
> in a different Java package from the other classes (even though this
> new package has the exact same name). When the specially loaded code
> accesses those private members, this is recognized by the JVM which
> throws the exception you are seeing.
>
> You should either make those other members (including constructors)
> public OR mark the service in question as not live-reloadable. This
> can be accomplished as:
>
> public static void bind(ServiceBinder binder)
> {
> binder.bind(MyInterface.class, MyImplementation.class).preventReloading();
> }
>
> On Wed, Aug 11, 2010 at 12:42 AM, Vjeran Marcinko
> <vj...@email.t-com.hr> wrote:
> > Hello,
> >
> > I tried to port my 5.1 app to 5.2 alpha, and also got IllegalAccessError.
> >
> > I have my own ComponentRequestFilter implementation (for Hibernate
> session
> > management) registered naturally in Tapestry's module class (service
> > package), and IllegalAccessError is raised when this filter tries to
> access
> > other helper class from same package.
> >
> > My filter and mentioned helper classes is located in my arbitrary package
> > <tapestry-.root-package>/my/arbitrary/package
> >
> > I thought maybe some packaging policy has been changed since 5.1 to 5.2,
> so
> > I tried to move all classes (filter and helpers) to "service" package
> since
> > that's where Tapestry's module class is located and references filter,
> but
> > to no avail. Same error occurs.
> >
> > I guess this is bug then, since I can see Peter has mentioned similar
> error.
> >
> > Regards,
> > Vjeran
> >
> > ----- Original Message ----- From: <P....@albourne.com>
> > Newsgroups: gmane.comp.java.tapestry.user
> > To: "Tapestry users" <us...@tapestry.apache.org>
> > Sent: Tuesday, August 10, 2010 1:49 PM
> > Subject: Re: Tapestry 5.2.0 Alpha Release Now Available
> >
> >
> >> I guess you're autobuilding a service (AlertFilterCacheRepositoryImpl)
> >> with a constructor that receives two Strings. Am I right?
> >
> > Not quite, there is no explicit auto-loading, I simply build my IoC
> registry
> > adding a bunch of modules to it in the process... the constructor for
> that
> > service looks like this:
> >
> > public AlertFilterCacheRepositoryImpl(@HfdbDatabase HfdbSession session)
> {
> > session_ = session;
> > cache_ = new
> > LookupCacheWrapper<AlertFilterDigest,Integer>(AlertFilterDigest.class);
> > }
> >
> >
> > The annotation is a marker, followed by an interface and all this does is
> > simply determine the database to reference, the cache object is
> constructed
> > and also populated, its all pretty innocuous so I don't see how it
> relates
> > to the IllegalAccessError?
> >
> > Peter
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Thiago H. de Paula Figueiredo" <th...@gmail.com>
> > To: "Tapestry users" <us...@tapestry.apache.org>
> > Sent: Tuesday, 10 August, 2010 13:58:58 GMT +02:00 Athens, Beirut,
> > Bucharest, Istanbul
> > Subject: Re: Tapestry 5.2.0 Alpha Release Now Available
> >
> > On Tue, 10 Aug 2010 05:30:32 -0300, <P....@albourne.com> wrote:
> >
> >> Hi Guys,
> >
> > Hi!
> >
> >> I just tried the upgrade from 5.1, but having no luck getting it
> >> running, I am getting this exception:
> >
> >> Caused by: java.lang.IllegalAccessError: tried to access method
> >>
> >>
> com.albourne.db.alert.cache.AlertFilterDigest.<init>(IILjava/lang/String;Ljava/lang/String;)V
> >> > from class com.albourne.db.alert.cache.AlertFilterCacheRepositoryImpl
> >
> > I guess you're autobuilding a service (AlertFilterCacheRepositoryImpl)
> > with a constructor that receives two Strings. Am I right?
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> > and instructor
> > Owner, Ars Machina Tecnologia da Informação Ltda.
> > http://www.arsmachina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
Agreed. A global flag defaulted to false is a good compromise which ensures
backward compatibility.
On Mon, Aug 16, 2010 at 7:40 PM, Kalle Korhonen
<ka...@gmail.com>wrote:
> I suggested the global flag and enableReloading() in my first post on
> this thread, but also noted that it might cause even more confusion as
> more configuration options typically do. Let's remember that this is a
> development-time feature only so the outcry regarding backwards
> compatibility is somewhat unwarranted. A global service reloading flag
> that by default is false would probably be a good enough compromise -
> if you want the feature you need to deal with the requirements it
> imposes.
>
> Kalle
>
>
> On Mon, Aug 16, 2010 at 10:27 AM, Robert Zeigler <ro...@scazdl.org>
> wrote:
> > I love live service implementation reloading, and I would hate to have to
> explicitly enable it for every service I create. I'm in favor of the "global
> on/off switch" as proposed by, eg, Michal Gruca. I'm not sure if it would
> be feasible to have a global "off" and then an enableReloading() call for
> specific services, but, at the very least, having it be "off"="everything
> off", and "on" = retain current behavior (on except for services with
> preventReloading()) should be imminently doable. It may even be best to turn
> off live service reloading by default (in tapestry's
> contributeFactoryDefaults) so that you have the same behavior as before
> T5.2, and then you can turn on the reloading at your leisure. That way,
> upgrade = painless, but it's still easy to globally turn on the feature (for
> people like me who love it and don't have any access issues :).
> >
> > Robert
> >
> > On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
> >
> >> On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> wrote:
> >>
> >>> So, what is the consensus on fixing the issue?
> >>
> >> +1 for live reloading of a given service live needing an explicit action
> from the Tapestry user (i.e. enableReloading()).
> >>
> >> As it is now, Tapestry-IoC is breaking backward compatibility in a
> serious way.
> >>
> >> --
> >> Thiago H. de Paula Figueiredo
> >> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> >> Owner, Ars Machina Tecnologia da Informação Ltda.
> >> http://www.arsmachina.com.br
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Kalle Korhonen <ka...@gmail.com>.
I suggested the global flag and enableReloading() in my first post on
this thread, but also noted that it might cause even more confusion as
more configuration options typically do. Let's remember that this is a
development-time feature only so the outcry regarding backwards
compatibility is somewhat unwarranted. A global service reloading flag
that by default is false would probably be a good enough compromise -
if you want the feature you need to deal with the requirements it
imposes.
Kalle
On Mon, Aug 16, 2010 at 10:27 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> I love live service implementation reloading, and I would hate to have to explicitly enable it for every service I create. I'm in favor of the "global on/off switch" as proposed by, eg, Michal Gruca. I'm not sure if it would be feasible to have a global "off" and then an enableReloading() call for specific services, but, at the very least, having it be "off"="everything off", and "on" = retain current behavior (on except for services with preventReloading()) should be imminently doable. It may even be best to turn off live service reloading by default (in tapestry's contributeFactoryDefaults) so that you have the same behavior as before T5.2, and then you can turn on the reloading at your leisure. That way, upgrade = painless, but it's still easy to globally turn on the feature (for people like me who love it and don't have any access issues :).
>
> Robert
>
> On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
>
>> On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <ig...@gmail.com> wrote:
>>
>>> So, what is the consensus on fixing the issue?
>>
>> +1 for live reloading of a given service live needing an explicit action from the Tapestry user (i.e. enableReloading()).
>>
>> As it is now, Tapestry-IoC is breaking backward compatibility in a serious way.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 17 Aug 2010 03:40:01 -0300, Igor Drobiazko
<ig...@gmail.com> wrote:
> Sorry, the last message was confusing. Forget the statement about
> FactoryDefault's and ApplicationDefaults.
>
> But there is a challenge. Right now the decision whether a service is
> reloadable or not is made during binding. At bind time you don't have
> access to symbols.
That's what I was thinking when I suggested that every service should not
be reloadable unless explicitly configured. This could be combined with
the system property, which would provide a default value. I can't think of
a better solution.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Howard Lewis Ship <hl...@gmail.com>.
We'll see ... I may still be able to "make it work" by doing a more
complex analysis of the class in relationship to other classes
(including parent classes) and loading all of those in the same class
loader.
On Tue, Aug 17, 2010 at 7:44 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> You're right; it would have to be a system property.
>
> Robert
>
> On Aug 17, 2010, at 8/171:40 AM , Igor Drobiazko wrote:
>
>> Sorry, the last message was confusing. Forget the statement about
>> FactoryDefault's and ApplicationDefaults.
>>
>> But there is a challenge. Right now the decision whether a service is
>> reloadable or not is made during binding. At bind time you don't have access
>> to symbols.
>>
>> On Tue, Aug 17, 2010 at 8:22 AM, Igor Drobiazko <ig...@gmail.com>wrote:
>>
>>> I would prefer a system property, not a symbol. The "global switch on/off"
>>> is only for development and you will never override the FactoryDefault's
>>> value in ApplicationDefaults.
>>>
>>>
>>> On Mon, Aug 16, 2010 at 7:27 PM, Robert Zeigler <ro...@scazdl.org>wrote:
>>>
>>>> I love live service implementation reloading, and I would hate to have to
>>>> explicitly enable it for every service I create. I'm in favor of the "global
>>>> on/off switch" as proposed by, eg, Michal Gruca. I'm not sure if it would
>>>> be feasible to have a global "off" and then an enableReloading() call for
>>>> specific services, but, at the very least, having it be "off"="everything
>>>> off", and "on" = retain current behavior (on except for services with
>>>> preventReloading()) should be imminently doable. It may even be best to turn
>>>> off live service reloading by default (in tapestry's
>>>> contributeFactoryDefaults) so that you have the same behavior as before
>>>> T5.2, and then you can turn on the reloading at your leisure. That way,
>>>> upgrade = painless, but it's still easy to globally turn on the feature (for
>>>> people like me who love it and don't have any access issues :).
>>>>
>>>> Robert
>>>>
>>>> On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
>>>>
>>>>> On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <
>>>> igor.drobiazko@gmail.com> wrote:
>>>>>
>>>>>> So, what is the consensus on fixing the issue?
>>>>>
>>>>> +1 for live reloading of a given service live needing an explicit action
>>>> from the Tapestry user (i.e. enableReloading()).
>>>>>
>>>>> As it is now, Tapestry-IoC is breaking backward compatibility in a
>>>> serious way.
>>>>>
>>>>> --
>>>>> Thiago H. de Paula Figueiredo
>>>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>>>> and instructor
>>>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>>>> http://www.arsmachina.com.br
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> Igor Drobiazko
>>> http://tapestry5.de
>>>
>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Robert Zeigler <ro...@scazdl.org>.
You're right; it would have to be a system property.
Robert
On Aug 17, 2010, at 8/171:40 AM , Igor Drobiazko wrote:
> Sorry, the last message was confusing. Forget the statement about
> FactoryDefault's and ApplicationDefaults.
>
> But there is a challenge. Right now the decision whether a service is
> reloadable or not is made during binding. At bind time you don't have access
> to symbols.
>
> On Tue, Aug 17, 2010 at 8:22 AM, Igor Drobiazko <ig...@gmail.com>wrote:
>
>> I would prefer a system property, not a symbol. The "global switch on/off"
>> is only for development and you will never override the FactoryDefault's
>> value in ApplicationDefaults.
>>
>>
>> On Mon, Aug 16, 2010 at 7:27 PM, Robert Zeigler <ro...@scazdl.org>wrote:
>>
>>> I love live service implementation reloading, and I would hate to have to
>>> explicitly enable it for every service I create. I'm in favor of the "global
>>> on/off switch" as proposed by, eg, Michal Gruca. I'm not sure if it would
>>> be feasible to have a global "off" and then an enableReloading() call for
>>> specific services, but, at the very least, having it be "off"="everything
>>> off", and "on" = retain current behavior (on except for services with
>>> preventReloading()) should be imminently doable. It may even be best to turn
>>> off live service reloading by default (in tapestry's
>>> contributeFactoryDefaults) so that you have the same behavior as before
>>> T5.2, and then you can turn on the reloading at your leisure. That way,
>>> upgrade = painless, but it's still easy to globally turn on the feature (for
>>> people like me who love it and don't have any access issues :).
>>>
>>> Robert
>>>
>>> On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
>>>
>>>> On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <
>>> igor.drobiazko@gmail.com> wrote:
>>>>
>>>>> So, what is the consensus on fixing the issue?
>>>>
>>>> +1 for live reloading of a given service live needing an explicit action
>>> from the Tapestry user (i.e. enableReloading()).
>>>>
>>>> As it is now, Tapestry-IoC is breaking backward compatibility in a
>>> serious way.
>>>>
>>>> --
>>>> Thiago H. de Paula Figueiredo
>>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>>> and instructor
>>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>>> http://www.arsmachina.com.br
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de
>>
>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
Sorry, the last message was confusing. Forget the statement about
FactoryDefault's and ApplicationDefaults.
But there is a challenge. Right now the decision whether a service is
reloadable or not is made during binding. At bind time you don't have access
to symbols.
On Tue, Aug 17, 2010 at 8:22 AM, Igor Drobiazko <ig...@gmail.com>wrote:
> I would prefer a system property, not a symbol. The "global switch on/off"
> is only for development and you will never override the FactoryDefault's
> value in ApplicationDefaults.
>
>
> On Mon, Aug 16, 2010 at 7:27 PM, Robert Zeigler <ro...@scazdl.org>wrote:
>
>> I love live service implementation reloading, and I would hate to have to
>> explicitly enable it for every service I create. I'm in favor of the "global
>> on/off switch" as proposed by, eg, Michal Gruca. I'm not sure if it would
>> be feasible to have a global "off" and then an enableReloading() call for
>> specific services, but, at the very least, having it be "off"="everything
>> off", and "on" = retain current behavior (on except for services with
>> preventReloading()) should be imminently doable. It may even be best to turn
>> off live service reloading by default (in tapestry's
>> contributeFactoryDefaults) so that you have the same behavior as before
>> T5.2, and then you can turn on the reloading at your leisure. That way,
>> upgrade = painless, but it's still easy to globally turn on the feature (for
>> people like me who love it and don't have any access issues :).
>>
>> Robert
>>
>> On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
>>
>> > On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <
>> igor.drobiazko@gmail.com> wrote:
>> >
>> >> So, what is the consensus on fixing the issue?
>> >
>> > +1 for live reloading of a given service live needing an explicit action
>> from the Tapestry user (i.e. enableReloading()).
>> >
>> > As it is now, Tapestry-IoC is breaking backward compatibility in a
>> serious way.
>> >
>> > --
>> > Thiago H. de Paula Figueiredo
>> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and instructor
>> > Owner, Ars Machina Tecnologia da Informação Ltda.
>> > http://www.arsmachina.com.br
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
I would prefer a system property, not a symbol. The "global switch on/off"
is only for development and you will never override the FactoryDefault's
value in ApplicationDefaults.
On Mon, Aug 16, 2010 at 7:27 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> I love live service implementation reloading, and I would hate to have to
> explicitly enable it for every service I create. I'm in favor of the "global
> on/off switch" as proposed by, eg, Michal Gruca. I'm not sure if it would
> be feasible to have a global "off" and then an enableReloading() call for
> specific services, but, at the very least, having it be "off"="everything
> off", and "on" = retain current behavior (on except for services with
> preventReloading()) should be imminently doable. It may even be best to turn
> off live service reloading by default (in tapestry's
> contributeFactoryDefaults) so that you have the same behavior as before
> T5.2, and then you can turn on the reloading at your leisure. That way,
> upgrade = painless, but it's still easy to globally turn on the feature (for
> people like me who love it and don't have any access issues :).
>
> Robert
>
> On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
>
> > On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> wrote:
> >
> >> So, what is the consensus on fixing the issue?
> >
> > +1 for live reloading of a given service live needing an explicit action
> from the Tapestry user (i.e. enableReloading()).
> >
> > As it is now, Tapestry-IoC is breaking backward compatibility in a
> serious way.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> > Owner, Ars Machina Tecnologia da Informação Ltda.
> > http://www.arsmachina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Robert Zeigler <ro...@scazdl.org>.
I love live service implementation reloading, and I would hate to have to explicitly enable it for every service I create. I'm in favor of the "global on/off switch" as proposed by, eg, Michal Gruca. I'm not sure if it would be feasible to have a global "off" and then an enableReloading() call for specific services, but, at the very least, having it be "off"="everything off", and "on" = retain current behavior (on except for services with preventReloading()) should be imminently doable. It may even be best to turn off live service reloading by default (in tapestry's contributeFactoryDefaults) so that you have the same behavior as before T5.2, and then you can turn on the reloading at your leisure. That way, upgrade = painless, but it's still easy to globally turn on the feature (for people like me who love it and don't have any access issues :).
Robert
On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
> On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <ig...@gmail.com> wrote:
>
>> So, what is the consensus on fixing the issue?
>
> +1 for live reloading of a given service live needing an explicit action from the Tapestry user (i.e. enableReloading()).
>
> As it is now, Tapestry-IoC is breaking backward compatibility in a serious way.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko
<ig...@gmail.com> wrote:
> So, what is the consensus on fixing the issue?
+1 for live reloading of a given service live needing an explicit action
from the Tapestry user (i.e. enableReloading()).
As it is now, Tapestry-IoC is breaking backward compatibility in a serious
way.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
So, what is the consensus on fixing the issue?
On Thu, Aug 12, 2010 at 2:33 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 12 Aug 2010 02:55:12 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> wrote:
>
> For backward compatibility reasons it should be enableReloading() and not
>> preventReloading().
>>
>
> Very nice idea, Igor!
>
>
> Otherwise the most apps will suffer from this issue. Do you remember our
>> promise? Making new features (that can break my app)
>> configurable and disabling them per default is a good practise.
>>
>
> Exactly. The less unexpected problems, the better.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 12 Aug 2010 02:55:12 -0300, Igor Drobiazko
<ig...@gmail.com> wrote:
> For backward compatibility reasons it should be enableReloading() and not
> preventReloading().
Very nice idea, Igor!
> Otherwise the most apps will suffer from this issue. Do you remember our
> promise? Making new features (that can break my app)
> configurable and disabling them per default is a good practise.
Exactly. The less unexpected problems, the better.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
Backward compatibility is not the only one issue. Think of new users who are
experimenting with Tapestry. If everything is realodable per default, it is
very likely that they app will be broken. They will write some package
private methods and experience errors which are very hard to understand.
After that they will be annoyed and say that Tapestry is broken and bad. Do
we really want it?
On Thu, Aug 12, 2010 at 8:45 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> I agree about backward compatibility, but introducing new features disabled
> by default may cause that nobody will use those features even in new
> applications.
> I like the idea to analyze if service can be made reloadable in runtime and
> log warning if it doesn't. This won't break compatibility but give new
> projects chance to use live class reloading without additional
> configuration.
>
> On Thu, Aug 12, 2010 at 09:55, Igor Drobiazko <igor.drobiazko@gmail.com
> >wrote:
>
> > For backward compatibility reasons it should be enableReloading() and not
> > preventReloading(). Otherwise the most apps will suffer from this issue.
> Do
> > you remember our promise? Making new features (that can break my app)
> > configurable and disabling them per default is a good practise.
> >
> >
> > On Thu, Aug 12, 2010 at 1:01 AM, Robert Zeigler <ro...@scazdl.org>
> > wrote:
> >
> > > Does:
> > > binder.bind(Interface.class, Implementation.class).preventReloading();
> > >
> > > not do the trick?
> > >
> > > It's already disabled for services that use buildXXX since Tapestry
> won't
> > > know the implementation class of the service.
> > >
> > > Robert
> > >
> > > On Aug 11, 2010, at 8/115:40 PM , Thiago H. de Paula Figueiredo wrote:
> > >
> > > > On Wed, 11 Aug 2010 19:18:42 -0300, Igor Drobiazko <
> > > igor.drobiazko@gmail.com> wrote:
> > > >
> > > >> But you would recreate only those services that you need right now.
> > All
> > > >> other "heavy" services are created later on demand.
> > > >
> > > > These heavy service methods could be invoked by the recreated
> services,
> > > but I agree with you too.
> > > >
> > > > By the way, I couldn't find any way of disabling the services live
> > > reloading. Is there any? If not, it would be nice to have one.
> > > >
> > > > --
> > > > Thiago H. de Paula Figueiredo
> > > > Independent Java, Apache Tapestry 5 and Hibernate consultant,
> > developer,
> > > and instructor
> > > > Owner, Ars Machina Tecnologia da Informação Ltda.
> > > > http://www.arsmachina.com.br
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > Best regards,
> >
> > Igor Drobiazko
> > http://tapestry5.de
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Dmitry Gusev <dm...@gmail.com>.
I agree about backward compatibility, but introducing new features disabled
by default may cause that nobody will use those features even in new
applications.
I like the idea to analyze if service can be made reloadable in runtime and
log warning if it doesn't. This won't break compatibility but give new
projects chance to use live class reloading without additional
configuration.
On Thu, Aug 12, 2010 at 09:55, Igor Drobiazko <ig...@gmail.com>wrote:
> For backward compatibility reasons it should be enableReloading() and not
> preventReloading(). Otherwise the most apps will suffer from this issue. Do
> you remember our promise? Making new features (that can break my app)
> configurable and disabling them per default is a good practise.
>
>
> On Thu, Aug 12, 2010 at 1:01 AM, Robert Zeigler <ro...@scazdl.org>
> wrote:
>
> > Does:
> > binder.bind(Interface.class, Implementation.class).preventReloading();
> >
> > not do the trick?
> >
> > It's already disabled for services that use buildXXX since Tapestry won't
> > know the implementation class of the service.
> >
> > Robert
> >
> > On Aug 11, 2010, at 8/115:40 PM , Thiago H. de Paula Figueiredo wrote:
> >
> > > On Wed, 11 Aug 2010 19:18:42 -0300, Igor Drobiazko <
> > igor.drobiazko@gmail.com> wrote:
> > >
> > >> But you would recreate only those services that you need right now.
> All
> > >> other "heavy" services are created later on demand.
> > >
> > > These heavy service methods could be invoked by the recreated services,
> > but I agree with you too.
> > >
> > > By the way, I couldn't find any way of disabling the services live
> > reloading. Is there any? If not, it would be nice to have one.
> > >
> > > --
> > > Thiago H. de Paula Figueiredo
> > > Independent Java, Apache Tapestry 5 and Hibernate consultant,
> developer,
> > and instructor
> > > Owner, Ars Machina Tecnologia da Informação Ltda.
> > > http://www.arsmachina.com.br
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
For backward compatibility reasons it should be enableReloading() and not
preventReloading(). Otherwise the most apps will suffer from this issue. Do
you remember our promise? Making new features (that can break my app)
configurable and disabling them per default is a good practise.
On Thu, Aug 12, 2010 at 1:01 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> Does:
> binder.bind(Interface.class, Implementation.class).preventReloading();
>
> not do the trick?
>
> It's already disabled for services that use buildXXX since Tapestry won't
> know the implementation class of the service.
>
> Robert
>
> On Aug 11, 2010, at 8/115:40 PM , Thiago H. de Paula Figueiredo wrote:
>
> > On Wed, 11 Aug 2010 19:18:42 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> wrote:
> >
> >> But you would recreate only those services that you need right now. All
> >> other "heavy" services are created later on demand.
> >
> > These heavy service methods could be invoked by the recreated services,
> but I agree with you too.
> >
> > By the way, I couldn't find any way of disabling the services live
> reloading. Is there any? If not, it would be nice to have one.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> > Owner, Ars Machina Tecnologia da Informação Ltda.
> > http://www.arsmachina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Dmitry Gusev <dm...@gmail.com>.
Btw, I believe most projects deployed on GAE doesn't use JAR packaging
because of GAE Eclipse plugin and *.class files are actually on the file
system in production (In Eclipse GAE plugin there is just an option to
deploy eclipse java project to GAE, I don't think that some packaging
happens during this process).
Just to clarify I understand this right: Is live class reloading turned off
when application runs in production mode?
On Thu, Aug 12, 2010 at 04:34, Howard Lewis Ship <hl...@gmail.com> wrote:
> Also, this only applies to development mode, where the .class files
> are on the file system. Classes loaded from JARs are not reloaded and
> use the standard class loader.
>
> On Wed, Aug 11, 2010 at 5:33 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
> > In most cases, they will still work. For instance, reloadable class B
> > can extend class A and even invoke its protected methods. What gets
> > you is package private access, or access to protected methods from
> > non-inheriting classes within the same package.
> >
> > On Wed, Aug 11, 2010 at 4:35 PM, Thiago H. de Paula Figueiredo
> > <th...@gmail.com> wrote:
> >> On Wed, 11 Aug 2010 20:01:29 -0300, Robert Zeigler <ro...@scazdl.org>
> >> wrote:
> >>
> >>> Does:
> >>> binder.bind(Interface.class, Implementation.class).preventReloading();
> >>> not do the trick?
> >>
> >> I haven't tried, but I guess it does. I was talking about a single
> switch
> >> for all services in the registry. Think about projects using autobound
> >> services whose implementation is a subclass and I can't/don't want
> change
> >> the sources. For example, my packages and apps have several service
> >> implementations that are subclasses.
> >>
> >> --
> >> Thiago H. de Paula Figueiredo
> >> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and
> >> instructor
> >> Owner, Ars Machina Tecnologia da Informação Ltda.
> >> http://www.arsmachina.com.br
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@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
> >
>
>
>
> --
> 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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Howard Lewis Ship <hl...@gmail.com>.
Also, this only applies to development mode, where the .class files
are on the file system. Classes loaded from JARs are not reloaded and
use the standard class loader.
On Wed, Aug 11, 2010 at 5:33 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> In most cases, they will still work. For instance, reloadable class B
> can extend class A and even invoke its protected methods. What gets
> you is package private access, or access to protected methods from
> non-inheriting classes within the same package.
>
> On Wed, Aug 11, 2010 at 4:35 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> On Wed, 11 Aug 2010 20:01:29 -0300, Robert Zeigler <ro...@scazdl.org>
>> wrote:
>>
>>> Does:
>>> binder.bind(Interface.class, Implementation.class).preventReloading();
>>> not do the trick?
>>
>> I haven't tried, but I guess it does. I was talking about a single switch
>> for all services in the registry. Think about projects using autobound
>> services whose implementation is a subclass and I can't/don't want change
>> the sources. For example, my packages and apps have several service
>> implementations that are subclasses.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
>> instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@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
>
--
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Howard Lewis Ship <hl...@gmail.com>.
In most cases, they will still work. For instance, reloadable class B
can extend class A and even invoke its protected methods. What gets
you is package private access, or access to protected methods from
non-inheriting classes within the same package.
On Wed, Aug 11, 2010 at 4:35 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Wed, 11 Aug 2010 20:01:29 -0300, Robert Zeigler <ro...@scazdl.org>
> wrote:
>
>> Does:
>> binder.bind(Interface.class, Implementation.class).preventReloading();
>> not do the trick?
>
> I haven't tried, but I guess it does. I was talking about a single switch
> for all services in the registry. Think about projects using autobound
> services whose implementation is a subclass and I can't/don't want change
> the sources. For example, my packages and apps have several service
> implementations that are subclasses.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 11 Aug 2010 20:01:29 -0300, Robert Zeigler <ro...@scazdl.org>
wrote:
> Does:
> binder.bind(Interface.class, Implementation.class).preventReloading();
> not do the trick?
I haven't tried, but I guess it does. I was talking about a single switch
for all services in the registry. Think about projects using autobound
services whose implementation is a subclass and I can't/don't want change
the sources. For example, my packages and apps have several service
implementations that are subclasses.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Robert Zeigler <ro...@scazdl.org>.
Does:
binder.bind(Interface.class, Implementation.class).preventReloading();
not do the trick?
It's already disabled for services that use buildXXX since Tapestry won't know the implementation class of the service.
Robert
On Aug 11, 2010, at 8/115:40 PM , Thiago H. de Paula Figueiredo wrote:
> On Wed, 11 Aug 2010 19:18:42 -0300, Igor Drobiazko <ig...@gmail.com> wrote:
>
>> But you would recreate only those services that you need right now. All
>> other "heavy" services are created later on demand.
>
> These heavy service methods could be invoked by the recreated services, but I agree with you too.
>
> By the way, I couldn't find any way of disabling the services live reloading. Is there any? If not, it would be nice to have one.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 11 Aug 2010 19:18:42 -0300, Igor Drobiazko
<ig...@gmail.com> wrote:
> But you would recreate only those services that you need right now. All
> other "heavy" services are created later on demand.
These heavy service methods could be invoked by the recreated services,
but I agree with you too.
By the way, I couldn't find any way of disabling the services live
reloading. Is there any? If not, it would be nice to have one.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
But you would recreate only those services that you need right now. All
other "heavy" services are created later on demand.
On Wed, Aug 11, 2010 at 11:53 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Wed, 11 Aug 2010 18:51:44 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> wrote:
>
> Why not? How expensive is it to reload all the implementations?
>>
>
> I think the issue here is not how expensive it is, but the state of the
> services. I guess it's quite likely for an application to have services that
> aren't meant to be reinitialized all the time, specially when they do some
> costly operation in a constructor, for example.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 11 Aug 2010 18:51:44 -0300, Igor Drobiazko
<ig...@gmail.com> wrote:
> Why not? How expensive is it to reload all the implementations?
I think the issue here is not how expensive it is, but the state of the
services. I guess it's quite likely for an application to have services
that aren't meant to be reinitialized all the time, specially when they do
some costly operation in a constructor, for example.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
Why not? How expensive is it to reload all the implementations?
On Wed, Aug 11, 2010 at 11:04 PM, Howard Lewis Ship <hl...@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
> <ig...@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 <hlship@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
> >> <ka...@gmail.com> wrote:
> >> > On Wed, Aug 11, 2010 at 12:32 PM, Thiago H. de Paula Figueiredo
> >> > <th...@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-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Robert Zeigler <ro...@scazdl.org>.
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
> <ig...@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 <hl...@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
>>> <ka...@gmail.com> wrote:
>>>> On Wed, Aug 11, 2010 at 12:32 PM, Thiago H. de Paula Figueiredo
>>>> <th...@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ig...@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 <hl...@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
>> <ka...@gmail.com> wrote:
>> > On Wed, Aug 11, 2010 at 12:32 PM, Thiago H. de Paula Figueiredo
>> > <th...@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-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Igor Drobiazko <ig...@gmail.com>.
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 <hl...@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
> <ka...@gmail.com> wrote:
> > On Wed, Aug 11, 2010 at 12:32 PM, Thiago H. de Paula Figueiredo
> > <th...@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ka...@gmail.com> wrote:
> On Wed, Aug 11, 2010 at 12:32 PM, Thiago H. de Paula Figueiredo
> <th...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by Kalle Korhonen <ka...@gmail.com>.
On Wed, Aug 11, 2010 at 12:32 PM, Thiago H. de Paula Figueiredo
<th...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Hi, guys!
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?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org