August 2008 - jboss-jira - Jboss List Archives

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

1
6
0 / 0

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

2
5
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, 8 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, 8 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1191) Work with contributor to translate JBoss Cache documentation into Spanish

by Manik Surtani (JIRA)

Work with contributor to translate JBoss Cache documentation into Spanish ------------------------------------------------------------------------- Key: JBCACHE-1191 URL: http://jira.jboss.com/jira/browse/JBCACHE-1191 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Michael Smith Fix For: 2.2.0.GA See email sent in to the jbosscache-dev list: http://lists.jboss.org/pipermail/jbosscache-dev/2007-September/002031.html -- 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, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (JBRULES-1724) refactor security stuff, replacing package UUID with package name

by Jervis Liu (JIRA)

refactor security stuff, replacing package UUID with package name ------------------------------------------------------------------ Key: JBRULES-1724 URL: https://jira.jboss.org/jira/browse/JBRULES-1724 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Reporter: Jervis Liu Assignee: Jervis Liu Fix For: 5.0.0.M2 switch to using package name instead of UUID -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1727) permissions should use package=packageNameHere instead of UUID

by Michael Neale (JIRA)

permissions should use package=packageNameHere instead of UUID -------------------------------------------------------------- Key: JBRULES-1727 URL: https://jira.jboss.org/jira/browse/JBRULES-1727 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 5.0.0.M1 Reporter: Michael Neale Assignee: Jervis Liu Fix For: 5.0.0.M2 I think we should use name instead of UUID. In case of name change, we can propagate changes in ServiceImplementation (there is a specific name change service) or just let people deal with it. Names won't change very often. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5807) org.jboss.test.deployers.ear.test.EARAltDDConnectorDeploymentUnitTestCase

by Shelly McGowan (JIRA)

org.jboss.test.deployers.ear.test.EARAltDDConnectorDeploymentUnitTestCase ------------------------------------------------------------------------- Key: JBAS-5807 URL: https://jira.jboss.org/jira/browse/JBAS-5807 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Shelly McGowan Assignee: Alexey Loubyansky -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-5848) Optimize AnnotatedMetaDataDeployer

by Ales Justin (JIRA)

Optimize AnnotatedMetaDataDeployer ---------------------------------- Key: JBAS-5848 URL: https://jira.jboss.org/jira/browse/JBAS-5848 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-5.0.0.CR1 Reporter: Ales Justin Assignee: Ales Justin Fix For: JBossAS-5.0.0.CR2 Optimize AnnotatedMetaDataDeployer. New deployer should use MC deployers AnnotationEnvironment implementation which uses Javassist to lazily load classes. -- 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, 8 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2008