August 2006 - jboss-dev-forums - Jboss List Archives

[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, 4 months

1
0
0 / 0

[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:  | | <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, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityContext

by anil.saldhana＠jboss.com

"scott.stark(a)jboss.org" wrote : | We need to workout the trust usecase workflows to define the spi. I don't think its best embeded in the authentication call, but I"m not sure. How would 196 deal with a saml identity assertion? | JSR-196 does not handle it now explicitly. There is support via: a) Access to the Http Request (means access to the SAML Token). The server runtime can do back-door communication via SOAP with a Identity Server for the additional attributes associated with the saml identity. b) Server Runtime can hold state such that there is back and forth communication with the client runtime. Similar to the SPNEGO requirements. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968424#3968424 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968424

18 years, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityContext

by scott.stark＠jboss.org

Both the context data(such as roles) and authorization manager should be a function of the security domain. We need to workout the trust usecase workflows to define the spi. I don't think its best embeded in the authentication call, but I"m not sure. How would 196 deal with a saml identity assertion? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968418#3968418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968418

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Specifying Default Client Binding

by bill.burke＠jboss.com

I cannot reproduce this problem View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968414#3968414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968414

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Specifying Default Client Binding

by ALRubinger

Also, I'm working out of SVN JBoss AS Branch 4.0 - not entirely sure that's correct, but it seemed logical. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968408#3968408 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968408

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Specifying Default Client Binding

by ALRubinger

If I'm understanding correctly what I need to do, modifying the existing one to get overridden values from the Service Bindings Plugin such that the Invoker Locator returned from the ProxyDeployer has client bindings other than the default. I think. I'm new at the "patching JBoss" game. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968407#3968407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968407

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Specifying Default Client Binding

by bill.burke＠jboss.com

You are creating a new connector? Or just modifying the one in ejb3.deployer/META-INF/jboss-service.xml? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968404#3968404 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968404

18 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: String size limitations with TreeCacheMarshaller

by clebert.suconic＠jboss.com

It will send something like this: <ObjectID(integer)><Short|Integer>.... It's very similar to ObjectOutputStream from Java Serialization. If you want to save 4 bytes from ObjectID you could use StringUtil directly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968401#3968401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968401

18 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2006