Thanks for the reading material, this is very similar to what I experienced.
From what I understand it's difficult to log the jar containing a bad Class-Path partly because of the exploded
directory structure during deployment. Maybe a log giving a path inside the exploded directory structure shall ease the
jar hunt.
Maybe this could be discussed in the issue :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=10334
/Paul
Le vendredi 16 octobre 2009 16:41:17, Tim Quinn a écrit :
> Hong Zhang wrote:
> >> Thanks Paul for letting us know. It is great to see your app
> >> deployed fine !
> >>
> >> "I had to hunt because the log message do not tell from which jar the
> >> manifest came from. ", if you have any
> >> good suggestion please help us log an enhancement.
> >
> > Yeah, if you still have the log message, please send it. We will see
> > if we could improve that message by adding the jar information.
>
> Also, please read this blog entry
>
> http://blogs.sun.com/quinn/entry/why_the_warnings_about_glassfish
>
> and see if it describes your situation. From your description it sounds
> like this is a similar issue. Note that parts of that entry refer to v2
> behavior. Even so, the underlying cause - in which a manifest refers to
> a non-existent JAR - can still occur in v3, depending of course on how
> the app is packaged.
>
> In the past I've gone back to this code and it's not a trivial one-line
> change to add the referring JAR to the error message (currently the
> referenced JAR is the only one displayed). Certainly changing this is
> possible, but it's a little bit involved and we just haven't had the
> time to get to things of this priority.
>
> Please do open an issue if you feel strongly about this.
>
> - Tim