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

[Design of Security on JBoss] - Re: Security Injection in AS5

by scott.stark＠jboss.org

You will have to specify that jar and related in the deployment classpath: | | <classloader><inject bean="JBossSXClassLoader"/></classloader> | | <bean name="JBossSXClassLoader" class="org.jboss.system.NoAnnotationURLClassLoader"> | <classloader><null/></classloader> | <constructor factoryClass="org.jboss.system.NoAnnotationURLClassLoader" factoryMethod="createClassLoader"> | <parameter> | <array elementClass="java.net.URL"> |  | <value>${jboss.server.lib.url}/jbosssx.jar</value> | </array> | </parameter> | </constructor> | </bean> | ... | This is a brute force configuration. There should be a way to specify the class loader system that includes all the server libs as well as just naming the packages you want to import. We need to get that syntax documented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142217#4142217 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142217

18 years

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Clustering classes in the aspects module

by bstansberry＠jboss.com

The folks in Neuchatel have begun work on refactoring the aspects module into external projects so EJB3 doesn't depend on an AS module. I'll be making the following changes in support of this: 1) jboss-ha-client will add a dependency on Remoting and on a new to-be-created org.jboss.aspects:jboss-aspects-remoting project. This will resolve the dependency issue discussed at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=124773, allowing me to move ClusterConstants, ClusterChooserInterceptor and FamilyWrapper into jboss-ha-client. 2) jboss-ha-server-api will add a dependency on jboss-ha-client. The org.jboss.aspects.remoting.ReplicantsManagerInterceptor will be moved into jboss-ha-server-api. 3) The org.jboss.aspects.remoting.ClusteredRemoting class is a helper utility for creating clustered proxies. No one uses it outside of an AS testsuite class, org.jboss.test.aop.bean.RemotingTester. I don't want to bring this class into jboss-ha-server-api as it has a bunch of hardcoded dependencies on other remoting interceptors -- I don't want that kind of detailed coupling to the jboss-aspects-remoting project. I think the class should either be removed altogether, moved to the cluster module or just left in a rump aspects module. This work will produce a 1.1.0.GA release of jboss-ha-client and jboss-ha-server-api. I'll publish a 1.1.0-SNAPSHOT as soon as a snapshot of jboss-aspects-remoting is published. In the 1.1.0 release I'll also add a HAPartitionLocator class to jboss-ha-server-api. This will be a utility to encapsulate HAPartition service location; get rid of the JNDI and JMX lookup code scattered in various places. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142177#4142177 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142177

18 years

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-5278 Errors .

by timfox

For JBM 2.0 I don't want to have to write a connection consumer implementation at all (since it's a horrible thing), in which case, as Adrian points out a JBM resource adaptor will need to use some kind of JBM internal API and won't work with other JMS systems. So question is does this become part of JBM or remain in the JCA project? I'm not too bothered either way. One thing to bear in mind is I suspect the JBM specific RA can re-use a fair bit of code from the generic one, so we need to think where that shared code lives. Jesper - if you want to lend a hand that's great. We could spin this off as a JBM sub project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142166#4142166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142166

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: MessageDeliverException when call ESB inside a WS.

by lihui_pang

Anyone can help, please? Lihui View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142164#4142164 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142164

18 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5376: leak of webapp classloader when deployed in e

by bstansberry＠jboss.com

If you deploy a war with a loader-repository configured, the domain gets leaked; your patch above will fix that. But, in this case it's not such a big deal, as the war's classloader gets removed from the leaked domain, and the leaked domain's parent is the default domain. So, my FIELD granularity classloader leak problem is something else. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142162#4142162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142162

18 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Security Injection in AS5

by sguilhen＠redhat.com

Scott, I've tried again, and it indeed goes past the parsing error when using the vsf schema location. Now I am also seeing the failure to load the org.jboss.security.config.PolicyConfig that you also reported: | 10:20:33,101 ERROR [AbstractKernelController] Error installing to Parse: name=vfsfile:/opt/workspace/JBAS-Trunk/build/output/jboss-5.0.0.CR1/server/default/deploy/security-policies-beans.xml state=Not Installed mode=Manual requiredState=Parse | org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/opt/workspace/JBAS-Trunk/build/output/jboss-5.0.0.CR1/server/default/deploy/security-policies-beans.xml | at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:253) | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:223) | .... | Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to resolve class name for {urn:jboss:security-config:5.0}policy: org.jboss.security.config.PolicyConfig | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:193) | at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:153) | at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:120) | at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:143) | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:249) | ... 20 more | Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve class name for {urn:jboss:security-config:5.0}policy: org.jboss.security.config.PolicyConfig | at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.loadClassForTerm(RtElementHandler.java:1038) | at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.classForNonArrayItem(RtElementHandler.java:1367) | at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.startElement(RtElementHandler.java:693) | at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.startParticle(RtElementHandler.java:89) | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:632) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:407) | this class can be found in the server/xx/lib/jbosssx.jar. Would this be a classloading issue or am I missing some configuration? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142148#4142148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142148

