No luck here. I still get IllegalAccessError raised.
I probably don't have enough understanding of Tapestry to know where to
apply this reloading prevention, so I took my module service class where I
have filter registered, and add there this bind(..) method:
public static void bind(ServiceBinder binder) {
binder.bind(ComponentRequestFilter.class,
HibernateSessionFilter.class).preventReloading();
}
public static void contributeComponentRequestHandler(OrderedConfiguration
configuration) {
configuration.addInstance("HibernateSessionFilter",
HibernateSessionFilter.class);
}
As I said, my HibernateSessionFilter calls protected method on helper class
from same package, and error is raised there.
I don't want to sound ungrateful to Tapestry's good sides, and I know how
much of his life has Howard invested in this framework (i've been here sice
v3.0), but this kind of awkward things really can annoy someone who is
fairly acquainted with framework, let alone some newbie evaluating Tapestry.
It seems that newer versions of Tapestry always make 2 steps ahead, and one
behind. I recently trained first time few of coworkers in T5 so they can
maintain my web apps, and although they were impressed with some Tapestry's
features, they really blinked blankly when I explained to them they cannot
package their classes related to domain (due to reloading classloader), or
when I showed them how page activation parameters are not named or optional
so one has to use some tricks to achive that with cumbesome
onActivate()/onPassivate() when one develops some pages with multiple
activation contexts (simple example when editing page is used for creating
*and* updating some entitiy, each case asks for diffrerent activation
params). I informed them how with simple @ActivationRequestParameter one can
achiveve that now in 5.2, but their reaction was - "Isn't that basic feature
supose to be available in T5 from day one instead of bunch of other fancy
stuff since?"
Related to this classloading issues - it's not important whether few lines
of code can resolve certain problem, but it's mostly how counterintuitive it
is for someone who cannot do usual java programming as he always did. Most
of people work with many java libraries, and the probability is that you
never had to care about classloaders, and suddenly this seems very awkward.
Same kind of issues I had when I explained "abstract" fields in T4. It's not
the problem with amount of code you had to add, it's strangeness of abstract
getter/setter for purpose of single field is so far away to ordinarly java
coding that almost everyone dismiss it as too complicated.
I know this sounds a bit harsh, but it's not my opinion only - I've seen
these things in other people eyes. It's sad for me to see how my coworkers
use Spring and plan to continue to do so just because everything seems
natural, your brain is relaxed, although you have to do fair amount of
tedious tasks youself instead of framework.
Regards,
Vjeran
----- Original Message -----
From: "Howard Lewis Ship" <hls...@gmail.com>
Newsgroups: gmane.comp.java.tapestry.user
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Wednesday, August 11, 2010 6:54 PM
Subject: Re: Another IllegalAccessError in 5.2 alpha [bug?]
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
<vjeran.marci...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
