[JBoss JIRA] Created: (JBREM-962) Remote classloading does not work with Isolated EARs
by Magesh Kumar B (JIRA)
Remote classloading does not work with Isolated EARs
----------------------------------------------------
Key: JBREM-962
URL: http://jira.jboss.com/jira/browse/JBREM-962
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Environment: EAP4.3
Reporter: Magesh Kumar B
When user has enabled isolation in a ear file containing an EJB3 jar file, the implementation classes are not serialized and a ClassNotFoundException is thrown. I have attached a sample called HelloEJB3.zip that contains all files needed for deploying this test case. Using EAP4.3 do "ant deploy" and then do "ant test".
When the jboss-app.xml is removed the application client works fine. This fails in the isolated mode with the below exception:
Caused by: java.lang.ClassNotFoundException: org.jboss.ejb3.user.UserImpl
at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:82)
at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:76)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:174)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
at java.io.ObjectInputStream.readExternalData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:239)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:919)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:613)
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.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
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:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
--
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
[JBoss JIRA] Created: (JBREM-954) InterruptException should not be rethrown as CannotConnectionException
by Galder Zamarreno (JIRA)
InterruptException should not be rethrown as CannotConnectionException
----------------------------------------------------------------------
Key: JBREM-954
URL: http://jira.jboss.com/jira/browse/JBREM-954
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Reporter: Galder Zamarreno
Fix For: 2.2.2.SP4
Let's say you have a Swing GUI application that calls an EJB remotely and the
client code is waiting to get entry to client side pool (controlled by clientMaxPoolSize).
While waiting, the user decides to cancel the operation by interrupting the thread. In
that case, the Remoting code does not make a difference between an InterruptedException
and any other Exception:
MicroSocketClientInvoker.java:
protected SocketWrapper getConnection(Marshaller marshaller,
UnMarshaller unmarshaller,
int timeAllowed)
throws Exception
{
long start = System.currentTimeMillis();
long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000;
boolean timedout = !semaphore.attempt(timeToWait);
Any Exception thrown from getConnection() is treated as a CannotConnectException
try
{
socketWrapper = getConnection(marshaller, unmarshaller, timeLeft);
}
catch (Exception e)
{
// if (bailOut)
// return null;
semaphore.release();
if (trace) log.trace(this + " released semaphore: " + semaphore.permits());
throw new CannotConnectException(
"Can not get connection to server. Problem establishing " +
"socket connection for " + locator, e);
}
The EJB3 layer wraps this in CannotConnectException in a RuntimeException like:
throw new RuntimeException("cluster invocation failed, last exception was: ", lastException);
This is misleading on the Remoting side. Semantically, the fact that the thread attempting
to connect is interrupted shouldn't be translated into a CannotConnectException.
Please find attached a test case I've created.
--
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
[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
[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
[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
[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
[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