Bug 37854

Summary: Too strict Extension-List analysis
Product: Tomcat 4 Reporter: Pascal Grange <pgrange>
Component: UnknownAssignee: Tomcat Developers Mailing List <dev>
Severity: normal    
Priority: P2    
Version: 4.1.31   
Target Milestone: ---   
Hardware: All   
OS: All   

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.