fingerprint.jsp (was Re: I hate axis because..)

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Brian Ewins" <Br...@btinternet.com>
To: <ax...@xml.apache.org>
Sent: Wednesday, August 07, 2002 03:59
Subject: Re: I hate axis because...


> happyaxis.jsp is a big step towards helping with peoples install
> problems, but I'd prefer if it was the index.jsp though. Saying in the
> manual: "You must not proceed until all needed libraries can be found,
> and this validation page is happy" just passes people by.

that may be something todo, especially if we can tease out a discrete,
self-contained happy test that can be stuck on the start page, so that if
all is well the user sees nothing but what they get today.

>
> The classpath(s) and the various xml parsers on them are most often the
> problem; I'm wondering if would help to provide some easy way to
> 'fingerprint' your system, so people could easily pass on info about
> what they know to be a working setup, people with problems can more
> easily supply info about their env with their question, and you should
> even be able to 'diff' environments.
>
> Rather than just talk about this, I've attached a JSP which allows you
> to do exactly this. Originally I intended for this to dump out jvm
> versions too, and read in a separate properties file which identifies
> jar versions by their names and sizes, eg
> 'jdom.jar(126898)=JDOM-beta-8'. But you can see how it works (just drop
> it into a webapp).
>
> The differences between this and happyaxis are that it doesnt attempt to
> identify problems, it provides info on whats on your classpath that's
> _not_ getting picked up, as well as attempting to identify versions. If
> the axis folk want to use this code in any way, be my guest.

This is cool. I've just committed a version with
-tabs to spaces
-tabular output
-datestamp of files
-refactored presentation (makes it easier to move to an XML output)

The best way to do versioning is to look in the JAR manifests and extract
the strings from there. if you write that, I will happily commit it.

still todo: link to this from the start page. We could leave it for
reporting (and move the property enum there), so that when someone reports
trouble we can ask for the fingerprint.

Other things to add would probably include: jre, server engine identity and
versions.

-Steve

Re: fingerprint.jsp (was Re: I hate axis because..)

[Brian Ewins <Br...@btinternet.com>]

Steve Loughran wrote:
>>
> This is cool. I've just committed a version with
> -tabs to spaces
sorry about that, I'm afraid I hacked it up in notepad...netbeans was 
taking too long to start.

> -tabular output
> -datestamp of files
> -refactored presentation (makes it easier to move to an XML output)
> 
> The best way to do versioning is to look in the JAR manifests and extract
> the strings from there. if you write that, I will happily commit it.

Steve, I added that to the program last night (following the versioning 
spec, 
http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningSpecification.html 
). Unfortunately the results are worse than useless. I was using 
Package.getImplementationVersion() and the like. Unfortunately it seems 
like noone apart from the log4j project is writing meaningful manifests! 
I took this out, but could write it again quickly; I don't think its 
worth it though as I wasnt getting anything useful. Obviously if I was 
to do this again I'd use Manifest.getEntry() so we can get results for 
each individual jar.

I added datestamps too, but I took the most recent stamp of entries in 
the jar file, since they're more reliable (since if you make a copy of a 
jar the internal timestamps don't change).

Out of curiosity I also added some code which tries to figure out what 
jars are in use; it constructs the URL for each jar entry, then looks up 
the bare entry in the current classloader, and compares the resulting 
URL. It was interesting enough, but I don't think it accurately 
represents the problems people actually have with classloaders (namely 
that its not what they can't see, its that the things they can see can't 
see each other), and diagnosing that involves parsing .class files. A 
bit much for a single JSP ;) . Anyway, it moves away from being the 
'fingerprint' tool I wanted.

> still todo: link to this from the start page. We could leave it for
> reporting (and move the property enum there), so that when someone reports
> trouble we can ask for the fingerprint.
> 
> Other things to add would probably include: jre, server engine identity and
> versions.
> 
> -Steve
> 

Yup, via system properties and this.getServletContext().getServerInfo(). 
The os/platform is also useful. I originally had code in which dumped 
out all system properties, but this is no good as a fingerprint: 
anything which includes absolute paths  introduces meaningless 
differences between setups. I also need to scan the appropriate 
directories for different servers[1].

If you still want me to do anything more to this, send me your latest 
copy and tell me what you'd like done. I'm happy to work on this some 
more as our support guys think they'll find it useful.

-Baz

[1]
As far as I know...
TC 3.2  start from system property 'tomcat.home', scan 'lib'
TC 3.3  start from system property 'tomcat.home', scan 'lib/container', 
'lib/common'
Resin  start from system property 'resin.home', scan 'lib'
Orion  don't know if I can get 'orion.home'? From docs, looks like 
orion.home itself, and orion.home/lib should be scanned.
Weblogic 5.3 scan weblogic.httpd.servlet.classpath (can anyone confirm 
if this is still the case?)
.... and so on.