You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2007/01/22 21:32:47 UTC

getting at META-INF in a dependent jar

First of all, my apologies if this doesn't make complete sense.  I'm not 
sure how exactly we're supposed to be able to find the tag library 
descriptors defined in META-INF of a jar.  All I know for sure is that 
we currently have a problem with tags in JSTL and I suspect JSF as well.

JSTL is included in our assemblies because I have added the jar as a 
dependency in configs/jetty6 and configs/tomcat6.  This ensures that the 
JSTL classes are included in the classpath.  However, when we attempt to 
run a JSTL application we get the following error:

"The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved 
in either web.xml or the jar files deployed with this application"

The uri that it is attempting to resolve is defined in the META-INF 
contained within the jstl.jar (specifically in a tag library descriptor 
named c.tld).  I suspect that adding the jar dependency as I did in the 
config only adds the classes from the jar to the classpath and doesn't 
provide a means to process the META-INF container in the jar ... is that 
correct?

I can get around the problem by adding a dependency on the JSTL jar to 
the geronimo deployment plan of the application.  It seems this allows 
*whatever* to process the META-INF and resolve the uri reference for the 
tag.  However IIUC, this would not meet the Java EE 5 requirement to 
make JSTL available natively to the application.

I tried to add the same dependency on the jstl.jar dynamically during 
deployment by adding it to the defaultEnvironment of the deployer (as 
recommended by David Jencks).  However, it seems this isn't exactly the 
same as adding the dependency to the application since I still had the 
uri resolution error even with this change.


Is there another way to ensure the META-INF from this jstl jar is 
available short of actually adding the dependency to jstl directly in 
the geronimo deployment plan for the application?

I also attempted to add the jstl.jar as a dependency in the 
jetty6/tomcat6 module geronimo-dependency.xml thinking that there was 
some different/stronger magic at play there.  However, I couldn't get 
that to find the jstl.jar from the java.net repo to build the 
tomcat/jetty configs (even though I added the repository to the pom.xml 
for the config/tomcat6|jetty6 and module/geronimo-tomcat6|jetty6  ... it 
always failed when building the configs for the web container).

One more strange bit of information:  We don't seem to have this same 
problem with the web console application itself (which also uses JSTL). 
  For the web console I updated the pom for the 
geronimo-console-standard application to depend on jstl with a scope of 
"provided" so that it would build but not include jstl in the resulting 
war.  When running the console the uri can be resolved from the taglibs. 
  Is this because the "provided" scope puts a dependency directly on the 
jar even though it doesn't include the jar in the war?

Thanks,
Joe