Max Poon wrote:
> Hi Kedar
>
> We've got Glassbox (which uses AspectJ LTW) to be running very well on
> GlassFish with the proposed change, for our JavaOne 2007 Hands-On Lab
> 1420. You can refer to Sun Developer Network (SDN) JavaOne 2007 Online
> Hands-On Lab 1402
> <http://developers.sun.com/learning/javaoneonline/j1lab.jsp?lab=LAB-1420&yr=2007&track=5>
> for more details of our lab and configurations instructions for GlassFish.
Sorry the latest version of the lab instructions used at JavaOne is
available on Sun internal web link
http://sc-9.sfbay.sun.com/te-slides/handson2007/development/1420/jmxjconsole/
and should be available also publicly on the above SDN link in a few
more weeks from now.
>
> Btw, is there a recommended limit on the length of GlassFish's system
> classpath? Can you elaborate more on the issues regarding length of
> system classpath?
>
> Thanks
> Max
>
>
> Kedar Mhaswade wrote:
>> Max,
>>
>> I think this is a valid concern. Though I am not a 100% sure, one of
>> the reasons these classes
>> are not on the system classpath is to reduce the length of the
>> classpath which was known to
>> cause some issues. Currently, only the PELaunch and few other classes
>> are available in the system-classpath and
>> as such is loaded by the System CL. The rest is taken care of by the
>> classloading mechanism that
>> is documented extensively (Also read Sivakumar Thyagarajan's Blog).
>>
>> Frankly, I don't see any issues with this proposal. Can you give it a
>> try and see if it works?
>>
>> Kedar
>>
>> Max Poon wrote:
>>> Greetings *
>>>
>>> Is the any specific reason why JavaDB (org.apache.derby.*) classes
>>> are loaded via Extensions ClassLoader instead of System ClassLoader
>>> in GlassFish, since Extensions ClassLoader seems to be used for
>>> loading optional packages to core Java packages, mostly the javax.*
>>> classes ?
>>>
>>> >From JDK documentation on Java Extension Mechansim :
>>>
>>> "Optional packages are the new name for what used to be known as
>>> /standard extensions/. The "extension mechanism" is that
>>> functionality of the JDK and JRE that supports the use of optional
>>> packages.
>>> .......
>>> A optional package is an implementation of an open, standard API
>>> (examples of optional packages from Sun are JavaServlet
>>> <http://java.sun.com/products/servlet>, Java3D
>>> <http://java.sun.com/products/java-media/3D>, JavaManagement
>>> <http://java.sun.com/products/JavaManagement/>). Most optional
>>> packages are rooted in the javax.* namespace, although there may be
>>> exceptions."
>>>
>>> Especially in case of deploying AspectJ applications where the
>>> AspectJ weaver is loaded in GlassFish's System ClassLoader via the
>>> Java language agent (-javaagent:xxx.jar), the application classes
>>> weavable with AspectJ are limited to those which can "see" the
>>> AspectJ weaver classes and the aspects being weaved which are
>>> typically loaded in GlassFish's System ClassLoader. Loading
>>> database driver related (e.g. Derby) classes via Extension
>>> ClassLoader will render weaving on those classes not possible.
>>> This seems to be in sync with the strategy with loading of
>>> "non-core" classes via Bootstrap or Extension ClassLoader should be
>>> minimized.
>>>
>>> This will also facilitate deployment of AspectJ weaving applications
>>> on GlassFish. For example, we explicitly modified GlassFish's
>>> jvm-options to have derby jars and classes loaded via GlassFish's
>>> System ClassLoader to enable JDBC connection and statement execution
>>> monitoring by GlassBox <http://glassbox.com> on GlassFish, which may
>>> be by default enabled on other web containers like Tomcat without
>>> similar jvm-option modification needed :
>>>
>>> The following 3 additional jars are required to be entered and
>>> included in the AppServer Class Path configuration
>>>
>>> * ${com.sun.aas.derbyRoot}/lib/derby.jar
>>> * ${com.sun.aas.derbyRoot}/lib/derbyclient.jar
>>> * ${com.sun.aas.derbyRoot}/lib/derbynet.jar
>>>
>>> The following string is required to be deleted from -Djava.ext.dir
>>> JVM option
>>>
>>> * ${path.separator}${com.sun.aas.derbyRoot}/lib
>>>
>>> so that java.ext.dir is now
>>>
>>> *
>>> -Djava.ext.dirs=${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext
>>>
>>>
>>>
>>> Appreciate any comments/advice.
>>>
>>> Thanks
>>> Max