18 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5376: leak of webapp classloader when deployed in e

by bstansberry＠jboss.com

I'll let you know. Urgent thing for me is I'm trying to sort out classloading related failures in the FIELD granularity web session replication tests; first step was analyzing ClassLoaderLeakUnitTestCase failures, which is what led to my filing the JIRA. But this ear issue was really a tangent; the FIELD tests don't even use an ear. The FIELD tests just use a war, but it declares a loader-repository. I'll see if it could somehow be related and post back one way or another. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142145#4142145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142145

18 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5376: leak of webapp classloader when deployed in e

by adrian＠jboss.org

The patch is fairly simple (see the change to undeploy below). If you can't wait for the next release of jboss-deployers then we could just copy the fixed deployer into the AS project as a temporary fix. | Index: deployers-impl/src/main/org/jboss/deployers/plugins/classloading/AbstractLevelClassLoaderSystemDeployer.java | =================================================================== | --- deployers-impl/src/main/org/jboss/deployers/plugins/classloading/AbstractLevelClassLoaderSystemDeployer.java (revision 71766) | +++ deployers-impl/src/main/org/jboss/deployers/plugins/classloading/AbstractLevelClassLoaderSystemDeployer.java (working copy) | @@ -21,6 +21,7 @@ | */ | package org.jboss.deployers.plugins.classloading; | | +import org.jboss.classloader.spi.ClassLoaderDomain; | import org.jboss.classloader.spi.ClassLoaderSystem; | import org.jboss.classloading.spi.dependency.ClassLoading; | import org.jboss.classloading.spi.dependency.Module; | @@ -136,8 +137,22 @@ | ClassLoader classLoader = unit.getClassLoader(); | try | { | - // Remove the classloader | - system.unregisterClassLoader(classLoader); | + try | + { | + // Remove the classloader | + system.unregisterClassLoader(classLoader); | + } | + finally | + { | + // Try to tidy up empty domains | + String domainName = module.getDeterminedDomainName(); | + if (ClassLoaderSystem.DEFAULT_DOMAIN_NAME.equals(domainName) == false) | + { | + ClassLoaderDomain domain = system.getDomain(domainName); | + if (domain.hasClassLoaders() == false) | + system.unregisterDomain(domain); | + } | + } | } | finally | { | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142127#4142127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142127

18 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5376: leak of webapp classloader when deployed in e

by bstansberry＠jboss.com

LOL. Adrian looking at JBAS-5368 found the exact same thing, and doesn't appear to need my details. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142119#4142119 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142119

18 years

1
0
0 / 0

[Design of POJO Server] - JBAS-5376: leak of webapp classloader when deployed in ear

by bstansberry＠jboss.com

Discussion of http://jira.jboss.com/jira/browse/JBAS-5376. I've walked through the deploy/undeploy of an ear with an embedded war, and here's what I see. During deployment of the nested war: AbstractLevelClassLoaderSystemDeployer.createClassLoader(DeploymentUnit) --> VFSDeploymentClassLoaderPolicyModule.registerClassLoaderPolicy(ClassLoaderSystem system, ClassLoader parent) --> DefaultClassLoaderSystem.registerClassLoaderPolicy(String domainName, ParentPolicy parentPolicy, Loader parent, ClassLoaderPolicy policy) --> ClassLoaderSystem.createAndRegisterDomain(String name, ParentPolicy parentPolicy, Loader parent) Here we create a domain for the war and assign param "Loader parent" to the new domain as it's parent. "Loader parent" has a ref to the ear classloader. We then register the new domain with the classloader system. This sets up the chain of references shown in the JIRA description. During undeploy: AbstractLevelClassLoaderSystemDeployer.removeClassLoader(DeploymentUnit unit) --> BaseClassLoaderSystem.unregisterClassLoader(ClassLoader classLoader) --> BaseClassLoaderSystem.unregisterClassLoaderPolicy(ClassLoaderPolicy policy) that removes the ref to the *war's* poliyc/classloader from the war's domain, But the war domain itself is never unregistered from the ClassLoaderSystem. So the ref to the parent is leaked. In an eclipse I don't see any calls at all to ClassLoaderSystem.unregisterDomain(ClassLoaderDomain domain) anywhere. ClassLoaderSystem.shutdown() removes all domains, but that doesn't help here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142116#4142116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142116

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008