This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The situation: standard (new) Enterprise Application project, consisting of one EJB module and one Web module with JSPs. The web module uses a tag library, supplied in a JAR-file. The tag library URI is NOT declared explicitly in the web.xml. When the Web-module is built/deployed alone, everything works fine; the libraries to be packaged get nicely placed in WAR's WEB-INF/lib directory and the AppServer properly resolves the tag library URI from the JAR-file. However, when EAR is being built, the same libraries are not placed into the WEB-INF/lib anymore, but, instead are included in root of the EAR and in the appropriate manifest's classpath. Unfortuantely, SJAS 8.1 is unable to find any tag library references EAR packaged this way, resulting in an error "...the tag library absolute URI xxx is not specified in web.xml or in any libraries deployed with the application...". Not sure if SJAS is supposed to find them in this situation, or if it is just a bug. But the whole situation is definitely very confusing and takes time to find out what's gong wrong. As a workaround, one may explicitly add the libraries that must go to WEB-INF/lib in the Build/packaging window of the project settings.
Marku, this seems to be in your area.
I have a question for the reporter. Do you use "http-based" URIs to refer your taglibs in your JSP and tld files or you use the URIs relative to web root? This may make a significant difference. If you use the URIs relative to webmodule root e.g. <%@taglib uri="/WEB-INF/lib/mytaglib" prefix="c"%> (there is a <uri>/WEB-INF/lib/mytaglib</uri> element in you tld file) the webmodule deployed as a j2ee module inside and ear will not likely work. The some situation will happen if you use a link to a physical tld file (e.g. <%@taglib uri="/WEB-INF/lib/mytaglib.tld" prefix="c"%> The solution which should work is to define an "http-URI" like <uri>http://mydomain.org/mylib</uri> in your tld file and use this reference in your JSP files. So the JSP will look like: <%@taglib uri="http://mydomain.org/mylib" prefix="c"%> Please let me know which mechanism do you use, or better, send me you tld file or the entire library.
Created attachment 21862 [details] Example tag library
In fact, "http-based" URI is exactly what I used. The JSP fragment looks like: <%@page contentType="text/html;charset=ISO-8859-15"%> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> <%@ taglib uri="http://jsftutorials.net/htmLib" prefix="htm" %> ... and the library, defining the "http://jsftutorials.net/htmLib" is attached
Thanks for the information. It really seems to be an appserver problem. I will resend this issue to someone from the appserver team for further examination.
*** Issue 58393 has been marked as a duplicate of this issue. ***
I don't think it's an appserver issue. If I understand the specs right, the appserver is only required to scan all the jar files under WEB-INF/lib to look for TLDs, but not for jar files in other places. Correct me if I am wrong.
I think it's user problem. Web container works as specified in Servlet Specification. OTOH it would be nice if IDE can help user resolve this problem - how many users read spec? ;-)
New Struts support doesn't work out-of-box for J2EE apps due this issue. The bug should be definitely resolved very soon. I'm raising priority to p2.
ufff - fixed. Now the buildscript for webprojects built from ears searches for /META-INF/tlds/*.tld files in project libraries and if it finds any tld/s it puts the jarfile into /WEB-INF/lib instead of using the j2ee jars sharing mechanism. Checking in src/org/netbeans/modules/web/project/resources/build-impl.xsl; /cvs/web/project/src/org/netbeans/modules/web/project/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.102; previous revision: 1.10
[build 20050915]