[WICKET-4293] UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.3
• Fix Version/s: 1.5.4, 6.0.0-beta1
• Component/s: wicket
• Labels: core ear glassfish resource
• Environment: GlassFish 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
• Assignee: Martin Tzvetanov Grigorov
• Reporter: Pepijn de Geus
• Created: 14/Dec/11 14:27
• Updated: 16/Dec/11 15:47
• Resolved: 16/Dec/11 14:17

Description

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

Issue Links

• is duplicated by: WICKET-3957 PackageResource file locking problem