[JBoss JIRA] (JGRP-1726) Bundler: send message batch of 1 as single message
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1726?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1726.
----------------------------
Resolution: Done
> Bundler: send message batch of 1 as single message
> --------------------------------------------------
>
> Key: JGRP-1726
> URL: https://issues.jboss.org/browse/JGRP-1726
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When the TransferQueueBundler ("new" / default) sends bundled messages, if there is only a single message in the list, the message is still sent as a *batch* (of 1).
> Currently, parsing of single messages is done in a separate thread (JGRP-1716) whereas parsing of message batches is done in the thread which received the messages from the socket.
> If we therefore send a batch of 1 as a single message, we might get better perf (to be verified).
--
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
10 years, 6 months
[JBoss JIRA] (WFLY-2368) env-entry is not injected with @Resource annotation into CDI beans and JAX-RS resources
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2368?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2368:
--------------------------------------
I think this should be resolved, can you re-test against upstream?
> env-entry is not injected with @Resource annotation into CDI beans and JAX-RS resources
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2368
> URL: https://issues.jboss.org/browse/WFLY-2368
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.Beta1
> Reporter: Dmytro Zemnytskiy
> Assignee: Stuart Douglas
>
> I built simple web application to narrow down problem, consisting of war packaged in ear. It attempts to inject env-entry declared in web.xml using @Resource annotation into servlet, jax-rs resource and cdi managed bean.
> For now only servlet is injected with env-entry properly. JAX-RS resource requires @ManagedBean annotation in order to work, but still does not work if it is listed explicitly in its Application, rather than autoscanned. CDI bean does not work yet. Same app without modifications work properly in Jboss AS 7.1
> Below is example of CDI bean :
> @Named
> public class EnvEntryProducer {
> @Resource(name="demo") String env;
>
> @PostConstruct void logMe() {
> System.out.print("Env: " + env);
> }
>
> @Produces @Named("enventry") String getEnv() {
> return env;
> }
> }
> PostConstruct is not called yet as well
--
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
10 years, 6 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 reassigned WFLY-803:
-----------------------------------
Assignee: David Lloyd (was: Stuart Douglas)
> "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: David Lloyd
> 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
10 years, 6 months
[JBoss JIRA] (WFLY-875) Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-875?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved WFLY-875.
---------------------------------
Resolution: Out of Date
I fixed this a while ago.
> Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-875
> URL: https://issues.jboss.org/browse/WFLY-875
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: JBoss 7.1.1
> Reporter: Sławomir Wojtasiak
> Assignee: Stuart Douglas
> Labels: rhq
> Attachments: jboss-as-helloworld-singleton.war
>
>
> Singletons don't respect any transaction attributes for their @PostConstruct methods and invokes them always with REQUIRED_NEW semantics. Following part of code is responsible for hardcoding these values for registered _SingletonLifecycleCMTTxInterceptor_ factories:
> {code:title=org.jboss.as.ejb3.component.singleton.SingletonComponentDescription.java|borderStyle=solid}
> @Override
> public void configure(final DeploymentPhaseContext context, final ComponentDescription description, final ComponentConfiguration configuration) throws DeploymentUnitProcessingException {
> configuration.addPostConstructInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPostConstruct.TRANSACTION_INTERCEPTOR);
> configuration.addPreDestroyInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPreDestroy.TRANSACTION_INTERCEPTOR);
> if(description.isPassivationApplicable()) {
> configuration.addPrePassivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> configuration.addPostActivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> }
> configuration.addTimeoutViewInterceptor(TimerCMTTxInterceptor.FACTORY, InterceptorOrder.View.CMT_TRANSACTION_INTERCEPTOR);
> }
> {code}
> EJB 3.1 specification says, REQUIRED, REQUIRED_NEW and NOT_SUPPORTED attributes should be supported, where in case of REQUIRED a semantic of REQUIRED_NEW trancation attribute should be used:
> {panel:title=4.8.3 Transaction Semantics of Initialization and Destruction| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
> PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional. From the bean developer’s view there is no client of a PostConstruct or PreDestroy method.
> A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
> _Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted._
> {panel}
> So there is not a problem with REQUIRED and REQUIRED_NEW transaction attributes, but NOT_SUPPORTED attribute is just not supported :)
--
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
10 years, 6 months
[JBoss JIRA] (WFLY-863) On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-863?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reassigned WFLY-863:
-----------------------------------
Assignee: David Lloyd (was: Stuart Douglas)
> On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-863
> URL: https://issues.jboss.org/browse/WFLY-863
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Ondřej Chaloupka
> Assignee: David Lloyd
> 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
10 years, 6 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 reassigned WFLY-972:
-----------------------------------
Assignee: Cheng Fang (was: Stuart Douglas)
> 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: Cheng Fang
>
> 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
10 years, 6 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reassigned WFLY-959:
-----------------------------------
Assignee: David Lloyd (was: Stuart Douglas)
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-959
> URL: https://issues.jboss.org/browse/WFLY-959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
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
10 years, 6 months