quality@glassfish.java.net

Re: WAR DeploymentContext needing EJBs o_O ?

From: Tim Quinn <Timothy.Quinn_at_Sun.COM>
Date: Fri, 16 Oct 2009 10:14:03 -0500

Paul MERLIN wrote:
> Thanks for the reading material, this is very similar to what I experienced.
>
In fact you're right, they are very similar but they are happening in
two different places, now that I see the log messages you are getting
(which you reported in the issue - thanks).

In your case the scanning process is triggered by Jasper's processing.
In the blog entry the scanning is triggered by the presence of an app
client in the application.

Quite different circumstances but the same underlying cause.

My earlier comment about the referring JAR not being handy in the code
is definitely correct for the app client case; I'm not sure about the
Jasper case.

- Tim
> 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
>>