August 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1019) RemotingClassLoader needs option to delegate to user class loader before parent

by Scott M Stark (JIRA)

RemotingClassLoader needs option to delegate to user class loader before parent ------------------------------------------------------------------------------- Key: JBREM-1019 URL: https://jira.jboss.org/jira/browse/JBREM-1019 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.GA (Pinto) Reporter: Scott M Stark For the jbossas5 app client container, a class loader policy that loads from the child first is used to pickup the client jar manifest references. If such a class loader is registered as the user class loader with the RemotingClassLoader, its not going be delegated to first. This results in duplicate and conflicting classes being loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1000) CLONE [JBREM-962] - Remote classloading does not work with Isolated EARs

by Ron Sigal (JIRA)

CLONE [JBREM-962] - Remote classloading does not work with Isolated EARs ------------------------------------------------------------------------ Key: JBREM-1000 URL: http://jira.jboss.com/jira/browse/JBREM-1000 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 Assigned To: Ron Sigal Fix For: 2.2.2.SP8 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

15 years, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1023) Dynamic marshalling fails with JBossSerialization

by Ron Sigal (JIRA)

Dynamic marshalling fails with JBossSerialization ------------------------------------------------- Key: JBREM-1023 URL: https://jira.jboss.org/jira/browse/JBREM-1023 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.GA (Pinto) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.4.0.SP1 org.jboss.remoting.marshal.MarshallerLoaderClient.getMarshaller() uses org.jboss.remoting.marshal.serializable.SerializableMarshaller and SerializableUnMarshaller, but it doesn't check the loader InvokerLocator for serializationtype. If the orginal InvokerLocator has "serializationtype=jboss", the attempt to download a marshaller will fail. Similarly, MarshallerLoaderClient should check for serializationtype. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBREM-302) remote dynamic marshall loading not working on linux

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-302?page=com.atlassian.jira.plug... ] Ron Sigal closed JBREM-302. --------------------------- Resolution: Done It appears that the problem lies in the fact when that org.jboss.jrunit.harness.TestDriver.executeRemoteTest() creates a command line to execute org.jboss.jrunit.harness.ServerTestHarness, it puts double quotes around the class path. For some reason, the quotes are included in the class path URLs maintained by URLClassLoader, in particular, the first and last URLs, and since jboss-remoting-loading-tests.jar, which holds the server side classes excluded from jboss-remoting-tests.jar is the first jar in the classpath, URLClassLoader is unable to find it. It seems likely that the problem is in the linux implementation of java.lang.Runtime().exec() rather than in URLClassLoader itself. The solution is to change TestDriver so that it doesn't add quotes. A new version of jrunit.jar, derived from the tag remoting_binary_081008, has been placed in the lib/jboss directory. The tests.marshall target in build.xml has been activated for linux, and the remote marshalling tests are passing in hudson. > remote dynamic marshall loading not working on linux > ---------------------------------------------------- > > Key: JBREM-302 > URL: https://jira.jboss.org/jira/browse/JBREM-302 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: marshall > Affects Versions: 1.4.0 beta > Environment: Linux, JDK 1.4 > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.4.0.SP1 > > Attachments: SocketMarshallerLoadingTestCase-out.txt > > > The following test cases fail on Linux (and not on Windows): > org.jboss.test.remoting.marshall.dynamic.remote.http.HTTPMarshallerLoadingTestCase > org.jboss.test.remoting.marshall.dynamic.remote.socket.SocketMarshallerLoadingTestCase > Test output for SocketMarshallerLoadingTestCase attached, but says that server can not find the class: > org.jboss.test.remoting.marshall.dynamic.remote.socket.TestObject > However, confirmed that this class is within the jboss-remoting-loading-tests.jar, which is being set on the classpath (as shown in the output log). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1006) SOA MTOM bug points to bug in Remoting codebase

by Julian Coleman (JIRA)

SOA MTOM bug points to bug in Remoting codebase ----------------------------------------------- Key: JBREM-1006 URL: http://jira.jboss.com/jira/browse/JBREM-1006 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Environment: SOA 4.3.0 CP02 CR3 Reporter: Julian Coleman Priority: Minor SOA-568 and JBESB-1803 point to a potential bug in the HttpUnmarshaller code shipped with EAP 4.3.0 CP01. -- 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

