June 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-958) CLONE -Put code subject to a security manager in privileged blocks

by Ron Sigal (JIRA)

CLONE -Put code subject to a security manager in privileged blocks ------------------------------------------------------------------ Key: JBREM-958 URL: http://jira.jboss.com/jira/browse/JBREM-958 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Critical Fix For: 2.4.0.GA To run in a the Application Server, which might be run in a security manager, Remoting code must wrap all code that needs security privileges in AccessController.doPrivileged() calls. -- 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

16 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-959) CLONE [JBREM-920] - Create build.xml target to run test suite with a Security Manager

by Ron Sigal (JIRA)

CLONE [JBREM-920] - Create build.xml target to run test suite with a Security Manager ------------------------------------------------------------------------------------- Key: JBREM-959 URL: http://jira.jboss.com/jira/browse/JBREM-959 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: David Lloyd Fix For: 2.4.0.GA >From Anil Saldana: Presuming that you have a test suite and either use ANT or Maven, I recommend an extra target to run the test suite in a Java Security Manager with minimal permissions. So for ANT, you will have an additional target. For MAVEN, you can use a profile. The idea is that you have a Java Security Policy file in which you provide unlimited permission to third party libraries and minimal permissions to your own code. This exercise is to detect critical sections of code that need special privileges and get into privileged blocks. If you have an extra target for the security manager and your test runs happen on hudson, you can detect issues with security manager as new code gets added. Please do not have one test that does System.setSecurityManager but run your entire test suite via the security manager (-Djava.security.manager -Djava.security.policy=somefile). Example: (Take a look by clicking "Configure" on the LHS) http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/ http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s... Now if your head is spinning or you do not care about security or do not have the time to do it, please tell me. I can engage myself, someone from JBoss Security Team or the QA person handling your project to add a JIRA issue (and make the build.xml/pom.xml changes for your project). Why is this important? * Because many customers run JBAS in a security manager and we need to detect issues in our own code. Also during a recent integration work with JBoss Messaging for the SOA platform, there was one issue with remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is still reeling). It took some cycles from me also. * We need to have tests running in a security manager on an ongoing basis. I understand that there are resource issues in various projects. But that does not discount the work that we need to do before we ship JBAS. ;) -- 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

16 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-960) Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect

by Galder Zamarreno (JIRA)

Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect -------------------------------------------------------------------------------------------------------- Key: JBREM-960 URL: http://jira.jboss.com/jira/browse/JBREM-960 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.4.0.GA, 2.2.2.SP8, 2.4.1.Beta Reporter: Galder Zamarreno Assigned To: Galder Zamarreno I've been struggling to set up a ServletInvoker in Remoting to be able to use the unified invoker to talk to EJB2 beans in AS/EAP 4.x. I had the Connector set up like this: <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=connector,transport=servlet" display-name="Servlet transport Connector"> <attribute name="Configuration"> <config> <invoker transport="servlet"> <attribute name="dataType" isParam="true">invocation</attribute> <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute> <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute> <attribute name="serverBindAddress">${jboss.bind.address}</attribute> <attribute name="serverBindPort">8080</attribute> <attribute name="path">unified-http-invoker/ServerInvokerServlet</attribute> </invoker> <handlers> <handler subsystem="invoker">jboss:service=invoker,type=unified-http</handler> </handlers> </config> </attribute> </mbean> But the path attribute was incorrect. Remoting was coming back with something like this: org.jboss.remoting.CannotConnectException: Can not connect http client invoker. at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:333) at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:135) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy0.create(Unknown Source) at com.acme.ejb2.slsb.TimerEnquirerHttpTest.test000(TimerEnquirerHttpTest.java:34) 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:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.StreamCorruptedException: invalid stream header at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:764) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277) at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:95) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:72) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:119) at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59) at org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:471) at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:305) ... 31 more Now, to get this Exception is very misleading. It generally means that either you have different client and server side Remoting versions, or you're using different serialization methods on either side. Once I started to dig into what Remoting was doing, I spotted HTTPClientInvoker does the following in useHttpURLConnection() method: if (sendingData) { //POST or PUT conn.setDoOutput(true); conn.setDoInput(true); conn.setRequestMethod(type); OutputStream stream = conn.getOutputStream(); if (marshaller instanceof VersionedMarshaller) ((VersionedMarshaller) marshaller).write(invocation, stream, Version.getDefaultVersion()); else marshaller.write(invocation, stream); responseCode = conn.getResponseCode(); InputStream is = (responseCode < 400) ? conn.getInputStream() : conn.getErrorStream(); Map headers = conn.getHeaderFields(); if (metadata == null) { metadata = new HashMap(); } // sometimes I get headers with "null" keys (I don't know who's fault is it), so I need // to clean the header map, unless I want to get an NPE thrown by metadata.putAll() if (headers != null) { for(Iterator i = headers.entrySet().iterator(); i.hasNext(); ) { Map.Entry e = (Map.Entry)i.next(); if (e.getKey() != null) { metadata.put(e.getKey(), e.getValue()); } } } metadata.put(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE, conn.getResponseMessage()); metadata.put(HTTPMetadataConstants.RESPONSE_CODE, new Integer(responseCode)); result = readResponse(metadata, headers, unmarshaller, is); } The Exception reported is coming from readResponse() but before that if the Servlet was not available, like in my case, conn.getResponseCode() was returning 404. Remoting code should check what the response code was, whether this is an invalid code, i.e. does not exist...etc, and throw an Exception if invalid, like in this case, giving the caller much better clue of what is going on. Thoughts? -- 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

