[JBoss JIRA] Created: (JBAS-4043) Allow webapps for different tomcat services to deployed in the same .ear
by Martin Welss (JIRA)
Allow webapps for different tomcat services to deployed in the same .ear
------------------------------------------------------------------------
Key: JBAS-4043
URL: http://jira.jboss.com/jira/browse/JBAS-4043
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.5.GA
Environment: jboss with embedded tomcat configured with 2 services, like in JBAS-2410
Reporter: Martin Welss
Assigned To: Dimitris Andreadis
The second tomcat service has its own deployment directory, so the deployment has to be splitted into two separate files. This causes timing problems (NoClassDefFoundError), because our ejb3 application takes amch longer to deploy than our webapp.
Maybe a new tag in jbossweb.xml could target the webapp to the respective tomcat-service
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (EJBTHREE-978) Deployer should ignore files that Javassist throws a "non class file" exception for
by Josh Devins (JIRA)
Deployer should ignore files that Javassist throws a "non class file" exception for
-----------------------------------------------------------------------------------
Key: EJBTHREE-978
URL: http://jira.jboss.com/jira/browse/EJBTHREE-978
Project: EJB 3.0
Issue Type: Bug
Environment: JBoss 4.0.5 GA with EJB3 deployer and IBM DB2 JDBC driver v3.3.54
Reporter: Josh Devins
This is a follow-up to a Javassist issue # JASSIST-34.
For some reason, the IBM DB2 JDBC jar file contains a class that does not start with the magic code "0xCAFEBABE". When the EJB3 deployer looks at this jar file and scans the classes in it, Javassist is throwing an IOException with message "non class file". This is entirely useless to the end user since there is no information given about what class file or jar file is in error.
Javassist should be throwing a more descriptive exception (as per the issue JASSIST-34), and the EJB3 deployer should simply skip that file and output a warning telling the user/developer what jar file and class was in error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (JBAS-3405) Unable to secure JMX Invoker
by amdonov (JIRA)
Unable to secure JMX Invoker
----------------------------
Key: JBAS-3405
URL: http://jira.jboss.com/jira/browse/JBAS-3405
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.3 SP1
Environment: Windows Sun JDK 1.5
Reporter: amdonov
I am having the same problem securing the JMX invoker as the user in the referenced forum thread. However, I'm running 4.0.4.GA instead of 4.0.3 SP1. When, performing a clean installation using the installer. I selected the default configuration and elected to secure the invokers. The install completes without error. JBoss has the following error which is unfortunatly only written at the DEBUG level.
2006-07-20 10:40:47,541 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
at java.lang.Class.getConstructor0(Class.java:2647)
at java.lang.Class.getConstructor(Class.java:1629)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.install(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy6.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)
2006-07-20 10:40:47,551 DEBUG [org.jboss.system.ServiceCreator] Created bean:
Access to the adaptors is not restricted.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (JBAS-3644) ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
by anajavi (JIRA)
ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
----------------------------------------------------------------------------
Key: JBAS-3644
URL: http://jira.jboss.com/jira/browse/JBAS-3644
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CMP service
Affects Versions: JBossAS-4.0.3 SP1
Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
Reporter: anajavi
Assigned To: Alexey Loubyansky
Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index.
Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
Example:
Original EJBQL:
SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
Generated SQL:
SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o
LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id
LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id
LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id
WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
10x faster SQL:
SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o
INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id
INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id
INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id
WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
Thank you.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (EJBTHREE-1029) Invoke remote EJB3 from JVM 1.4 client
by Boris Maras (JIRA)
Invoke remote EJB3 from JVM 1.4 client
--------------------------------------
Key: EJBTHREE-1029
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
Project: EJB 3.0
Issue Type: Patch
Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
Client : JDK 1.4.2
Reporter: Boris Maras
Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.
So I used jbossretro to convert this jar in jdk 1.4 compatible format.
That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)
In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
- the client jar for your EJBs
- the generated jboss-ejb3-client14.jar
- jbossretro-rt.jar
- jboss-backport-concurrent.jar
- javassist.jar
I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.
I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.
I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
- uncompress the file jboss-ejb3.jar
- delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
- run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
- recompress the jar
This ant script should probably let you convert the jar of other versions of JBoss & EJB3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (EJBTHREE-1005) TxPropagationInterceptor requires use of IsLocalInterceptor
by Brian Stansberry (JIRA)
TxPropagationInterceptor requires use of IsLocalInterceptor
-----------------------------------------------------------
Key: EJBTHREE-1005
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1005
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.0 GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
The TxPropagationInterceptor will fail if a tx is running and a call to a local bean is not routed through IsLocalInterceptor.invokeLocal(). This means the IsLocalInterceptor.invokeLocal() routing can't be effectively disabled, which is a user request that comes up fairly often for EJB2. Users request this when they want the EJB requests load balanced, with no preference for the in-VM bean.
The same thing isn't a problem in EJB2, where transaction propagation is a function of the Invoker; the LocalInvoker just doesn't do it. But EJB3 doesn't have that option -- Remoting will bypass any invoker if it detects an in-VM target.
Couple possibilities:
1) Change TxPropagationInterceptor from:
Transaction tx = tm.getTransaction();
if (tx != null) throw new RuntimeException("cannot import a transaction context when a transaction is already associated with the thread");
Transaction importedTx = TransactionPropagationContextUtil.getTPCImporter().importTransactionPropagationContext(tpc);
tm.resume(importedTx);
to:
Transaction tx = tm.getTransaction();
Transaction importedTx = TransactionPropagationContextUtil.getTPCImporter().importTransactionPropagationContext(tpc);
if (tx != null)
{
if (tx != importedTx)
{
throw new RuntimeException("cannot import a transaction context when a transaction is already associated with the thread");
}
else
{
tm.resume(importedTx);
}
2) Have IsLocalInterceptor add some transient metadata to the invocation if it doesn't route the request via invokeLocal() -- i.e. if it expects the call is going remote. TxPropagationInterceptor can check for that metadata; if found it knows the call didn't actually go remote and can skip the import of the tx.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (EJBTHREE-862) EJB 3.0 dependencies injection accross EARs
by Roland R?z (JIRA)
EJB 3.0 dependencies injection accross EARs
-------------------------------------------
Key: EJBTHREE-862
URL: http://jira.jboss.com/jira/browse/EJBTHREE-862
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: EJB 3.0 RC9 - Patch 1
Environment: Windows, JDK 1.5.0_06-b05, JBoss 4.0.5 GA, EJB-3.0_RC9 Patch 1
Reporter: Roland R?z
We have a deployment schema similar to the example from EJB 3.0 specification (chapter 19.6 Example):
ear1:
FirstReferencer.jar Class-Path:FirstReferencer-client.jar SecondReferencer-client.jar
FirstReferencer-client.jar
SecondReferencer-client.jar
ear2:
SecondReferencer.jar Class-Path:SecondReferencer-client.jar
SecondReferencer-client.jar
deployment descriptor contains:
<ejb-client-jar>SecondReferencer-client.jar</ejb-client-jar>
There are two session beans FirstReferencer and SecondReferencer. FirstReferencer references SecondReferencer over the dependency injection. After deployment if we call the business method on the FirstReferencer, which in turn calls SecondReferencer we get exception like this:
16:22:12,155 ERROR [STDERR] java.lang.RuntimeException: Non matching type for inject of field: SecondReferencer FirstReferencerEjb.secondReferencer for type: $Proxy79 of jndiName env/FirstReferencerEjb/secondReferencer
intfs: , SecondReferencer, org.jboss.ejb3.JBossProxy, javax.ejb.EJBObject
16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:135)
16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:104)
16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:61)
16:22:12,155 ERROR [STDERR] at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:92)
16:22:12,155 ERROR [STDERR] at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
16:22:12,165 ERROR [STDERR] at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:209)
16:22:12,165 ERROR [STDERR] at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:303)
16:22:12,165 ERROR [STDERR] at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
16:22:12,165 ERROR [STDERR] at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
16:22:12,175 ERROR [STDERR] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
16:22:12,175 ERROR [STDERR] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
16:22:12,185 ERROR [STDERR] Caused by: java.lang.IllegalArgumentException
16:22:12,185 ERROR [STDERR] at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
16:22:12,185 ERROR [STDERR] at java.lang.reflect.Field.set(Field.java:656)
16:22:12,185 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:119)
16:22:12,185 ERROR [STDERR] ... 13 more
On debuging and from the stacktrace of the exception we can see that the lookup for refernced EJB works fine but the assigning over reflaction fails. It seems to be a ClassLoading issue there.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month