[ahardy66]

This is the one that compiles into jboss-3.2.4RC1?


Adam

[ahardy66]

It worked. Thanks v. much for the fix.

Adam

[jdoble]

I ran into the same problem trying to deploy the JavaServer Faces 1.0 Beta samples on JBoss 3.2.3, with Tomcat 5. The suggested work-around (i.e. false) appears to solve the problem of locating the taglibs, but I found that it led to other classloader-related problems. For example, the first thing I ran into was that debug classes contained within jars in the sample war's WEB-INF/lib directory didn't match identical classes that had previously been loaded by the JBoss class loader. In order to deal with this problem, I experimented some more and found that if I copied all of the TLD files that were in any of the jars in the WEB-INF/lib directory into the WEB-INF directory, then I found that the system was able to find the TLD files, and I no longer needed to set the UseJBossWebLoader property to false.

To make my life easier, I developed a small ant file to do the necessary conversion:













































Note that you need to specify the war-name (the name of the war file you want to convert) and the deploy-dir (the name of the directory to which you would like to deploy the war file). If you just want to modify the war file, you can just invoke the copyTlds target, and you don't need to specify a value for the deploy-dir in that case.

Also note that I tried this with one of the the JSTL samples (standard-examples.war), and it appeared to work for that as well.

So now we have two work-arounds to choose from:

1) set the UseJBossWebLoader property to false
2) copy the tlds into the WEB-INF directory

The bottom line here is that the JBossWebLoader doesn't seem to be looking for TLD files within the jars in the WEB-INF/lib directory. Are there any plans to fix this?

[jdoble]

I ran into the same problem trying to deploy the JavaServer Faces 1.0 Beta samples on JBoss 3.2.3, with Tomcat 5. The suggested work-around (i.e. false) appears to solve the problem of locating the taglibs, but I found that it led to other classloader-related problems. For example, the first thing I ran into was that debug classes contained within jars in the sample war's WEB-INF/lib directory didn't match identical classes that had previously been loaded by the JBoss class loader. In order to deal with this problem, I experimented some more and found that if I copied all of the TLD files that were in any of the jars in the WEB-INF/lib directory into the WEB-INF directory, then I found that the system was able to find the TLD files, and I no longer needed to set the UseJBossWebLoader property to false.

To make my life easier, I developed a small ant file to do the necessary conversion:













































Note that you need to specify the war-name (the name of the war file you want to convert) and the deploy-dir (the name of the directory to which you would like to deploy the war file). If you just want to modify the war file, you can just invoke the copyTlds target, and you don't need to specify a value for the deploy-dir in that case.

Also note that I tried this with one of the the JSTL samples (standard-examples.war), and it appeared to work for that as well.

So now we have two work-arounds to choose from:

1) set the UseJBossWebLoader property to false
2) copy the tlds into the WEB-INF directory

The bottom line here is that the JBossWebLoader doesn't seem to be looking for TLD files within the jars in the WEB-INF/lib directory. Are there any plans to fix this?

[jdoble]

I guess the sample ant code would be more helpful if it were not invisible:

<project name="JBoss Helper" default="deploy" basedir=".">

 <property name="jboss-helper-dir" value="/jboss-helper" />
 <property name="jboss-helper-jars-dir" value="/jars" />
 <property name="jboss-helper-tlds-dir" value="/tlds" />

 <target name="copyTlds" description="">

 <fail message="The war-name property is not set." unless="war-name" />

 <mkdir dir=""/>
 <mkdir dir=""/>
 <mkdir dir=""/>

 <unwar src="./.war" dest="">
 <patternset>
 <include name="**/*.jar"/>
 </patternset>
 </unwar>

 <unjar dest="">
 <patternset>
 <include name="**/*.tld"/>
 </patternset>
 <fileset dir="">
 <include name="**/*.jar"/>
 </fileset>
 </unjar>

 <war destfile="./.war" update="true">
 <webinf dir="/META-INF"/>
 </war>

 <delete dir=""/>

 </target>

 <target name="deploy" description="" depends="copyTlds">
 <fail message="The deploy-dir property is not set." unless="deploy-dir" />
 <copy file="./.war" todir="" />
 </target>

</project>

[sureshvembu]

After some analysis, we were able to locate the problem in the WebCtxLoader.java (present in the tomcat/src/main/org/jboss/web/tomcat/tc5 directory) implementation.

The problem is in the setWarURL method. Here instead of adding the URLs to the ENCLoader (ctxLoader), it has been added to the parent (UnifiedClassLoader) loader. When I changed the implementation to add the URLs to the ENCLoader, things are working fine now. I.e., the Tomcat is able to load the tlds present in the jar files now properly. This is because, the TldLocator needs the getURLs() to return properly for locating the .tld files. The UnifiedClassLoader by design ignores the getURLs() method and returns a empty-array. So, changing the URL addition to the ENCLoader helps return proper URL [] and thus the location of resources too!

I've given below the code-snippet of the change made:

public void setWarURL(URL warURL) throws MalformedURLException
{
....
//Add the URLs to the ctxLoader instead of the delegate!
//delegate.addURL(classesDir.toURL());
ctxLoader.addURL(classesDir.toURL());
....
//Add the URLs to the ctxLoader instead of the delegate!
//delegate.addURL(jars[j].toURL());
ctxLoader.addURL(jars[j].toURL());
}

Hope this is useful.

Regards,
Suresh.K.V.

[rmaucher]

I recommend using the Tomcat classloader instead (configured in the jboss-service.xml). This is a lot more "webapp friendly" than the JBoss classloader.

I will properly implement the getURLs of the fake ENCLoader (your proposed patch is bad).