16 years, 5 months

2
10
0 / 0

[JBoss JIRA] Created: (JBREM-973) CLONE [JBREM-970] - Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted

by Ron Sigal (JIRA)

CLONE [JBREM-970] - Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted ---------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-973 URL: http://jira.jboss.com/jira/browse/JBREM-973 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR2 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 2.4.0.GA A misspelled client-side truststore file name causes a remoting connection to fail with a misleading error message: Exception in thread "main" org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [sslsocket://192.168.67.164:3874/] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:530) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) [...] Caused by: java.net.SocketException: Socket Closed at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201) at java.net.Socket.setSoTimeout(Socket.java:997) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:2047) [...] There's nothing in the stacktrace hinting towards the root cause of the problem, and this could make the debugging quite laborious and time consuming. A welcome improvement would be to identify and loudly advertise the root cause of the problem (or at least problems related to the fact that the SSL handshake did not succeed) -- 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

16 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-972) CLONE [JBREM-971] - Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded

by Ron Sigal (JIRA)

CLONE [JBREM-971] - Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded ----------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-972 URL: http://jira.jboss.com/jira/browse/JBREM-972 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR2 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 2.4.0.GA A SSL connection (for example) may fail due to handshake problems, but Remoting would discard the original exception and throw a different and less relevant exception, thus hiding the original cause of the error. Example: The server reports Caused by: java.net.SocketException: Socket Closed at java.net.PlainSocketImpl.setOption(Unknown Source) at java.net.Socket.setSoTimeout(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(Unknown Source) at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85) at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:168) at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66) while in fact the root problem is: 14:39:38,174 ERROR [STDERR] javax.net.ssl.SSLException: Received fatal alert: internal_error 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) 14:39:38,175 ERROR [STDERR] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) This makes troubleshooting of a potential simple problem such a misspelled truststore file name laborious and time consuming. The server-side code could be modified to log relevant exceptions. -- 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

16 years, 5 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBREM-677) Compression marshalling fails intermittently.

