On Fri, Nov 14, 2014 at 3:14 PM, Mark Thomas <ma...@apache.org> wrote: > On 14/11/2014 18:14, Matt Newell wrote: >> Greetings, >> >> I have a need to get version information for classes that I have been >> packaged in a war, and loaded into Tomcat 7.0.trunk on Windows 7. For >> example: >> >> >> System.out.println(this.getClass().getPackage().getImplementationVersion()); >> >> Assuming my.war/META-INF/MANIFEST.MF: >> Manifest-Version: 1.0 >> Implementation-Version: 1.0 >> >> getImplementationVersion() always returns null. >> >> If I review the code for WebappClassLoader the reason for this is clear. >> All roads lead to findResourceInternal(File, String), line 2983 in >> 7.x/trunk. This method makes no attempt to load the manifest from the war. >> >> My first instinct was that this is a bug. However, I did a quick check >> using the same scenario using Wildfly 8 and the behavior is the same. Given >> the clarity of the Tomcat code, and that two robust, well-tested platforms >> behave the same, I have to assume this is intentional. > > Probably not. My guess is that the Tomcat developers didn't implement it > because they didn't have a need for it. > >> My question is this: why? > > I'm fairly sure the Wildfly Servlet container is a fork of Tomcat - > hence the commonality. > >> Is META-INF/MANIFEST.MF not part of the war standard? > > It looks like it is to me. > >> I've googled, but am not enough of a java standards wonk to know >> what docs are authoritative on this topic. I've certainly seen examples >> that use it. > > I think this is worth opening a bug for. I am a little concerned about > the overhead that may be required for this. It might end up as WONTFIX.
Mark, Ok, will take your advice and open a bug as soon as I work out the correct process to do so. Whether fixed or not, it won't help me in the short-term, but am happy to try and improve the product. It's been my rock for more years than I can count. Frankly, it's a credit credit to the Tomcat crew that I've never needed to open a bug previously. Heck, I should take a swing a fixing it myself. I owe at least that much. Thanks, -- m. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
