[JBoss JIRA] (AS7-4042) On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-4042?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-4042:
-----------------------------------
P R, this JIRA is just about a cosmetic change to the logging. If you are running into specific issue then please create a forum discussion here https://community.jboss.org/community/jbossas7?view=discussions with the relevant details.
> On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4042
> URL: https://issues.jboss.org/browse/AS7-4042
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Final, 7.1.2.Final (EAP)
> Reporter: Ondřej Chaloupka
> Assignee: jaikiran pai
> Priority: Minor
>
> When EJB invocations from a remote server instance is used and remoting connector of the remote server is secured and the attempt to connection fails an incorrect exception is thrown.
> In case of version 7.1.0.Final when authentication si not correctly defined then during deployment following exception is thrown:
> {code}
> ERROR [org.jboss.remoting.remote.connection] (Remoting "clientnode" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": org.jboss.msc.service.StartException in service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
> Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.createRemotingConnections(DescriptorBasedEJBClientContextService.java:124)
> at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.start(DescriptorBasedEJBClientContextService.java:86)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> ... 3 more
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:315) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
> at org.jboss.as.remoting.RemoteOutboundConnectionService.connect(RemoteOutboundConnectionService.java:130) [jboss-as-remoting-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> {code}
> which is correct. But in case that the remote server is shut down, configuration is changed to use security connection then incorrect and confusing exception is thrown:
> {code}
> ERROR [org.jboss.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component CallingBean for method public abstract java.lang.String serverclient.CallingBeanRemote.call(): javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_23]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_23]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_23]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
> at serverclient.CallingBean.call(CallingBean.java:39) [serverclient-ejb.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> ... 27 more
> Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
> at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:516) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
> at $Proxy15.sayHello(Unknown Source) at serverclient.CallingBean.call(CallingBean.java:34) [serverclient-ejb.jar:]
> ... 46 more
> {code}
> The exception seems that everything was connected correctly only module does not exist in remote context.
> In case of the AS7 Final version is not so problematic but when you take source codes from git then after deploying of application to client server which would like to connect to a secured remote server then no exception is thrown during deployment. Everything looks fine but after execution of remote call the confusing exception is thrown and it's hard to understand that the problem is in not connected context because of security.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-6334:
-----------------------------
Description:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups [OK]
clustering/infinispan - PR https://github.com/jbossas/jboss-as/pull/3971
cmp [OK]
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
ee - [OK]
ejb3 [OK]
jacorb - PR https://github.com/jbossas/jboss-as/pull/3974
jaxr [OK]
jaxrs [OK] empty subsystem
jdr - [OK] empty subsystem
jmx [OK]
jpa [OK]
jsf [OK]
jsr77 [OK] empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail PR sent https://github.com/jbossas/jboss-as/pull/3979
messaging [OK]
modcluster [OK]
naming [OK]
osgi [OK]
pojo [OK] empty subsystem
remoting - [OK]
sar [OK] empty subsystem
security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
threads [OK]
transactions [OK]
web [OK]
webservices - PR sent https://github.com/jbossas/jboss-as/pull/3979
weld [OK] empty subsystem
xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
was:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups [OK]
clustering/infinispan - PR https://github.com/jbossas/jboss-as/pull/3971
cmp [OK]
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
ee - [OK]
ejb3 [OK]
jacorb - PR https://github.com/jbossas/jboss-as/pull/3974
jaxr [OK]
jaxrs [OK] empty subsystem
jdr - [OK] empty subsystem
jmx [OK]
jpa [OK]
jsf [OK]
jsr77 [OK] empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail done - will send PR together with WS
messaging [OK]
modcluster [OK]
naming [OK]
osgi [OK]
pojo [OK] empty subsystem
remoting - [OK]
sar [OK] empty subsystem
security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
threads [OK]
transactions [OK]
web [OK]
webservices - almost done, problem with recursive discard transformation [tomaz]
weld [OK] empty subsystem
xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
> Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6334
> URL: https://issues.jboss.org/browse/AS7-6334
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.2.0.Alpha1
>
>
> Task to track the work we've all been doing on expressions/transformers.
> See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
> 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
> 2) Basic transformation testing against 7.1.2 and 7.1.3
> 3) Reject-expression testing against 7.1.2 and 7.1.3
> Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
> Please edit this description and put an OK after the subsystem name to indicate it's good to go.
> clustering/jgroups [OK]
> clustering/infinispan - PR https://github.com/jbossas/jboss-as/pull/3971
> cmp [OK]
> configadmin [OK]
> connector/datasource
> connector/jca [OK]
> connector/resource-adapter
> deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
> ee - [OK]
> ejb3 [OK]
> jacorb - PR https://github.com/jbossas/jboss-as/pull/3974
> jaxr [OK]
> jaxrs [OK] empty subsystem
> jdr - [OK] empty subsystem
> jmx [OK]
> jpa [OK]
> jsf [OK]
> jsr77 [OK] empty subsystem
> logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
> mail PR sent https://github.com/jbossas/jboss-as/pull/3979
> messaging [OK]
> modcluster [OK]
> naming [OK]
> osgi [OK]
> pojo [OK] empty subsystem
> remoting - [OK]
> sar [OK] empty subsystem
> security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
> threads [OK]
> transactions [OK]
> web [OK]
> webservices - PR sent https://github.com/jbossas/jboss-as/pull/3979
> weld [OK] empty subsystem
> xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
--
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
13 years, 4 months
[JBoss JIRA] (JGRP-1578) UNICAST: lost ACK leads to endless retransmissions
by Bela Ban (JIRA)
Bela Ban created JGRP-1578:
------------------------------
Summary: UNICAST: lost ACK leads to endless retransmissions
Key: JGRP-1578
URL: https://issues.jboss.org/browse/JGRP-1578
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.2.7, 3.3
- B sends a unicast message M to A
- A drops the ACK(M) to B
- B sends no further messages to A
--> B will keep retransmitting M to A until it gets an ACK from A, or A leaves the cluster
--> However, A will not send an ACK(M) to B, as the logic for acking only sends an ack if we did receive a message from B and it was successfully added to the retransmit table
--> However, the retransmitted M will not get added to A's table, as M has already been received
SOLUTION:
- Always ack a message frpm B with the highest delivered seqno for B's table
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6375) EJB2 CMP - Entity callbacks are not invoked according to the EJB2 spec
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/AS7-6375?page=com.atlassian.jira.plugin.s... ]
Wolf-Dieter Fink updated AS7-6375:
----------------------------------
Description: The ejbPassivate() is not called during passivation of an entity. (was: From the EJB specification the callback (un)setEntityContext() should be called if the instance change lifecycle from 'not exist' <=> 'ready'
ejbPassivate() should called if the instance change from 'ready' => 'pooled'
The behavior is current that ejbPassivate() is never called.
But (un)setEntityContext is called for changes between 'ready' and 'pooled')
> EJB2 CMP - Entity callbacks are not invoked according to the EJB2 spec
> ----------------------------------------------------------------------
>
> Key: AS7-6375
> URL: https://issues.jboss.org/browse/AS7-6375
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
>
> The ejbPassivate() is not called during passivation of an entity.
--
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
13 years, 4 months
[JBoss JIRA] (HIBERNATE-132) The license information for hibernate-jpa-2.0-api has no name, only an URL: "license.txt"
by Alix Warnke (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-132?page=com.atlassian.jira.plu... ]
Alix Warnke commented on HIBERNATE-132:
---------------------------------------
Hi, can I get a comment about this issue? It is resolved within ten minutes or so :-)
Regards A
> The license information for hibernate-jpa-2.0-api has no name, only an URL: "license.txt"
> -----------------------------------------------------------------------------------------
>
> Key: HIBERNATE-132
> URL: https://issues.jboss.org/browse/HIBERNATE-132
> Project: Hibernate Integration
> Issue Type: Feature Request
> Environment: Maven 3
> Reporter: Alix Warnke
> Assignee: Steve Ebersole
> Priority: Minor
> Labels: license
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Today in the pom-file of hibernate-jpa-2.0-api:
> <licenses> -<license> <url>license.txt</url> </license> </licenses>
> I would like it to say:
> <licenses> -<license> <name>Eclipse Public License, V 1.0</name> <url>license.txt</url> </license> </licenses>
> as this would help when using a license plugin to automatically validate against a whitelist of licenses. It is impossible for the maven plugin to know what "license.txt" is.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6432) Incorrect evaluation of system property for expression substitution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6432?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6432:
---------------------------------------
Be sure in your Utils to throw an exception if the operation "outcome" != "success". That may shed more light on why getJBossProperty() isn't producing the expected value. If you could attach test report output that would be great as well.
I don't see any setInnerExpression test but that sounds like ${outer:${inner}} or something like that and that's not supported.
> Incorrect evaluation of system property for expression substitution
> -------------------------------------------------------------------
>
> Key: AS7-6432
> URL: https://issues.jboss.org/browse/AS7-6432
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.2.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Brian Stansberry
>
> Finally I think that I've got a way how to resolve expressions on VM where container resides.
> My test case:
> https://github.com/ochaloup/jboss-as/blob/expression-substitution-run-in-...
> From this I've found issues for system property evaluation. I mean the case when System.getProperty(someName) is called.
> The application should get the evaluated value from expression but instead of it it gets the default value from expression.
> The problematic test cases are
> testSystemPropertyEvaluation - there is defined system property by calling System.setProperty and it's expected that the expression which uses this defined property will evaluate itself to the value of the System.setProperty. For the way of :resolve-expression it works fine but for getting value with System.getProperty the old default value is returned.
> setInnerExpression - it defines two levels of evaluation of expression and it seems that then the System.getProperty on the second level of evaluation does not get the evaluated/substituted value
> I hope that the test code will be more comprehensible than my explanation.
--
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
13 years, 4 months