You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by P....@albourne.com on 2011/04/14 11:55:39 UTC
IllegalAccessError in IoC
Hi Howard et al,
We are using Tapestry 5 IoC in all our applications (both standalone and web), and have a very sizeable IoC code base. We have tried a couple of times now to upgrade it from 5.1 and 5.2.4, but it seems backwards compatibility is broken... The problem we are stuck on now is whenever a non-public method is called from within a service we are getting the dreaded IllegalAccessError. I have not dug very deep into Tapestrys internals to figure out why this is happening yet, but I am certain that in Tapestry 5.1 this is not the case.
You might suggest to simply change the scope of these methods and classes but we can't easily re-factor our library modules because of the sheer scale, and even if it were an option, and we did consider it for a time, these errors produce runtime exceptions, which makes it is very difficult to find every occurrence in the code, so for us to change the scope for our entire IoC codebase is not a practical solution. This seems like a big change from 5.1, and is a real blocker for us, I would greatly appreciate any assistance.
Thanks,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: IllegalAccessError in IoC
Posted by Kristian Marinkovic <kr...@porscheinformatik.at>.
Hi Peter,
we do have the same problem here.
there are two solutions we use to circumvent this problem:
1) keep your modules (projects) closed; Tapestry 5.2 will only create
proxies for services without a interface only if it can find the class
file in the local filesytem (not in jar file)
2) create a patched tapestry 5.2.5 version that does not create proxies
for services without a interface:
AbstractConfigurationImpl -> if (contributionType.isInterface() &&
InternalUtils.isLocalFile(clazz))
remove the isLocalFile part; it is not possible to make it configurable
via a SymbolSource due to recursions.
g,
kris
Von: P.Stavrinides@albourne.com
An: Tapestry Mailing List <us...@tapestry.apache.org>
Datum: 14.04.2011 11:56
Betreff: IllegalAccessError in IoC
Hi Howard et al,
We are using Tapestry 5 IoC in all our applications (both standalone and
web), and have a very sizeable IoC code base. We have tried a couple of
times now to upgrade it from 5.1 and 5.2.4, but it seems backwards
compatibility is broken... The problem we are stuck on now is whenever a
non-public method is called from within a service we are getting the
dreaded IllegalAccessError. I have not dug very deep into Tapestrys
internals to figure out why this is happening yet, but I am certain that
in Tapestry 5.1 this is not the case.
You might suggest to simply change the scope of these methods and classes
but we can't easily re-factor our library modules because of the sheer
scale, and even if it were an option, and we did consider it for a time,
these errors produce runtime exceptions, which makes it is very difficult
to find every occurrence in the code, so for us to change the scope for
our entire IoC codebase is not a practical solution. This seems like a big
change from 5.1, and is a real blocker for us, I would greatly appreciate
any assistance.
Thanks,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: IllegalAccessError in IoC
Posted by Peter Stavrinides <P....@albourne.com>.
Thanks very much for the explanation Howard!!
Cheers,
Peter
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Thursday, 14 April, 2011 19:21:03 GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: Re: IllegalAccessError in IoC
On Thu, Apr 14, 2011 at 2:55 AM, <P....@albourne.com> wrote:
> Hi Howard et al,
>
> We are using Tapestry 5 IoC in all our applications (both standalone and web), and have a very sizeable IoC code base. We have tried a couple of times now to upgrade it from 5.1 and 5.2.4, but it seems backwards compatibility is broken... The problem we are stuck on now is whenever a non-public method is called from within a service we are getting the dreaded IllegalAccessError. I have not dug very deep into Tapestrys internals to figure out why this is happening yet, but I am certain that in Tapestry 5.1 this is not the case.
>
When Tapestry loads a service it creates a new class loader for it.
The service class and its inner classes and base classes are loaded by
that class loader, but it causes problems accessing non-public members
of other classes in the same package: it's not really the same class
or the same package, it just shares the package name and class name.
A very, very leaky abstraction (one of the reasons I didn't attempt
live service reloading earlier it because its impossible to do it
"right" without much more intrusive technology, such as an agent).
When you bind() a service, you can now explicitly disable live service
reloading for that one service, see ServiceBindingOptions.
> You might suggest to simply change the scope of these methods and classes but we can't easily re-factor our library modules because of the sheer scale, and even if it were an option, and we did consider it for a time, these errors produce runtime exceptions, which makes it is very difficult to find every occurrence in the code, so for us to change the scope for our entire IoC codebase is not a practical solution. This seems like a big change from 5.1, and is a real blocker for us, I would greatly appreciate any assistance.
>
> Thanks,
> Peter
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: IllegalAccessError in IoC
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Thu, Apr 14, 2011 at 2:55 AM, <P....@albourne.com> wrote:
> Hi Howard et al,
>
> We are using Tapestry 5 IoC in all our applications (both standalone and web), and have a very sizeable IoC code base. We have tried a couple of times now to upgrade it from 5.1 and 5.2.4, but it seems backwards compatibility is broken... The problem we are stuck on now is whenever a non-public method is called from within a service we are getting the dreaded IllegalAccessError. I have not dug very deep into Tapestrys internals to figure out why this is happening yet, but I am certain that in Tapestry 5.1 this is not the case.
>
When Tapestry loads a service it creates a new class loader for it.
The service class and its inner classes and base classes are loaded by
that class loader, but it causes problems accessing non-public members
of other classes in the same package: it's not really the same class
or the same package, it just shares the package name and class name.
A very, very leaky abstraction (one of the reasons I didn't attempt
live service reloading earlier it because its impossible to do it
"right" without much more intrusive technology, such as an agent).
When you bind() a service, you can now explicitly disable live service
reloading for that one service, see ServiceBindingOptions.
> You might suggest to simply change the scope of these methods and classes but we can't easily re-factor our library modules because of the sheer scale, and even if it were an option, and we did consider it for a time, these errors produce runtime exceptions, which makes it is very difficult to find every occurrence in the code, so for us to change the scope for our entire IoC codebase is not a practical solution. This seems like a big change from 5.1, and is a real blocker for us, I would greatly appreciate any assistance.
>
> Thanks,
> Peter
>
>
>
>
>
> ---------------------------------------------------------------------
> 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