November 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by anil.saldhana＠jboss.com

We are past that error now. But I am seeing the following error. | java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: | java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.security.plugins.JBossSecurityContext (no security manager: RMI class loader disabled) | at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:285) | at sun.rmi.transport.Transport$1.run(Transport.java:153) | at java.security.AccessController.doPrivileged(Native Method) | at sun.rmi.transport.Transport.serviceCall(Transport.java:149) | at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) | at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.security.plugins.JBossSecurityContext (no security manager: RMI class loader disabled) | at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) | at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) | at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) | at org.jboss.system.JBossRMIClassLoader.loadClass(JBossRMIClassLoader.java:91) | at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) | at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197) | at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544) | at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) | at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) | at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) | at org.jboss.invocation.MarshalledInvocation.readExternal(MarshalledInvocation.java:665) | at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755) | at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717) | at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) | at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:290) | at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:279) | ... 6 more | I am not sure how to solve this as JBossSecurityContext is both part of jbosssx.jar and jbosssx-client.jar. What are the 4.2.x test cases using? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193149#4193149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193149

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractDeploymentClassLoaderPolicyModule is mossing res

by alesj

"alesj" wrote : Resolved: https://jira.jboss.org/jira/browse/JBDEPLOY-137 Re-opened. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193148#4193148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193148

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractDeploymentClassLoaderPolicyModule is missing res

by alesj

Now I'm seeing this: | 00:38:37,546 ERROR [VFSClassLoaderDescribeDeployer] Error during undeploy: vfszip:/C:/projects/jboss5/trunk/testsuite/output/lib/jboss-seam-numberguess.ear/jboss-seam-numberguess.war | java.lang.IllegalStateException: Not installed: vfszip:/C:/projects/jboss5/trunk/testsuite/output/lib/jboss-seam-numberguess.ear/jboss-seam-numberguess.war_Alias_AbstractKernelController[9568605] | at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:689) | at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568) | at org.jboss.dependency.plugins.AbstractController.removeAlias(AbstractController.java:621) | at org.jboss.deployers.plugins.classloading.AbstractDeploymentClassLoaderPolicyModule.determineContextName(AbstractDeploymentClassLoaderPolicyModule.java:104) | at org.jboss.deployers.plugins.classloading.AbstractDeploymentClassLoaderPolicyModule.reset(AbstractDeploymentClassLoaderPolicyModule.java:146) | at org.jboss.classloading.spi.dependency.Module.release(Module.java:751) | at org.jboss.classloading.spi.dependency.ClassLoading.removeModule(ClassLoading.java:71) | at org.jboss.deployers.plugins.classloading.AbstractClassLoaderDescribeDeployer.undeploy(AbstractClassLoaderDescribeDeployer.java:120) | at org.jboss.deployers.plugins.classloading.AbstractClassLoaderDescribeDeployer.undeploy(AbstractClassLoaderDescribeDeployer.java:39) | at org.jboss.deployers.spi.deployer.helpers.AbstractOptionalRealDeployer.internalUndeploy(AbstractOptionalRealDeployer.java:91) | at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.undeploy(AbstractRealDeployer.java:112) | at org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:196) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doUndeploy(DeployersImpl.java:1469) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1376) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1356) | at org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:1331) | at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354) | at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631) | at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:827) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:694) | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545) | at org.jboss.profileservice.management.upload.remoting.DeployHandler.stop(DeployHandler.java:251) | at org.jboss.profileservice.management.upload.remoting.DeployHandler.invoke(DeployHandler.java:153) | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908) | at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695) | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522) | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230) :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193147#4193147 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193147

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MainDeployerImpl deploy/undeploy using wrong DeploymentC

by alesj

https://jira.jboss.org/jira/browse/JBDEPLOY-138 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193145#4193145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193145

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - MainDeployerImpl deploy/undeploy using wrong DeploymentConte

by alesj

While fixing Module::reset for Controller::removeAlias, I saw that this two cases don't behave the same, all though they should: | Deployment deployment = ...; | DeployerClient dc = ...; | | dc.addDeployment(deployment); | dc.proocess(); | | // vs. | | dc.deploy(deployment); | | // same for undeploy(ment) | This was due to the fact that Deployment::name is not necessarily equal to DeploymentContext::name, as my ModuleRemoveUnitTestCase test shows. I've fixed it to use the right method --> getTopLevelDeploymentContext. I guess this is the 2nd bug, which calls for another release. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193144#4193144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193144

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractDeploymentClassLoaderPolicyModule is mossing res

by alesj

Resolved: https://jira.jboss.org/jira/browse/JBDEPLOY-137 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193140#4193140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193140

16 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: Security aspect updates

by anil.saldhana＠jboss.com

https://jira.jboss.org/jira/browse/JBASPECT-29 has been assigned to Stefan to start building some test cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193135#4193135 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193135

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by anil.saldhana＠jboss.com

Dimitris, I have upgraded AS to use Security 2.0.2.SP3 and made the necessary changes in the AS/security module. Please verify that the compatibility test is fixed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193133#4193133 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193133

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC upgrade breaks scoped aop tests in trunk

by alesj

"anil.saldhana(a)jboss.com" wrote : While you are at the mc release, can you put back the system property for the real urls in VFSClassLoaderPolicy? MC != CL ;-) Dimitris means Kernel part of MC. We should re-name the MC parts, as MC of MC is confusing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193131#4193131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193131

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractDeploymentClassLoaderPolicyModule is mossing res

by alesj

This | if (aliases != null && aliases.contains(contextName) == false) | was also a bug. It should be | if (aliases == null || (aliases != null && aliases.contains(contextName) == false)) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193130#4193130 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193130

16 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2008