Bugs item #565701, was opened at 2002-06-07 01:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=565701&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nigel Magnay (magnayn)
>Assigned to: Scott M Stark (starksm)
Summary: IllegalAccessException in 3.0 Release
Initial Comment:
I have a couple of EARs that run fine in 2.4, and I am
wondering what has changed to cause this
to happen. Environment is Win2K/3.0.0 release/JDK
1.4.0.
I have 2 EARs : sef.ear and aa.ear.
sef.ear contains an EJB - SessionManagerBean, which
loads and saves objects of type 'SessionEnv'
into a database. Both SessionManagerBean and
SessionEnv exist in the same package.
aa.ear contains unrelated code, but has a 'sef.jar'
which contains a copy of SessionEnv, so that the
SessionManagerBean is callable by that application.
SessionEnv has a protected method called setExpiryDate
which is called by SessionManagerBean.load,
which is allowed because both classes are in the same
package.
A servlet inside sef.ear configures a new SessionEnv
object, and calls save on the EJB. this writes
the instance to an Oracle database.
Later on, a servlet inside aa.ear calls the
SessionManagerBean EJB in order to load the EJB. This
has
always worked before. Now the instantiation appears to
work correctly. However, when the EJB
attempts to call setExpiryDate (the protected method),
I get:
08:49:17,329 ERROR [LogInterceptor]
TransactionRolledbackException, causedBy:
java.lang.IllegalAccessError: try to access method
com.newton.sef.service.session.SessionEnv.setExpiryDate
(Ljava/util/Date;)V from class com.newton.se
f.service.session.SessionManagerBean
at
com.newton.sef.service.session.SessionManagerBean.load
(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterc
eptor.invoke(StatelessSessionContainer.java:664)
at
org.jboss.resource.connectionmanager.CachedConnectionIn
terceptor.invoke(CachedConnectionInterceptor.java:186)
at
org.jboss.ejb.plugins.StatelessSessionInstanceIntercept
or.invoke(StatelessSessionInstanceInterceptor.java:77)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:96)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:167)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:61)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:129)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:166)
at
org.jboss.ejb.StatelessSessionContainer.invoke
(StatelessSessionContainer.java:313)
at org.jboss.ejb.Container.invoke
(Container.java:705)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:491)
at
org.jboss.invocation.local.LocalInvoker.invoke
(LocalInvoker.java:98)
at
org.jboss.invocation.InvokerInterceptor.invoke
(InvokerInterceptor.java:102)
at
org.jboss.proxy.TransactionInterceptor.invoke
(TransactionInterceptor.java:73)
at org.jboss.proxy.SecurityInterceptor.invoke
(SecurityInterceptor.java:76)
at
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke
(StatelessSessionInterceptor.java:111)
at org.jboss.proxy.ClientContainer.invoke
(ClientContainer.java:76)
...error trimmed...
Both aa.ear and sef.ear were recompiled from source
and redeployed at the same time.
Am I missing something or does anyone have any ideas
as to why the JVM thinks it shouldn't be allowed
to access the method?
----------------------------------------------------------------------
>Comment By: Scott M Stark (starksm)
Date: 2002-06-13 19:27
Message:
Logged In: YES
user_id=175228
3.0 has a shared class loader repository and the exception you see
will happen if the SessionEnv is loaded from aa.ear first and then
SessionManagerBean is loaded from sef.ear. Since these classes
will have been loaded by two different class loader they are not in the
same package as far as permissions go. Factor out the common
classes into a seperate jar to fix the problem.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=565701&group_id=22866
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
