[JBoss JIRA] (WFLY-1763) Escaped transactions stay associated with a HTTP request thread after they timeout
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1763?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-1763:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> Escaped transactions stay associated with a HTTP request thread after they timeout
> ----------------------------------------------------------------------------------
>
> Key: WFLY-1763
> URL: https://issues.jboss.org/browse/WFLY-1763
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Environment: JBoss EAP 6.1
> Reporter: Tom Ross
> Assignee: Stuart Douglas
>
> When a transaction times out during execution of HTTP request and an inadequate error handling lets it escape the next HTTP request gets exception:
> {noformat}
> 20130528,17:20:05,561 ERROR [CheckupAction] DB-HIBERNATE: ERROR: xx.yyy.zzz.utils.TransactionAdapterSDB$TransactionSDBException: java.lang.RuntimeException: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - ARJUNA016051:
> thread is already associated with a transaction!
> at xx.yyy.zzz.utils.TransactionAdapterSDB.begin(TransactionAdapterSDB.java:85) [WebPortalCore.jar:]
> at xx.yyy.apps.crmtrk.web.component.HibernateSessionHandler.getHBS(HibernateSessionHandler.java:30) [WebPortalCore.jar:]
> at xx.yyy.apps.crmtrk.web.action.HibernateAction.getHBS(HibernateAction.java:91) [WebPortalCore.jar:]
> at xx.yyy.apps.crmtrk.web.action.CheckupAction.execute(CheckupAction.java:643) [classes:]
> at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:283) [xwork-1.0.5.jar:]
> at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:166) [xwork-1.0.5.jar:]
> at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) [xwork-1.0.5.jar:]
> at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164) [xwork-1.0.5.jar:]
> at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) [xwork-1.0.5.jar:]
> at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164) [xwork-1.0.5.jar:]
> at xx.yyy.apps.crmtrk.web.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:80)
> {noformat}
> This does not happen to transactions that did not timed out. They seemed to be cleaned up.
> This is due to the TransactionRollbackSetupAction class that supposed to make sure that there are not transaction leaks in EE request. There is a method checkTransactionStatus() that performs a check on an escaped transaction and does a rollback() if it finds a transaction with following status:
> {noformat}
> switch (status) {
> case Status.STATUS_ACTIVE:
> case Status.STATUS_COMMITTING:
> case Status.STATUS_MARKED_ROLLBACK:
> case Status.STATUS_PREPARING:
> case Status.STATUS_ROLLING_BACK:
> case Status.STATUS_PREPARED:
> try {
> TransactionLogger.ROOT_LOGGER.transactionStillOpen(status);
> tm.rollback();
> } catch (Exception ex) {
> TransactionLogger.ROOT_LOGGER.unableToRollBack(ex);
> }
> }
> {noformat}
> The status of a timed out transaction is STATUS_ROLLEDBACK which explains why it escapes this cleanup attempt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-803) "NullPointerException" in RemotingConnectionEJBReceiver constructor if misconfigured
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-803?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas updated WFLY-803:
--------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> "NullPointerException" in RemotingConnectionEJBReceiver constructor if misconfigured
> ------------------------------------------------------------------------------------
>
> Key: WFLY-803
> URL: https://issues.jboss.org/browse/WFLY-803
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Tested with 7.2.0 Alpha snapshot of 2013-02-05
> Sample project is build with Java 1.7
> Reporter: Wolfgang Knauf
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: StatelessStandaloneClient.zip
>
>
> While experimenting with EJB remote access, I got confused with the proper configuration ;-). This resulted in a NullPointerException in one of your EJB client classes, and I think this should be handled by a meaningful error message.
> I performed a lookup for "ejb:Stateless/StatelessEJB//GeometricModelBean!de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote" => this means I want to use the JNDI lookup.
> But in "jndi.properties", I used this: "jboss.naming.client.ejb.context=true" => This should probably activate "jboss-remote naming", and the lookup should be done for "Stateless/StatelessEJB//GeometricModelBean...". (no "ejb:" prefix).
> Instead of an error message, this resulted in this console output, followed by an exception:
> Feb 05, 2013 10:43:57 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.14.GA
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
> INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@28ad5a, receiver=Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante]} on channel Channel ID b93e696f (outbound) of Remoting connection 00411379 to localhost/127.0.0.1:4447
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000015: Initial module availability report for Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante] wasn't received during the receiver context association
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 1.0.16.Final
> java.lang.NullPointerException
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:90)
> at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:420)
> at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getContext(RemoteNamingEjbClientContextSelector.java:60)
> at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:46)
> at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:15)
> at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271)
> at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:156)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
> at sun.proxy.$Proxy0.computeCuboidVolume(Unknown Source)
> at de.fhw.komponentenarchitekturen.knauf.stateless.standaloneclient.GeometricModelApplicationClient.main(GeometricModelApplicationClient.java:38)
> I will attach a sample. This is an Eclipse project. But i can also be run standalone: just modify "StatelessStandaloneClient\startclient.bat" to match your path to "jboss-client.jar" and start it (you need Java 1.7 for this). You don't even have to deploy the EAR app on the server to see the error. But if you want to do so: it is also part of the attachment: "Stateless.ear".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-972) EJB calendar timer Sunday calculation problem in certain locales
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas updated WFLY-972:
--------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
> Key: WFLY-972
> URL: https://issues.jboss.org/browse/WFLY-972
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: JDK 6 & 7
> Reporter: Cheng Fang
> Assignee: Stuart Douglas
>
> My ejb class contains this timeout method:
> {code:java}
> @Schedule(dayOfWeek="Sun", persistent=false)
> private void sunday(Timer t) {
> }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc). It works as expected on other locales like en_US.
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug. There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday. Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes." I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2011?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-2011:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
> -------------------------------------------------------------------------------------
>
> Key: WFLY-2011
> URL: https://issues.jboss.org/browse/WFLY-2011
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: Stuart Douglas
> Labels: ejb-jar.xml
>
> If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.
> From the XSD the <ejb-name> element can not be added multiple times.
> And the following configuration will be not valid:
> <assembly-descriptor>
> <c:clustering>
> <ejb-name>Bean1</ejb-name>
> <ejb-name>Bean2</ejb-name>
> <c:clustered>true</c:clustered>
> </c:clustering>
> </assembly-descriptor>
> The parser should throw an Exception and the application should not be deployed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2016) Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the caller thread
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2016?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-2016:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the caller thread
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2016
> URL: https://issues.jboss.org/browse/WFLY-2016
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Security
> Affects Versions: 8.0.0.Alpha4
> Reporter: jaikiran pai
> Assignee: Stuart Douglas
>
> Consider a servlet "S" which invokes on a asynchronous EJB "A". Let's assume "S" runs with a "foo" run-as role. Now when S invokes on "A", the run-as "foo" role is correctly propagated to the asynchronous EJB invocation. However, when the "S" invocation completes and potentially clears the security context (of any run-as role), the invocation(s) within the asynchronous EJB "A" too lose the corresponding security context role association. This is because the 2 threads (the servlet invocation one and the async EJB invocation one) literally share the same object instance of the SecurityContext.
> The expected behaviour is that the original security context (attributes) are copied over to the async invocation and updates to that security context later on in a separate thread shouldn't affect the ongoing async EJB invocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-835) @Resource UserTransaction error when file passivation store is selected
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas updated WFLY-835:
--------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
> Key: WFLY-835
> URL: https://issues.jboss.org/browse/WFLY-835
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: Ubuntu 11.10, Intel® Core™ i3-2120 CPU @ 3.30GHz × 4
> Reporter: Abraham Cabanillas Piera
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: jboss
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 15 more
> Caused by: an exception which occurred:
> in field userTransaction
> in field instance
> in field instance
> in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl@6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="10000" cache-ref="passivating"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <mdb>
> <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple" aliases="NoPassivationCache"/>
> <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
> </caches>
> <passivation-stores>
> <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
> </passivation-stores>
> <async thread-pool-name="default"/>
> <timer-service thread-pool-name="default">
> <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
> </timer-service>
> <remote connector-ref="remoting-connector" thread-pool-name="default"/>
> <thread-pools>
> <thread-pool name="default">
> <max-threads count="100"/>
> <keepalive-time time="100" unit="milliseconds"/>
> </thread-pool>
> </thread-pools>
> <iiop enable-by-default="false" use-qualified-name="false"/>
> </subsystem>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-1766) The @Local annotation on a session bean "overrides" information about @Local interfaces implemented through keyword "implements"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1766?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-1766:
---------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> The @Local annotation on a session bean "overrides" information about @Local interfaces implemented through keyword "implements"
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1766
> URL: https://issues.jboss.org/browse/WFLY-1766
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha3
> Reporter: Matus Abaffy
> Assignee: Stuart Douglas
>
> I have the following interfaces
> {code}
> public interface Bar { }
> {code}
> {code}
> @Local
> public interface Foo { }
> {code}
> and a session bean
> {code}
> @Local(Bar.class)
> @Stateful
> public class SessionBean implements Foo { }
> {code}
> EJB 3.2 specification (4.9.7 Session Bean’s Business Interface) states:
> "any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means:
> • using the Local or Remote annotation with a non-empty value on the bean class
> • using the Local or Remote annotation on the interface
> • in the deployment descriptor"
> Therefore, I assume SessionBean should expose both Bar and Foo as local business interfaces. However, only Bar is exposed:
> {noformat}
> ...
> INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named SessionBean in deployment unit deployment "pckg.war" are as follows:
> java:global/pckg/SessionBean!org.jboss. ... .Bar
> java:app/pckg/SessionBean!org.jboss. ... .Bar
> java:module/SessionBean!org.jboss. ... .Bar
> java:global/pckg/SessionBean
> java:app/pckg/SessionBean
> java:module/SessionBean
> {noformat}
> It seems that the @Local annotation on a session bean class "overrides" all information about @Local interfaces implemented using the keyword "implements". (It does not ignore @Remote interfaces implemented using the keyword "implements".)
> The @Remote annotation on a session bean class works analogically - it causes @Remote interfaces implemented using the keyword "implements" not to be contained in the set of remote business interfaces.
> I haven't tried yet what happens if I declare another interface(s) for certain session beans as local/remote in the deployment descriptor - whether those defined in the java classes become "overriden". But I'd like to know what SHOULD happen. If it is not clear from the EJB spec., the exact behaviour in such case should be stated specifically for Wildfly - I'd be grateful for any links to such information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months