Hi Max
Thanks for the suggestion below. It does appear fine, however I am not an
expert in this area. Jie Leng [copied] handles logging and so, Jie might be
able to help us here.
Thanks
--Siva.
Max Poon wrote:
> Hi Sivakumar
>
> I just revisit the enclosed issue and think that we can consider the
> following :-
>
> (1) GlassFish starts up with something like :
>
> "-Dcom.sun.enterprise.server.logging.manager=com.sun.enterprise.server.logging.ServerLogManager"
>
> instead of
>
> "-Djava.util.logging.manager=com.sun.enterprise.server.logging.ServerLogManager"
>
>
> (2) GlassFish tries loading what is referenced by
> "com.sun.enterprise.server.logging.manager", if successful, use it as
> "java.util.logging.manager"
>
> try {
> cname = System.getProperty("com.sun.enterprise.server.logging.manager");
> if (cname != null) {
> Class clz = ClassLoader.getSystemClassLoader().loadClass(cname);
> manager = (LogManager) clz.newInstance();
> }
> } catch (Exception ex) {
> System.err.println("Could not load Logmanager \"" + cname + "\"");
> ex.printStackTrace();
> }
> if (manager == null) {
> manager = new LogManager();
> }
>
> So that
>
> (a) any application (e.g. AspectJ weaver applications) loaded in System
> CL (without any visibility to GlassFish's classes) can still use JDK
> Logging with its own designated LogManager
>
> (b) GlassFish can use its own
> com.sun.enterprise.server.logging.ServerLogManager
>
> I guess this involves minimal code changes to GlassFish while solving
> the enclosed problem we have.
>
> What do you think? Which GlassFish sources are needed to be changed?
>
> Thanks
> Max
>
>
> Max Poon wrote:
>> Hi Sivakumar
>>
>> Thanks for your input! I've got it "working" by :
>>
>> 1. specifying in domain.xml the <java-config> <jvm-option>
>> "-Dorg.aspectj.tracing.factory=org.aspectj.weaver.tools.CommonsTraceFactory"
>> - to tell aspectjweaver.jar (loaded in GF's System Class Loader)
>> to use commons logging instead of GF's default log manager
>> com.sun.enterprise.server.logging.ServerLogManager which is
>> loaded in GF's Shared Chain Class Loader and hence not
>> accessible from GF's System ClassLoader (hence the previously
>> observed ClassNotFoundException).
>> 2. adding locations of commons-logging-1.1.jar and log4j-1.2.14.jar
>> to GF's system classpath
>> - so that Commons Logging can see Log4j before looking for and
>> then using JDK1.4 Logging (which then tries to load
>> com.sun.enterprise.server.logging.ServerLogManager and throws
>> the ClassNotFoundException, as per testing)
>>
>> To summarise, as aspectjweaver.jar has to be specified via
>> "-javaagent:" jvm option and loaded via System Class Loader, make the
>> classes in aspectjweaver.jar access alternative logging accessible
>> from the System Class Loader, instead of GF's default log manager
>> com.sun.enterprise.server.logging.ServerLogManager.
>>
>> This approach may be applicable to other AspectJ applications (with
>> classes required to be accessed directly by AspectJ's Load-Time
>> Weaver) running on GlassFish, given that those classes are/can be
>> packaged in known jar files to be included in GF's System Classpath.
>>
>> Not sure whether this is the best approach. Any better
>> idea/solution/comment much welcome.
>>
>> Actually, I have been trying to have GlassBox Inspector running on
>> GlassFish (v1 & v2), and would like to thank you as well as Ron Bodkin
>> of GlassBox (cc'ed) for all the input and help.
>>
>> Thanks
>> Max
>>
>>
>> Sivakumar Thyagarajan wrote:
>>> Hi Max
>>>
>>> Responses inline. Thanks.
>>>
>>> --Siva.
>>>
>>> Max Poon wrote:
>>>> Hi Sivakumar
>>>>
>>>> Thanks! Some comments on your suggestions :
>>>>
>>>> 1) Putting required logger classes/jar in web app - This seems not
>>>> helping as the problem is on accessing classes loaded by the
>>>> children class loaders (CL) from the System CL (via "-javaagent:"
>>>> jvm option), not from the Web CL or App CL. Kindly advise if I
>>>> understand correctly.
>>>
>>> Probably I should have been a bit more clearer. I was suggesting
>>> bundling the LogManager classes along with aspectjweaver.jar you
>>> specify in the -javaagent option. That way the logManager would also
>>> be loaded as part of the system classloader and AspectJ runtime would
>>> be able to load the LogManager.
>>>
>>>>
>>>> 2) I just notice : it seems that Application Class Loader (CL) is
>>>> involved in the exception causing execution stack:
>>>>
>>>> Could not load Logmanager
>>>> "com.sun.enterprise.server.logging.ServerLogManager"
>>>> java.lang.ClassNotFoundException:
>>>> com.sun.enterprise.server.logging.ServerLogManager
>>>> ...
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>>> at
>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>>> ...
>>>> at org.aspectj.weaver.loadtime.Agent.<clinit>(Agent.java:33)*
>>>>
>>>> Questions:
>>>>
>>>> (a) as the "-javaagent:<aspectjweaver.jar>" jvm option requires
>>>> loading by System CL, why is AppCL involved?
>>>
>>> The name is probably a misnomer [or probably confusing in a J2EE
>>> appserver context]. It is not ApplicationClassLoader [as in J2EE
>>> application classloader] but sun.misc.Launcher$AppClassLoader. This
>>> is the Sun JVM's representation of what is referred to as the System
>>> classloader.
>>>
>>>>
>>>> (b) if AppCL is used, then GlassFish should be able to load
>>>> com.sun.enterprise.server.logging.ServerLogManager (in
>>>> appserv-rt.jar) via delegating up to the Shared Chain CL per
>>>> GlassFish default behavior. Then, why was the above exception thrown?
>>>>
>>>
>>> Hope the explanation above helps. It is system classloader and so the
>>> ServerLogManager is not visible to that classloader as it loaded
>>> below in the hierarchy.
>>>
>>>
>>>> Thanks again!
>>>> Max
>>>>
>>>>
>>>> Sivakumar Thyagarajan wrote:
>>>>> Hi Max
>>>>>
>>>>> > _Questions
>>>>> ..
>>>>> >
>>>>> > 1. how can we have the classes specified via *-javaagent:*
>>>>> able to
>>>>> > load those classes (e.g. in Shared Chain CL) available
>>>>> lower down
>>>>> > in the CL hierarchy (coz' it may not be feasible to put
>>>>> everything
>>>>> > in System CL) ?
>>>>>
>>>>> As you have mentioned already in your analysis, this is because
>>>>> aspectjweaver loaded by the system classloader cannot see classes
>>>>> loaded lower in the hierarchy such as the Logging Manager and AFAIK
>>>>> there is no easy fix for this.
>>>>>
>>>>> No easy fix because the static block at
>>>>> java.util.logging.LogManager tries to load using both the
>>>>> SystemClassLoader and the Thread context classloader (which at the
>>>>> time of initialization of the PreMain class is not set to a
>>>>> classloader that can load the specified loggingmanager) and both
>>>>> would not be able to load the loggingmanager.
>>>>>
>>>>> Unfortunately, while we did the earlier classloader changes in
>>>>> GlassFish v1, we tried to move our logging manager
>>>>> [com.sun.enterprise.server.logging.ServerLogManager] higher up in
>>>>> the hierarchy [to be placed with appserv-launch.jar] but it had
>>>>> dependencies on a whole lot of other appserv-rt.jar classes and
>>>>> hence couldn't get this out.
>>>>>
>>>>> Possible Workarounds:
>>>>> - I don't have the soruces for Aj/JDK14Trace. Is there a way to
>>>>> disable AspectJWeaver logging? ie an option to not have this done
>>>>> at all
>>>>>> at java.util.logging.Logger.getLogger(Logger.java:274)
>>>>>> at org.aspectj.weaver.tools.Jdk14Trace.<init>(Jdk14Trace.java:25)
>>>>>> at
>>>>>> org.aspectj.weaver.tools.Jdk14TraceFactory.getTrace(Jdk14TraceFactory.java:17)
>>>>>>
>>>>>> at org.aspectj.weaver.loadtime.Aj.<clinit>(Aj.java:32)
>>>>> If yes, we could use that as a temproary workaround
>>>>>
>>>>> - AspectJ weaving using WeavingURLClassLoader.
>>>>>
>>>>> - use a custom server log Manager. I know this is not supported but
>>>>> if the custom log manager is bundled with the aspectjweaver class
>>>>> or specified in the system classpath this would help aspectjweaver
>>>>> to continue to load.
>>>>>
>>>>> If none of these help, someone from the admin team could let us
>>>>> know if it would be possible to separate out our LoggingManager, so
>>>>> that this could be moved higher up in the classloader hierarchy.
>>>>>
>>>>> > 2. can we override *java.util.logging.manager* within
>>>>> > context/execution of our web apps (vs that set during
>>>>> glassfish
>>>>> > initialisation) so it points to something available with
>>>>> the web
>>>>> > apps (e.g. apache commons logging, log4J, etc) ?
>>>>>
>>>>> For log4j style configuration for a web app, does this help?
>>>>> https://glassfish.dev.java.net/servlets/ReadMsg?list=users&msgNo=590
>>>>>
>>>>> > Adding to domain.xml the jvm-option :
>>>>> >
>>>>> > * -Dcom.sun.aas.useNewClassLoader=false
>>>>> >
>>>>> > to try to disable the new Shared Chain Class Loader does not seem
>>>>> to help.
>>>>>
>>>>> This was more of a internal temporary flag we introduced during
>>>>> GlassFish v1 days. This may be broken. I shall check this. If this
>>>>> is fixed, this would be a workaround as well :)
>>>>>
>>>>> Thanks
>>>>> --Siva.
>