15 years, 9 months

2
4
0 / 0

[JBoss JIRA] Commented: (JBREM-802) TransporterHandler should not use Class.forName

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-802?page=com.atlassian.jira.plug... ] David Lloyd commented on JBREM-802: ----------------------------------- Actually this is probably better done as: classSig[x] = Class.forName(sig[x], true, targetPOJO.getClass().getClassLoader()); (if that is in fact the proper classloader to use) > TransporterHandler should not use Class.forName > ----------------------------------------------- > > Key: JBREM-802 > URL: https://jira.jboss.org/jira/browse/JBREM-802 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transporter > Affects Versions: 2.2.2.GA, 2.4.0.Beta1 (Pinto) > Reporter: Julien Viet > Fix For: 2.4.1.Beta > > > line: > classSig[x] = Class.forName(sig[x]); > should probably be replaced by > classSig[x] = targetPOJO.getClass().getClassLoader().loadClass(sig[x]); > to provide a correct class lookup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-302) remote dynamic marshall loading not working on linux

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-302?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-302: ---------------------------- Fix Version/s: 2.4.0.SP1 (was: 2.4.1.Beta) Assignee: Ron Sigal > remote dynamic marshall loading not working on linux > ---------------------------------------------------- > > Key: JBREM-302 > URL: https://jira.jboss.org/jira/browse/JBREM-302 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: marshall > Affects Versions: 1.4.0 beta > Environment: Linux, JDK 1.4 > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.4.0.SP1 > > Attachments: SocketMarshallerLoadingTestCase-out.txt > > > The following test cases fail on Linux (and not on Windows): > org.jboss.test.remoting.marshall.dynamic.remote.http.HTTPMarshallerLoadingTestCase > org.jboss.test.remoting.marshall.dynamic.remote.socket.SocketMarshallerLoadingTestCase > Test output for SocketMarshallerLoadingTestCase attached, but says that server can not find the class: > org.jboss.test.remoting.marshall.dynamic.remote.socket.TestObject > However, confirmed that this class is within the jboss-remoting-loading-tests.jar, which is being set on the classpath (as shown in the output log). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-991) Investigate MulticastDetector message flood

by Ron Sigal (JIRA)

Investigate MulticastDetector message flood ------------------------------------------- Key: JBREM-991 URL: http://jira.jboss.com/jira/browse/JBREM-991 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 A use has reported that org.jboss.remoting.detection.multicast.MulticastDetector is flooding the network with messages. The problem might lie MulticastDetector.listen(): else { // for now, assume anything *not* of type Detection // is a prompt to send out detection msg heartbeat(); } -- 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

15 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-999) Make sure all fixes on 2.2 branch are ported to 2.x branch.

by Ron Sigal (JIRA)

Make sure all fixes on 2.2 branch are ported to 2.x branch. ----------------------------------------------------------- Key: JBREM-999 URL: http://jira.jboss.com/jira/browse/JBREM-999 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.SP1 -- 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

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBREM-925) SSLSocketBuilder config attribute names out of sync with docs

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-925?page=com.atlassian.jira.plug... ] Ron Sigal closed JBREM-925. --------------------------- Resolution: Done Added values for SSLSocketBuilder parameter name constants in the table and explained the difference. > SSLSocketBuilder config attribute names out of sync with docs > ------------------------------------------------------------- > > Key: JBREM-925 > URL: https://jira.jboss.org/jira/browse/JBREM-925 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: docs > Affects Versions: 2.4.0.GA (Pinto), 2.2.2.SP8 > Reporter: Tom Fennelly > Assignee: Ron Sigal > Fix For: 2.4.0.SP1, 2.2.2.SP10 > > > The latest docs available for download are for 2.2.0.GA (http://labs.jboss.org/jbossremoting/docs/index.html). > Table 5.1 (in pdf) outlines the attribute names for configuring the SSLSocketBuilder. They're not consistent with the actual definitions in the SSLSocketBuilder class, so errors result when used as per the docs. > In the ESB, we do a manual mapping of the names in code, so we get around the issue, but other users may be stumped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 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 August 2008