You may need to turn off live service reloading entirely; add -Dtapestry.service-reloading-enabled=false to your command line.
On Thu, Apr 14, 2011 at 5:58 AM, <p.stavrini...@albourne.com> wrote: > Thanks very much for the reply Kristian, I will give it a try and let you > know. > > Cheers, > Peter > > ----- Original Message ----- > From: "Kristian Marinkovic" <kristian.marinko...@porscheinformatik.at> > To: "Tapestry users" <users@tapestry.apache.org> > Sent: Thursday, 14 April, 2011 13:12:58 GMT +02:00 Athens, Beirut, Bucharest, > Istanbul > Subject: Re: IllegalAccessError in IoC > > 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.stavrini...@albourne.com > An: Tapestry Mailing List <users@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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-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: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
