[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Setting up JBoss Messaging integration tests
by rachmatowicz＠jboss.com
Tim, Ovidiu
Thank you for your very helpful comments and help in getting me started on this task!
Some replies:
1. Making use of release-admin.xml directly makes sense from the point of view of centralizing the code to create configurations. However, at present, we are pulling only pulling in jboss-messaging.jar into testsuite/thirdparty from repository.jboss.com, and don't have direct access to release-admin.xml. We are looking for a way to set up the configuration which makes life easy as well as being well-suited to the existing testsuite organization.
2. The JBAS build and testsuite makes use of a number of names for directories relating to JMS and the existing JBossMQ implementation:
trunk/messaging
trunk/testsuite/src/main/jms
trunk/testsuite/src/main/jmsra
trunk/testsuite/src/main/jbossmq
trunk/tetstsuite/src/resources/messaging
trunk/testsuite/src/resources/jbossmq
In incorporating these new Messaging tests, I tentatively chose the name messaging5 to be used as a basis for naming directories, files, and other related things.
trunk/testsuite/src/main/messaging5
trunk/testsuite/src/resources/messaging5
....
This would allow me to keep all the new Messaging artifacts separate from the existing JBossMQ and JMS atrifacts, as you suggested.
Is this name acceptable? Would another base name be preferable?
Richard
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968429#3968429
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968429
18 years
[Design of EJB 3.0] - Re: Specifying Default Client Binding
by ALRubinger
My Use Case:
* Obtain, Build JBoss AS from Branch_4_0.
* In build/output/jboss-4.0.5.CR1-ejb3/server/default/conf/jboss-service.xml:
<mbean code="org.jboss.services.binding.ServiceBindingManager"
| name="jboss.system:service=ServiceBindingManager">
| <attribute name="ServerName">ports-01</attribute>
| <attribute name="StoreURL">${jboss.server.home.url}/conf/service-bindings.xml</attribute>
| <attribute name="StoreFactoryClassName">
| org.jboss.services.binding.XMLServicesStoreFactory
| </attribute>
| </mbean>
* Copy the default service bindings example file to default/conf, renaming to "service-bindings.xml" Under the "ports-01" section is:
<!-- EJB3 Remoting Connector ejb3.deployer/META-INF/jboss-service.xml -->
|
| <service-config name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3"
| delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
| <delegate-config>
| <attribute name="InvokerLocator">socket://${jboss.bind.address}:3973</attribute>
| </delegate-config>
| <binding port="3973"/>
| </service-config>
* Copy a simple EJB3 Service Bean to default/deploy.
* Set breakpoint in org.jboss.ejb3.service.ServiceRemoteProxyFactory.setRemoteBinding
* Run the server
* At breakpoint stop, binding.bindUrl evaluates to socket://0.0.0.0:3873, whereas we've specified 3973 in the service binding plugin.
* Run client to contact the EJB3 Service Bean.
* Exception after timeout:
| 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:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:78)
| 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:31)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at 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(PlainSocketImpl.java:333)
| at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
| at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
| at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
| at java.net.Socket.connect(Socket.java:516)
| at java.net.Socket.connect(Socket.java:466)
| at java.net.Socket.<init>(Socket.java:366)
| at java.net.Socket.<init>(Socket.java:179)
| 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
|
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968428#3968428
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968428
18 years
[Design of Security on JBoss] - Re: JBoss Security Service Provider Interface Extension
by anil.saldhana＠jboss.com
I have been wondering about the following for the SPI:
Security Caching and a mechanism to flush it.
Previously, the Security Caches were injected into the Security Manager via the JMX wrapper service and flush when needed was an aspect of the service.
Since caching is a necessity and information can change in the background in the sources (like db, ldap etc), I was wondering about providing a formal mechanism by which data that gets updated in the source will trigger a flush of the cache. (SPML is a good choice and we do have access to OpenSPML for integration)
This formal mechanism can be a JMX service that acts as the door to the information update (Currently I can see JBossPortal/Seam etc being the major users of this). I use the mechanism to update the roles in the Database, the mechanism updates the info in the DB while sending a flush to the Security Cache.
Making this mechanism generic for usage is a challenge.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968422#3968422
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968422
18 years