[JBoss JIRA] Closed: (EJBTHREE-629) default remote binding not read for @Service beans
by Bill Burke (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-629?page=all ]
Bill Burke closed EJBTHREE-629.
-------------------------------
Resolution: Done
> default remote binding not read for @Service beans
> --------------------------------------------------
>
> Key: EJBTHREE-629
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-629
> Project: EJB 3.0
> Issue Type: Task
> Affects Versions: EJB 3.0 RC8 - FD
> Reporter: Andrea Luciano
> Assigned To: Bill Burke
> Fix For: EJB 3.0 RC9 - FD, EJB 3.0 RC2
>
>
> The issue http://jira.jboss.com/jira/browse/EJBTHREE-204 reopen.
> I downloaded jboss 4.0.4 GA and jboss-EJB-3.0_RC8-FD.
> I installed jboss and ejb3 support than I tryed to modify the standard port 3873 so I changed the file deploy/ejb3.deployer/META-INF/jboss-service.xml:
> <mbean code="org.jboss.remoting.transport.Connector"
> xmbean-dd="org/jboss/remoting/transport/Connector.xml"
> name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
> <depends>jboss.aop:service=AspectDeployer</depends>
> <attribute name="InvokerLocator">socket://${jboss.bind.address}:10009</attribute>
> <attribute name="Configuration">
> <handlers>
> <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
> </handlers>
> </attribute>
> </mbean>
> While the server listens correctly on new port the client has no way to contact the bean I deployed.
> Using strace I figured out that the client ignores the new port and tries to contact port 3873 as before RC3 of ejb3 support (while another installation with ejb3 rc3 works without problems).
> Is this a regression?
> Regards.
> Andrea
--
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
19 years, 10 months
[JBoss JIRA] Deleted: (EJBTHREE-673) Cannot change default InvokerLocator port for EJB3 Deployer
by Bill Burke (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-673?page=all ]
Bill Burke deleted EJBTHREE-673:
--------------------------------
> Cannot change default InvokerLocator port for EJB3 Deployer
> -----------------------------------------------------------
>
> Key: EJBTHREE-673
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-673
> Project: EJB 3.0
> Issue Type: Bug
> Environment: JBoss 4.0.4-GA w/ EJB3 Profile as installed by JNLP Installer. Properties Service Plugin and Binding Service Plugin added manually after initial install (as they were not included in the EJB3 profile). Windows XP Professional, Service Pack 2.
> Reporter: Andrew Rubinger
>
> Default InvokerLocator port for EJB3 cannot be changed/found correctly when using JBoss Binding Service Plugin.
> Use Case:
> Given two server instances, A and B. The binding service plugin is being used with all defaults from "sample-bindings.xml" as obtained from $JBOSS_HOME/docs/examples/binding-manager.
> Server Instance A is configured to use ServerName "ports-default" in the bindings.
> Server Instance B is configured to use ServerName "ports-01" in the bindings.
> Instances deploy on the same machine simultaneously.
> With both instances running, EJB3 archive is deployed into Server Instance B. Remote client obtains a stub properly, but once invoking a method on this stub, receives a NotFoundInDispatcherException:
> java.lang.reflect.UndeclaredThrowableException
> at $Proxy0.encrypt(Unknown Source)
> at com.ninem.rx.api.encryption.EncryptionDelegate.encrypt(EncryptionDelegate.java:54)
> at com.ninem.rx.api.encryption.EncryptionDelegateTests.testRoundtripEncryption(EncryptionDelegateTests.java:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:164)
> at junit.framework.TestCase.runBare(TestCase.java:130)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:120)
> at junit.framework.TestSuite.runTest(TestSuite.java:228)
> at junit.framework.TestSuite.run(TestSuite.java:223)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: org.jboss.aop.NotFoundInDispatcherException: Object with oid: jboss.j2ee:jar=rx_service-encryption.ejb3,name=EncryptionServiceBean,service=EJB3 was not found in the Dispatcher
> at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:85)
> at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190)
> at org.jboss.remoting.Client.invoke(Client.java:525)
> at org.jboss.remoting.Client.invoke(Client.java:488)
> at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.service.ServiceRemoteProxy.invoke(ServiceRemoteProxy.java:92)
> ... 18 more
> Instance A is shut down.
> Same remote client runs same execution process. EJB3 stub again obtained without error, but upon invoking a method on the stub, receives a org.jboss.remoting.CannotConnectException:
> org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection.
> at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:267)
> at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> at org.jboss.remoting.Client.invoke(Client.java:525)
> at org.jboss.remoting.Client.invoke(Client.java:488)
> at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.service.ServiceRemoteProxy.invoke(ServiceRemoteProxy.java:92)
> at $Proxy0.encrypt(Unknown Source)
> at com.ninem.rx.api.encryption.EncryptionDelegate.encrypt(EncryptionDelegate.java:54)
> at com.ninem.rx.api.encryption.EncryptionDelegateTests.testRoundtripEncryption(EncryptionDelegateTests.java:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:164)
> at junit.framework.TestCase.runBare(TestCase.java:130)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:120)
> at junit.framework.TestSuite.runTest(TestSuite.java:228)
> at junit.framework.TestSuite.run(TestSuite.java:223)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at java.net.Socket.<init>(Unknown Source)
> at java.net.Socket.<init>(Unknown Source)
> at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:535)
> at org.jboss.remoting.transport.socket.SocketClientInvoker.getConnection(SocketClientInvoker.java:471)
> at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:263)
> ... 30 more
--
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
19 years, 10 months
[JBoss JIRA] Updated: (EJBTHREE-629) default remote binding not read for @Service beans
by Bill Burke (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-629?page=all ]
Bill Burke updated EJBTHREE-629:
--------------------------------
Summary: default remote binding not read for @Service beans (was: need to get remote binding uri from Connector for default)
> default remote binding not read for @Service beans
> --------------------------------------------------
>
> Key: EJBTHREE-629
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-629
> Project: EJB 3.0
> Issue Type: Task
> Affects Versions: EJB 3.0 RC8 - FD
> Reporter: Andrea Luciano
> Assigned To: Bill Burke
> Fix For: EJB 3.0 RC2, EJB 3.0 RC9 - FD
>
>
> The issue http://jira.jboss.com/jira/browse/EJBTHREE-204 reopen.
> I downloaded jboss 4.0.4 GA and jboss-EJB-3.0_RC8-FD.
> I installed jboss and ejb3 support than I tryed to modify the standard port 3873 so I changed the file deploy/ejb3.deployer/META-INF/jboss-service.xml:
> <mbean code="org.jboss.remoting.transport.Connector"
> xmbean-dd="org/jboss/remoting/transport/Connector.xml"
> name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
> <depends>jboss.aop:service=AspectDeployer</depends>
> <attribute name="InvokerLocator">socket://${jboss.bind.address}:10009</attribute>
> <attribute name="Configuration">
> <handlers>
> <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
> </handlers>
> </attribute>
> </mbean>
> While the server listens correctly on new port the client has no way to contact the bean I deployed.
> Using strace I figured out that the client ignores the new port and tries to contact port 3873 as before RC3 of ejb3 support (while another installation with ejb3 rc3 works without problems).
> Is this a regression?
> Regards.
> Andrea
--
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
19 years, 10 months
[JBoss JIRA] Updated: (JBPM-315) SchedulerMain can not work
by Daniel Bloomfield Ramagem (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-315?page=all ]
Daniel Bloomfield Ramagem updated JBPM-315:
-------------------------------------------
Attachment: SchedulerMain.java
The scheduler should be started first before adding the LogListener (see my comment).
> SchedulerMain can not work
> --------------------------
>
> Key: JBPM-315
> URL: http://jira.jboss.com/jira/browse/JBPM-315
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Reporter: Bernd Ruecker
> Assigned To: Tom Baeyens
> Priority: Minor
> Attachments: SchedulerMain.java
>
> Original Estimate: 5 minutes
> Remaining Estimate: 5 minutes
>
> SchedulerMain.main throws NullPointerException at line 29
> I think the order of the two lines are wrong:
> // register the console listener
> scheduler.getSchedulerThread().addListener(new LogListener());
>
> // start the scheduler
> scheduler.start();
--
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
19 years, 10 months
[JBoss JIRA] Commented: (JBPM-315) SchedulerMain can not work
by Daniel Ramagem (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-315?page=comments#action_12342518 ]
Daniel Ramagem commented on JBPM-315:
-------------------------------------
I just started learning and using jBPM two days ago and bumped into this issue. I have the "jbpm-starters-kit-3.1.2". The problem is that the Scheduler only has the schedulerThread attribute set in the start() method. Therefore the "scheduler.getSchedulerThread()" will return null. My fix was to simply invert the order of the lines. Start the scheduler first and then add the LogListener.
> SchedulerMain can not work
> --------------------------
>
> Key: JBPM-315
> URL: http://jira.jboss.com/jira/browse/JBPM-315
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Reporter: Bernd Ruecker
> Assigned To: Tom Baeyens
> Priority: Minor
> Original Estimate: 5 minutes
> Remaining Estimate: 5 minutes
>
> SchedulerMain.main throws NullPointerException at line 29
> I think the order of the two lines are wrong:
> // register the console listener
> scheduler.getSchedulerThread().addListener(new LogListener());
>
> // start the scheduler
> scheduler.start();
--
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
19 years, 10 months
[JBoss JIRA] Commented: (JBMESSAGING-410) java:/JmsXA in no-tx context does not work the same way as JBossMQ
by Clebert Suconic (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=comments#action_12... ]
Clebert Suconic commented on JBMESSAGING-410:
---------------------------------------------
send your comments to http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968696#3968696
(this is the correct link now)
> java:/JmsXA in no-tx context does not work the same way as JBossMQ
> ------------------------------------------------------------------
>
> Key: JBMESSAGING-410
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410
> Project: JBoss Messaging
> Issue Type: Bug
> Components: Configuration and Management
> Affects Versions: 1.0.1.CR2
> Reporter: Elias Ross
> Assigned To: Clebert Suconic
> Fix For: 1.0.1.CR5
>
>
> The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory.
> Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility.
> The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced.
> QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA");
> ...
> QueueConnection queueConnection = queueCF.createQueueConnection();
> QueueSession queueSession =
> queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
> QueueSender queueSender = queueSession.createSender(queue);
> ObjectMessage om = queueSession.createObjectMessage();
> queueSender.send(om);
> queueSender.close();
> queueSession.close();
> queueConnection.close();
--
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
19 years, 10 months
[JBoss JIRA] Updated: (JBMESSAGING-410) java:/JmsXA in no-tx context does not work the same way as JBossMQ
by Clebert Suconic (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ]
Clebert Suconic updated JBMESSAGING-410:
----------------------------------------
Comment: was deleted
> java:/JmsXA in no-tx context does not work the same way as JBossMQ
> ------------------------------------------------------------------
>
> Key: JBMESSAGING-410
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410
> Project: JBoss Messaging
> Issue Type: Bug
> Components: Configuration and Management
> Affects Versions: 1.0.1.CR2
> Reporter: Elias Ross
> Assigned To: Clebert Suconic
> Fix For: 1.0.1.CR5
>
>
> The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory.
> Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility.
> The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced.
> QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA");
> ...
> QueueConnection queueConnection = queueCF.createQueueConnection();
> QueueSession queueSession =
> queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
> QueueSender queueSender = queueSession.createSender(queue);
> ObjectMessage om = queueSession.createObjectMessage();
> queueSender.send(om);
> queueSender.close();
> queueSession.close();
> queueConnection.close();
--
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
19 years, 10 months