You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Matt Newell <dy...@gmail.com> on 2014/11/14 19:14:38 UTC
WebappClassLoader and MANIFEST.MF in WARs
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.
My question is this: why? Is META-INF/MANIFEST.MF not part of the war
standard? 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.
Thanks in advance,
-- m.
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Matt,
On 11/14/14 5:02 PM, Matt Newell wrote:
> 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.
This.
Seriously, /this/ is what the community is all about:
1. you get a benefit from using a community built/supported product
2. your find you have a need the product doesn't fill
3. you offer your time and skills to improve the product
4. the community benefits
5. (bonus) you get your name in the changelog
Just assume that your first patch proposal will be brutally
criticized. Don't let that cause you any hesitation to propose a
patch, rather treat it as liberating that you don't have to mull-over
your patch for weeks before submitting it. Knock-up a patch that gets
the job done and don't over-think it too much. Try to make it as
minimally-invasive as possible. Submit it as soon as you have
something and you'll get feedback. If the patch is good,
congratulations: it'll likely get applied. If the patch needs
improvement, improve it and re-submit until it's acceptable.
Do it many times and you'll be voted in as a committer. ;)
Thanks in advance for your contribution(s).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUZrF6AAoJEBzwKT+lPKRYp6QP/2YtbwY3APo0cqL/jR70Y0ML
rIskfy8WybBtIBwAxEa0h9IXw2oRTATUle1RJCjuedy7LadVvZisYiVO5hch7iWB
VbYcqeB4J9BoxnhbN8trwmraMv0n98Nc3tv7RlLxSOxae6c5ANEY2CepfYxcgAnY
PsVQAZ9v8iSZiW9tjMhjtR5cgOOBb7Oxebud82OnULi2avdnSkQIVYmHtHqYLDX+
qNWszub6Enm8P8AVLEjY6UAfRlt3ZV5qgYfLwsXzP7SggGC8asjY6cc13fukDq+C
ZexpuozTPUzxglBx+nerRpLJkgOh03auUFOoUFzsNloaJotLAZpIF9dVmfWt61Jj
IoKSiaCbQcj+8CXkbKtu1E+Y5HYt+VMQZ/ZEPfM9hI59Tp0v7np2tuLj3RVP3quZ
bnnnzaJVR+hoM18sZiuRMCnnTDCE9Wo+dUUeXvXyRAm7uHQ9R97hc5d/sogEhdzH
3MuhXoiQPKRTzwNM14nycu+QGlTkfRipMCrYQp7KxVCZoivDKZifAr/AsYe7CMWs
VESw5C2mdY50+bKDNvNKGWxtmWzM9CLqU2pAt8l/mnR0pTMO48FhC0zvjSDmLotN
TNyELHR4TpZV4ptld3thkopoh2Ms8a2VdWF5xxPxrHoAMD451X46lBL7p/z7H/eY
+tixKSbCXRSmMmp3+yZv
=uDv+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Matt Newell <dy...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Mark Thomas <ma...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Mark Thomas <ma...@apache.org>.
On 15/11/2014 00:08, Konstantin Kolinko wrote:
> 2. Please find some specification references.
JavaEE, version EE.7.2.4 DataFormats is pretty clear that a WAR file
follows the JAR specification.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Matt Newell <dy...@gmail.com>.
On Fri, Nov 14, 2014 at 7:08 PM, Konstantin Kolinko
<kn...@gmail.com> wrote:
> 2014-11-15 0:57 GMT+03:00 Matt Newell <dy...@gmail.com>:
>> On Fri, Nov 14, 2014 at 3:28 PM, Christopher Schultz
>> <ch...@christopherschultz.net> wrote:
>>> On 11/14/14 1:14 PM, 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.
>>>>
>>>> My question is this: why? Is META-INF/MANIFEST.MF not part of the
>>>> war standard? 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.
>>>
>>> If Tomcat can't/won't do this, you can always load the manifest
>>> manually (context.getResource*) and grab the Implementation-Version
>>> from it.
>>
>> Chris,
>>
>> Agreed. Ultimately I am likely to leverage some approach along these
>> lines. Just thought it was odd that tomcat didn't populate the data
>> structures I expected.
>>
>> In my particular case, however, this approach is limiting. My use case
>> is to get version information from *all* loaded wars. Specifically
>> pulling resources from ServletContext or the available ClassLoader is
>> limited to resources within the current war.
>>
>> java.lang.Package.getPackages() doesn't have this limitation, it seems
>> to pull packages loaded via all ClassLoaders. But it only works if the
>> ClassLoader populated the metadata from META-INF/MANIFEST.MF when
>> loading a class.
>>
>> Otherwise, I've got to build a startup hook into each war that reads
>> its manifest, and writes version info to some global space.
>> Properties, maybe? Ugly. But, ya do what ya gotta.
>
> 1. What if the web application does not have a war file, but is
> deployed as an expanded directory?
Personally, I don't see how our expectations would change in this
scenario. As comparison, we load classes from the same relative
location whether exploded or not. However, see below.
> 2. Please find some specification references.
> 3. If there were a manifest for the WEB-INF/classes/ I would wonder
> whether it is META-INF/MANIFEST.MF or
> WEB-INF/classes/META-INF/MANIFEST.MF. Why prefer the former rather
> than the latter? I think that none of them is applicable.
I assume the Servlet Spec (JSR-000340) is authoritative.
Unfortunately, I find it vague. Section 10.5 speaks to the directory
structure, but makes no mention of META-INF, except in the context of
an included jar. Section 10.6 describes a packaged war, and describes
META-INF, but isn't specific to it's location. From the spec:
"When packaged into such a form, a META-INF directory will be present
which contains information useful to Java archive tools."
You could read these two sections to conclude that META-INF only
applies to a packaged war, not an expanded directory. That seems an
odd conclusion, however, since more times than not, we arrive at an
expanded directory by unzipping a war, and therefore whatever was
present in the war, would be in the directory. Either way, the spec
makes no specific reference to MANIFEST.MF or the metadata within.
I'd be glad to do more reading, but I'm not sure what other docs would apply.
> 4. Are there any precedents? Discussions?
Not sure what passes for a valid precedent around here. I had a look
at jetty, which strikes me as interesting and relevant as the simplest
implementation of the servlet spec. Its WebAppClassLoader is extremely
basic. In this case it ends up delegating to
java.net.URLClassLoader.defineClass(String, Resource). This method
also defines the Package with all null metadata fields, consistent to
the behavior of Tomcat.
Given that a core java class also has the same behavior, it
strengthens the argument that this is expected. Yet, it still strikes
me as odd. java.lang.Package is significantly less useful if it isn't
populated with metadata from MANIFEST.MF.
I don't find any discussions that are particularly compelling. There
are a few here and there:
http://stackoverflow.com/questions/11139643/what-is-use-of-manifest-mf-in-war-jar-ear
http://stackoverflow.com/questions/4239368/how-to-read-manifest-mf-inside-war-application
http://blog.frankel.ch/get-the-handle-on-the-manifest-mf-in-a-webapp
Most lead towards the solution that Chris originally proposed, rather
than a discussion of the standard.
It is interesting that maven provides a plugin for creating
META-INF/MANIFEST.MF in wars:
http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html
Given the existence of this plugin, I would assume that other users
are creating META-INF/MANIFEST.MF for wars, but I have to assume
everyone is reading it back manually as a resource, rather than
relying on the various ClassLoaders populating the metadata to
Package. Which, truthfully, given this analysis, will end up being
more robust across platforms, if not the only option.
If anyone thinks there is useful investigation beyond what I've done,
I'm open to it. Otherwise, I'm inclined to let this die.
Thanks,
-- m.
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-11-15 0:57 GMT+03:00 Matt Newell <dy...@gmail.com>:
> On Fri, Nov 14, 2014 at 3:28 PM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> On 11/14/14 1:14 PM, 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.
>>>
>>> My question is this: why? Is META-INF/MANIFEST.MF not part of the
>>> war standard? 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.
>>
>> If Tomcat can't/won't do this, you can always load the manifest
>> manually (context.getResource*) and grab the Implementation-Version
>> from it.
>
> Chris,
>
> Agreed. Ultimately I am likely to leverage some approach along these
> lines. Just thought it was odd that tomcat didn't populate the data
> structures I expected.
>
> In my particular case, however, this approach is limiting. My use case
> is to get version information from *all* loaded wars. Specifically
> pulling resources from ServletContext or the available ClassLoader is
> limited to resources within the current war.
>
> java.lang.Package.getPackages() doesn't have this limitation, it seems
> to pull packages loaded via all ClassLoaders. But it only works if the
> ClassLoader populated the metadata from META-INF/MANIFEST.MF when
> loading a class.
>
> Otherwise, I've got to build a startup hook into each war that reads
> its manifest, and writes version info to some global space.
> Properties, maybe? Ugly. But, ya do what ya gotta.
1. What if the web application does not have a war file, but is
deployed as an expanded directory?
2. Please find some specification references.
3. If there were a manifest for the WEB-INF/classes/ I would wonder
whether it is META-INF/MANIFEST.MF or
WEB-INF/classes/META-INF/MANIFEST.MF. Why prefer the former rather
than the latter? I think that none of them is applicable.
4. Are there any precedents? Discussions?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Matt Newell <dy...@gmail.com>.
On Fri, Nov 14, 2014 at 3:28 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Matt,
>
> On 11/14/14 1:14 PM, 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.
>>
>> My question is this: why? Is META-INF/MANIFEST.MF not part of the
>> war standard? 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.
>
> If Tomcat can't/won't do this, you can always load the manifest
> manually (context.getResource*) and grab the Implementation-Version
> from it.
Chris,
Agreed. Ultimately I am likely to leverage some approach along these
lines. Just thought it was odd that tomcat didn't populate the data
structures I expected.
In my particular case, however, this approach is limiting. My use case
is to get version information from *all* loaded wars. Specifically
pulling resources from ServletContext or the available ClassLoader is
limited to resources within the current war.
java.lang.Package.getPackages() doesn't have this limitation, it seems
to pull packages loaded via all ClassLoaders. But it only works if the
ClassLoader populated the metadata from META-INF/MANIFEST.MF when
loading a class.
Otherwise, I've got to build a startup hook into each war that reads
its manifest, and writes version info to some global space.
Properties, maybe? Ugly. But, ya do what ya gotta.
Thanks,
-- m.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUZmXoAAoJEBzwKT+lPKRYpQgP+gPdc9rySB7Fc3/L02PuoQkj
> K9W+XLA9K/rCb9hWaS2v8EZajR/S9Vf1EvZtmjvtkoTH5U/w3J+kDfH1K/rmzePZ
> aXxJajN487Oo22IF4IKe9YafaAHdUd40hpdXuFug3RrYLSpVC/+mczrq+bvAlbMq
> VRCEWokTTNrISpekZ/Kw/iVmFUny7YC4wclCE5jt9ziHPIdPJpR2w4AmvdEkiwEv
> 3gqAlTyo7YM5Ty7NWaScA3XlB/69bZfrUhRtBuvtT7wC/Yzk42AJ8VF4xYJ+Wg+S
> PVNERXGEP+O2eRGED2ShqYHEkaxHYldNbpo1q9ozE8yh9WvToJ0pqv5Gl4Z2WrKr
> QX2tPwWuGlqzMiaSWpCf7GfUgeSdo0tEPI9LwzUW74Ra2/NyosG1bsLWIahANJnG
> 5Hu6isQzUbmetaNpn9/FO6id4vS25yICHNH+2RXgw/ekcTqTrkyCoaD7fF+qKD/S
> zikoKVaXTWwK5f2vGzoctp2SLl2PgSj3RhBUs0snxGoDPEz0Vt02xi5f7nXBS09m
> 3mdLudyP4Z7nD/fKYYu+w9vxc/hx1Y357lQi3ES2GU2dC2YjAqyiF2n8Nw2k3M0v
> UJxIb9qCyT7a38buTMRt/zLKoG4UyOy41boB6F6A/2050P6QFWLOhsBOvDW4bQlS
> oz32lftds1Y6wlsarMoh
> =09hK
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: WebappClassLoader and MANIFEST.MF in WARs
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Matt,
On 11/14/14 1:14 PM, 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.
>
> My question is this: why? Is META-INF/MANIFEST.MF not part of the
> war standard? 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.
If Tomcat can't/won't do this, you can always load the manifest
manually (context.getResource*) and grab the Implementation-Version
from it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUZmXoAAoJEBzwKT+lPKRYpQgP+gPdc9rySB7Fc3/L02PuoQkj
K9W+XLA9K/rCb9hWaS2v8EZajR/S9Vf1EvZtmjvtkoTH5U/w3J+kDfH1K/rmzePZ
aXxJajN487Oo22IF4IKe9YafaAHdUd40hpdXuFug3RrYLSpVC/+mczrq+bvAlbMq
VRCEWokTTNrISpekZ/Kw/iVmFUny7YC4wclCE5jt9ziHPIdPJpR2w4AmvdEkiwEv
3gqAlTyo7YM5Ty7NWaScA3XlB/69bZfrUhRtBuvtT7wC/Yzk42AJ8VF4xYJ+Wg+S
PVNERXGEP+O2eRGED2ShqYHEkaxHYldNbpo1q9ozE8yh9WvToJ0pqv5Gl4Z2WrKr
QX2tPwWuGlqzMiaSWpCf7GfUgeSdo0tEPI9LwzUW74Ra2/NyosG1bsLWIahANJnG
5Hu6isQzUbmetaNpn9/FO6id4vS25yICHNH+2RXgw/ekcTqTrkyCoaD7fF+qKD/S
zikoKVaXTWwK5f2vGzoctp2SLl2PgSj3RhBUs0snxGoDPEz0Vt02xi5f7nXBS09m
3mdLudyP4Z7nD/fKYYu+w9vxc/hx1Y357lQi3ES2GU2dC2YjAqyiF2n8Nw2k3M0v
UJxIb9qCyT7a38buTMRt/zLKoG4UyOy41boB6F6A/2050P6QFWLOhsBOvDW4bQlS
oz32lftds1Y6wlsarMoh
=09hK
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org