Bug 37854 - Too strict Extension-List analysis
Summary: Too strict Extension-List analysis
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Unknown (show other bugs)
Version: 4.1.31
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2005-12-09 18:13 UTC by Pascal Grange
Modified: 2005-12-31 06:10 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Pascal Grange 2005-12-09 18:13:38 UTC
Using Extension-List in MANIFEST.MF jar files allows to specify dependencies  
between libraries or webapps.  
When a jar depends on an Extension without specifying an  
Implementation-Vendor-Id AND the corresponding extension does not specify an  
Implementation-Vendor-Id, tomcat fails loading the corresponding context  
claiming for a missing dependency.  
I thing that in this case (no Implementation-Vendor-Id in either files) the  
Implementation-Vendor-Id's must be considered OK and that it must not be  
enought to consider the dependency broken.
Comment 1 Mark Thomas 2005-12-18 17:47:33 UTC
Do you have a reference for a relevant speicifcation that requires the behaviour
you describe? I can't find one. I am leaning towards your interpretation but I
would like to see a proper definition of the required behaviour.
Comment 2 Pascal Grange 2005-12-21 11:03:46 UTC
The servlet spec v.2.3 p. 63 just makes a reference to the manifest spec 
specifying that the web container must reject the app and display an 
informative message if it can not satisfy a dependency. 
On the other hand, the manifest spec 
(http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html) specifies 
the behavior of the Java plugin. Since the servlet specification makes a direct 
reference to this manifest specification, I think we can consider that this 
behavior also applies to web containers. It specifies that : 
are all *OPTIONAL* in a manifest that indicate a dependency to <extension>. 
Moreover, still in manifest specification : 
"If the applet's manifest doesn't contain one or more of the optional 
attributes, the plug-in will accept any value of the corresponding attribute in 
the optional package's manifest." 
I suppose that "any value" also include no value. 
Hope it helps. 
Comment 3 Mark Thomas 2005-12-21 23:57:45 UTC
The attributes are optional for the plugin manifest but the same reference also

"Note that all of the above manifest attributes should be included in an
optional package's manifest."

The key word here is "should". If it was "must", the current Tomcat behaviour
would be fine. Nothing states explicity what the desired behaviour is if the
optional package's manifest does not include one of the attributes.

Your interpretation is a sensible one but hinges on the assumption that "any
value" is the same as "no value". I want to think about this for a little while
before I make any changes. Watch this space...
Comment 4 Mark Thomas 2005-12-31 15:10:35 UTC
This and some related issues have been fixed in TC4 and TC5.