Affects Version/s: 1.5.3
Environment:HideGlassFish v2.1.1 and GlassFish v.3.1
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
Mac OS X 10.7.2ShowGlassFish v2.1.1 and GlassFish v.3.1 java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) Mac OS X 10.7.2
The UrlResourceStream, used by PackageResources, uses URLConnection#getInputStream() to get file contents. This method is called in UrlResourceStream#getInputStream(), but also when closing the resource in UrlResourceStream#close(). At least on GlassFish v2 and v3, the second call to URLConnection#getInputStream() returns a new stream, so the one created to retrieve the file contents is never closed properly.
This results in a warning of the container when the classes are garbage-collected, for example on undeploy.
The problem is not triggered in all situations. It can be reproduced by using Wicket in a multi-module project consisting of an EAR, WAR and JAR. The JAR must contain a resource (CSS, image, ...) and a Behavior. Inside the Behavior, a static ResourceReference must be created for the resource file.
When using this Behavior from inside the WAR project by loading a page the resource is loaded properly. On undeploy however, the described problem will show up.
The problem does not exists in Wicket 1.4.x, because a reference to the InputStream is stored. A quickstart and patch for 1.5 is available, will try to attach it