[JBoss AS Development] - getResources in BaseClassLoader, ClassLoaderDomain, and frie
by ttarhan
Folks,
BaseClassLoader, ClassLoaderDomain and several other classes in JBossCL have public API methods which take Set as a parameter. We can't control what implementation of Set is passed in to these methods, but HashSet is commonly used, causing the URL.hashCode() performance problem (DNS lookup).
I do not understand enough about the public API of JBossCL to know where these methods might be used from. However, I do know that these methods are called internally from several areas in JBossCL with a HashSet.
I see a two-step solution:
1) Change anywhere in JBossCL where HashSet is used to another Set implementation. This is a quick and non-API-breaking change that will actually take care of the most common scenarios.
An example (from user code in the container): ClassLoader.getResources(String) eventually calls BaseClassLoader.loadResources(String) which creates a HashSet and passes that to ClassLoaderDomain.getResources(...) to be filled in, eventually returning the HashSet to the caller. Changing the internal usage of ClassLoaderDomain and friends to use a Set other than HashSet would fix this scenario.
2) Consider if there is an API change required to prevent misuse of this by callers outside of JBossCL. I'm not sure if any of these methods are intended to be used from outside. Some are public, some are not.
I'm willing to tackle solution #1 and may submit a patch later this evening.
However, I need some help/discussion/advice before I could tackle #2.
Thoughts? Comments?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255634#4255634
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255634
16 years, 6 months
[JBoss AS Development Deployment Framework] - Deployment isolation problem with ear being ported from Webl
by jwchristy
I have an ancient weblogic-hosted J2EE application (2003ish) that I am porting to Jboss 4.2.3.GA. It uses old versions of lots of 3rd party tools, including JAXB, version 1.0.4. I have gotten the ear to deploy cleanly by removing those 3rd party jars from the ear that conflict with jars already in use by the Jboss server, and the application almost runs, but hits problems when it tries to get an old JAXB ContextFactory class that no longer exists in the version of JAXB that the Jboss server is using, 2.1.4.
I then went down the path of putting the old jars back into the ear and doing an isolated deployment, in the hope that I could use the old JAXB. I am using this deployment descriptor in the ear:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-app
PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd">
<jboss-app>
<loader-repository>
com.ghx:archive=cm.ear
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
</jboss-app>
However, now it appears that various components within the ear can no longer see each other. The deployment is bombing when an application class in an included jar tries to find an xml document in another included jar. This worked fine with a non-isolated deployment. Help, what am I doing wrong?
The ear has 4 EJB jars, a war, numerous jars of application code, and even more jars of 3rd party library code (about 50 total jars/war within the ear).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255598#4255598
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255598
16 years, 6 months