Bug 57038 - codebase of a class in a jar (while loading it) is now associated with its own URL (jar:file://....../<jar_name>.jar/.../<classname>.class), instead of its JAR’s URL
codebase of a class in a jar (while loading it) is now associated with its ow...
Status: RESOLVED FIXED
Product: Tomcat 8
Classification: Unclassified
Component: Catalina
8.0.x-trunk
PC All
: P2 normal (vote)
: ----
Assigned To: Tomcat Developers Mailing List
:
: 57206 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-09-29 11:40 UTC by Senthil Kumar
Modified: 2014-11-13 13:07 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Senthil Kumar 2014-09-29 11:40:56 UTC
In Tomcat 8. We found that Code base for a class in a Jar is pointing to its own URI instead of JAR’s path.

	This change in Tomcat’s behavior is probably on account of changes made to WebappClassloader.findResourceInternal() method of Tomcat’s catalina component. I found this by quickly debugging through its source code.
	From the source code, it is clear that till Tomcat 7.0.55, the codebase that was being associated with a class while loading it was obtained from its JAR’s URL (i.e. jar://...../<jar_name>.jar). 
	But from Tomcat 8.0.0 onwards, codebase of the same class (while loading it) is now associated with its own URL (jar:file://....../<jar_name>.jar/.../<classname>.class), instead of its JAR’s URL.
	I also could not find any configuration parameter around this piece of code through which behavior can be reverted to previous releases.
	Thus, I suspect that this change made to WebappClassloader.findResourceInternal() method is leading to current problem. 

	I searched a lot, but could not find out the exact bug ID for which these changes were checked in. But I suspect that these changes are related to one of the following changes:
i.	Tomcat 8’s change log contains following entry: 

Implement a new Resources implementation that merges Aliases, VirtualLoader, VirtualDirContext, JAR resources and external repositories into a single framework rather than a separate one for each feature

‘Internal APIs’ section of Apache Tomcat 8.0 Migration document states the following:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Whilst the Tomcat 8 internal API is broadly compatible with Tomcat 7 there have been many changes at the detail level and they are not binary compatible. Developers of custom components that interact with Tomcat's internals should review the JavaDoc for the relevant API.

Of particular note are:

	The Manager, Loader and Resources have moved from Container to Context since Context is the only place they are used.
	The Mapper has moved from the Connector to the Service since the Mapper is identical for all Connectors of a given Service.
	A new Resources implementation that merges Aliases, VirtualLoader, VirtualDirContext, JAR resources and external repositories into a single framework rather than a separate one for each feature.
	A new interface SessionIdGenerator has been added making session id generation extensible. Methods to get and set the id generator class name have been added to the Manager interface.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


ii.	Bug 53081 - WebappClassLoader causes java.lang.OutOfMemoryError in findResourceInternal()
                      ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Comment 1 Mark Thomas 2014-09-29 14:42:29 UTC
Thanks for the report. This has been fixed in 8.0.x for 8.0.15 onwards.
Comment 2 Konstantin Kolinko 2014-11-13 13:07:34 UTC
*** Bug 57206 has been marked as a duplicate of this bug. ***