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.
Create a taglibrary with a tag that prints "taglib 1" create a tag library jar, put it in a web module's WEB-INF/lib and create a JSP that uses it. Deploy and execute the JSP. Now, stop Tomcat and delete the jar file. Delete the jarContents file. Delete the tag handlers. Generate tag handlers again and make it such that the tag prints "taglib 2". create the tag library jar, put it in the web module, deploy and make your request: you will see "taglib 1". Somewhere along the way, the new version is not overwriting the old version. I have not yet been able to discover a workaround and am thus filing this as a P1 bug.
I believe this could be caused by the fact that the Tomcat server only reloads the JSP if the JSP itself has been modified since last execution, so it does not pick up any changes in dependent files. I can think of two possible workarounds: 1) Delete the working files under the temp directory of Tomcat or 2) "touch" the JSP file - modify and save it Also, it would be useful to find out what is the behavior of standalone Tomcat server (without the IDE) in this case.
This turns out not to be specific to taglibs. It will happen with any jar dropped into WEB-INF/lib. I reproduced it the following way: - in a web module, create a directory (e.g. "pack"), create a java class "One" in that directory; compile the class. - create a new jar recipe, put the directory (pack) as one of the content members; compile the jar. - outside the ide, copy the jar into WEB-INF/lib; the jar will be mounted. Open it up in the explorer and see the package "pack" with the class "One" inside it. - delete the jar from WEB-INF/lib - remove the class "One" from the directory "pack"; create a new class "Two" in "pack"; compile it. - compile the jar recipe again. Look at the jar outside the ide. It should contain pack.Two but not pack.one. - outside the ide, copy the jar into WEB-INF/lib. wait for it to be mounted; open the mounted jar filesystem in the explorer -- it has pack.One, when it should have pack.Two. This might be related to some other jar behaviour I'm seeing: if two web modules have a copy of the same jar in WEB-INF/lib, only one will be mounted. So maybe there is some mechanism that sees that the name is the same as the old one, and mounts the old one instead. A confirmation of this: I copied the jar that was mounted incorrently into WEB-INF/lib, but under a different name, and the newly named copy was mounted correctly. Also: this happened without starting the tomcat server at all.
Spent more time trying to reproduce this, and the QAs cannot reproduce it. I went back and tried it again and found that it only occurs after certain other problems: 1. When I compile a jar recipe and then copy the jar from the menu on the jar's node inside the jarcontent node, and then paste the jar into WEB-INF/lib, then the resulting jar is length 0 (I've only seen this happen on my system), and then the bug happens. 2. Also, when I delete the jar from WEB-INF/lib, I get the little .nfsNNNN file. This also seems to correlate with this bug happening. (Note that I only seem to be getting the .nfsNNNN thingy after I get the zero length jar problem). 3. I'm only seeing this on solaris, and it happens to be solaris 7, using jdk1.3.1_01 So, if no one else can reproduce this problem it's probably not a P1.
Agreements was reached that this does not need to be fixed for Orion EA.
This additional behavior was noted by Hong Liu and filed as bug number 21331 build 020306(RC3) To reproduce: 1.create a web module. 2.create a taglibrary 3.add tag test1 to the taglibrary and create the taglibrary. 4.add the taglibary to the web module. 5.create a jsp file to use the test1 tag. It works fine. 6.add tag test2 to the taglibrary and create the taglibrary. 7 add the new taglibrary to the web module. The NEW taglibrary is added as it can be verified by extending the jar node. 8. modify the jsp to use the new tag test2. 9. compile the jsp There is error:No such tag test2 in the tag library... I tried to dismount/mount the web module, but it could not help. Restarting the ide, then it helps. Note: a workaround has been found! When developing a tag library, create the taglibrary (.tld file) in your web module's WEB-INF/lib directory. Additionally, set the tag handler generation root to WEB-INF/classes. In a .jsp file which is using the tag library, either refer to the URI as "/WEB- INF/lib/myTaglib.tld" or make an alias in the deployment descriptor.
*** Issue 21331 has been marked as a duplicate of this issue. ***
We've found a workaround, and this bug doesn't result in loss of user data or hanging the IDE, so we're lowering the priority to 2. Here is the entry from the release notes: 20877, 20384 Description: Tag library jars cannot be replaced in WEB-INF/lib after parsing and executing JSPs in the web module. The JSP parser, compiler, and/or executor sometimes hold onto pointers to tag library jars in WEB-INF/lib. On Windows this means that the jars intermittently cannot be deleted, resulting in a "Cannot delete file ..." exception. On Solaris, the jars can be deleted, but when they are replaced with new jars, sometimes the compiler "sees" the old version of the jars. To get the correct jar replacement behaviour, you must restart the IDE. This can make a tag library development cycle that involves packaging the tag library jars somewhat unwieldy. The workaround is to develop tag libraries by referencing the TLDs and tag handler classes directly, without packaging the tag library into a jar until the end of the development cycle. 1. Create the tag library in WEB-INF/lib and do all development there. 2. Set the tag handler generation root to the web module's WEB-INF/classes directory. 3. In order to use the tag libraries from a JSP, either directly refer to the taglib URI as "/WEB-INF/lib/myTaglib.tld" or set an alias in the deployment descriptor with a tag library entry.
*** This issue has been marked as a duplicate of 20384 ***
Changing target milestone to FFJ 4.0
Resolved for 3.4.x or earlier, no new info since then -> verify.
Resolved for 3.4.x or earlier, no new info since then -> closing.