by Jay Howell (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-677?page=comments#action_12417065 ] Jay Howell commented on JBREM-677: ---------------------------------- Looks like this issue may be that jboss serialization 1.0.3 is just broken and may not have anything to do with the compression marshaller. I've linked the other jiras that center around this problem. > Compression marshalling fails intermittently. > --------------------------------------------- > > Key: JBREM-677 > URL: http://jira.jboss.com/jira/browse/JBREM-677 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.CR1 (Pinto) > > > When used with EJB's, CompressingUnMarshaller intermittently throws java.io.IOException: Not in GZIP format. -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-965) Fix PortUtil.getRandomStartingPort()

by Ron Sigal (JIRA)

Fix PortUtil.getRandomStartingPort() ------------------------------------ Key: JBREM-965 URL: http://jira.jboss.com/jira/browse/JBREM-965 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 >From support case 176016: Description: While starting JBoss using the "all" configuration we get the following error message: "Problem starting service jboss.messaging:service=Connector,transport=bisocket". Followed in the stack trace by the error: "Caused by: java.lang.NumberFormatException: For input string: "add46e5e"". The JBoss messaging service does not start which prevents other JBoss services from being deployed. Walking through the following stack trace: 2008-04-16 09:29:46,160 WARN [org.jboss.system.ServiceController] Problem starting service jboss.messaging:service=Connector,transport=bisocket java.lang.ExceptionInInitializerError at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start(BisocketS erverInvoker.java:182) at org.jboss.remoting.transport.Connector.start(Connector.java:322) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:995) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.jav a:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOp erationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScann er.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner .java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan (AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstrac tDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport .java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSup port.java:245) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.jav a:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOp erationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:533) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:399) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Thread.java:602) Caused by: java.lang.NumberFormatException: For input string: "add46e5e" at java.lang.Throwable.<init>(Throwable.java:196) at java.lang.Exception.<init>(Exception.java:41) at java.lang.RuntimeException.<init>(RuntimeException.java:43) at java.lang.IllegalArgumentException.<init>(IllegalArgumentException.ja va:36) at java.lang.NumberFormatException.<init>(NumberFormatException.java:38) at java.lang.NumberFormatException.forInputString(NumberFormatException.java:4 8) at java.lang.Integer.parseInt(Integer.java:459) at org.jboss.remoting.transport.PortUtil.getRandomStartingPort(PortUtil.java:1 47) at org.jboss.remoting.transport.PortUtil.<clinit>(PortUtil.java:49) Gets us to the method "getRandomStartingPort" in the class "PortUtil" in the package "org.jboss.remoting.transport". Which is part of the "jboss-remoting.jar" in the directory jboss430/thirdparty/jboss/remoting/lib. The existing code that is failing is: public static int getRandomStartingPort() { Object o = new Object(); String os = o.toString(); os = os.substring(17); int n = Integer.parseInt(os, 16); int p = Math.abs(new SecureRandom(String.valueOf(System.currentTimeMillis() + n).getBytes()).nextInt(2000)) + 2000; return p; } The issue with this code is that, what an object returns for toString() is platform- and JVM-specific and never guaranteed to be parseable as an integer. There's also no guarantee that toString() will produce anything that's at least 17 characters long. The only time the output of toString() is defined is for instances of java.lang.Object; pretty much all classes override that method. Besides the hard-coding of the 17 in the code is rather naive, converting the hex string suffers from the fact that it may be representing a negative number. The parseInt() method allows only 31 bits of magnitude for the string, since the sign must be given externally (leading '+' or '-', with '+' being the default). In many JVM implementations, the hashCode() method for non-String objects returns a value based on the allocation address of the object. For 32-bit systems, such an address is almost always under the 2 GB boundary, and therefore positive. For architectures that use more than 32 bits for an address (including the Unisys OS 2200), there's no guarantee of any particular sign of the result. We propose that the code be changed to the following: public static int getRandomStartingPort() { int n = new Object().hashCode(); int p = Math.abs(new SecureRandom(String.valueOf(System.currentTimeMillis() + n).getBytes()).nextInt(2000)) + 2000; return p; } -- 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

16 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-997) CLONE [JBREM-970] - Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted

by Ron Sigal (JIRA)

CLONE [JBREM-970] - Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted ---------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-997 URL: http://jira.jboss.com/jira/browse/JBREM-997 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR2 (Pinto) Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 2.4.0.GA (Pinto) A misspelled client-side truststore file name causes a remoting connection to fail with a misleading error message: Exception in thread "main" org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [sslsocket://192.168.67.164:3874/] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:530) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) [...] Caused by: java.net.SocketException: Socket Closed at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201) at java.net.Socket.setSoTimeout(Socket.java:997) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:2047) [...] There's nothing in the stacktrace hinting towards the root cause of the problem, and this could make the debugging quite laborious and time consuming. A welcome improvement would be to identify and loudly advertise the root cause of the problem (or at least problems related to the fact that the SSL handshake did not succeed) -- 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

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-996) CLONE [JBREM-971] - Enhance server-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded

by Ron Sigal (JIRA)

CLONE [JBREM-971] - Enhance server-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded ----------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-996 URL: http://jira.jboss.com/jira/browse/JBREM-996 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR2 (Pinto) Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 2.4.0.GA (Pinto) A SSL connection (for example) may fail due to handshake problems, but Remoting would discard the original exception and throw a different and less relevant exception, thus hiding the original cause of the error. Example: The server reports Caused by: java.net.SocketException: Socket Closed at java.net.PlainSocketImpl.setOption(Unknown Source) at java.net.Socket.setSoTimeout(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(Unknown Source) at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85) at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:168) at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66) while in fact the root problem is: 14:39:38,174 ERROR [STDERR] javax.net.ssl.SSLException: Received fatal alert: internal_error 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623) 14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) 14:39:38,175 ERROR [STDERR] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) This makes troubleshooting of a potential simple problem such a misspelled truststore file name laborious and time consuming. The server-side code could be modified to log relevant exceptions. -- 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

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBREM-834) Remoting 3 Transaction API/Interceptor

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-834?page=all ] David Lloyd closed JBREM-834. ----------------------------- Fix Version/s: (was: 3.0.0-M3) Resolution: Rejected This issue is better handled by existing aspects at this point. Can review later. > Remoting 3 Transaction API/Interceptor > -------------------------------------- > > Key: JBREM-834 > URL: http://jira.jboss.com/jira/browse/JBREM-834 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > -- 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

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues June 2008