Raised issues # 531 [
https://glassfish.dev.java.net/issues/show_bug.cgi?id=531 ] and 532 [
https://glassfish.dev.java.net/issues/show_bug.cgi?id=532 ] to track
these issues
Thanks
--Siva.
Sivakumar Thyagarajan wrote:
> Hi Kedar
>
> Thanks for your comments below.
>
> Kedar Mhaswade wrote:
>
>>Hello everyone,
>>Had few questions regarding GlassFish build b42.
>>
>>What does the app server VM have in its classpath?
>
> GlassFish's server classpath [ie its -cp args] is defined by the new
> java-config attribute called "system-classpath" and is currently set as
> ${com.sun.aas.installRoot}/lib/appserv-launch.jar. This is technically
> the only jar in the system classpath of the AS VM process.
>
>
>>When the app server starts, it has -cp
>>[install-dir]/lib/appserv-launch.jar,
>>whereas when I connect to app server through JConsole, it shows that
>>Class path (this is how it is labeled) is a bunch of jars several of which
>>are not even relevant to the GlassFish/Platform Edition *runtime* (e.g.
>>admin-cli.jar, appserv-upgrade.jar etc.,)
>>
>
> This is a bug and it happens because we set java.class.path [after we
> start the AS process with appserv-launch.jar] in PELaunch [1] to
> maintain backward compat for a JSPC issue. However now that the JSPC
> issue has been fixed this could ideally be removed. I shall raise a bug
> for this and fix for GlassFish.next as there are no major issues with
> this behavior.
>
>
>>(BTW, another handy command is asadmin generate-jvm-report, check it out).
>>
>
> This is cool and works great :)!
>
>
>>A jar in this classpath does not even exist in
>>distribution(appserv-env.jar).
>>
>
> This jar was probably removed mid-way and we haven't updated the
> processLauncher.xml list.
>
>
>>This is very confusing and might be having performance penalties.
>
> I agree and would include this in the issue. I don't think this would
> cause any discernible performance issues though.
>
>
>>Also, when I added -verbose:class in the jvm-options and started the
>>app server, it was not evident from server.log what class loader
>>loads what class. Is every *class* loaded on demand?
>>
>
> This should get fixed by Cheng Fang's response in this thread.
>
>
>>I also observe that javadb classes needed by runtime are actually loaded
>>by Extensions Class Loader. Is that intentional?
>
> This was probably not intentional, but was done following our earlier
> documentation in AS8.x that users need to place their JDBC drivers in
> domain-root/domain-name/lib/ext which is automatically added by
> application server to java.ext.dirs. We also had a bug fixed in
> GlassFish [around b40] that would allow users to place their jdbc
> drivers in domain-root/domain-name/lib [which scopes that jar in the
> common classloader], so we could move the java db/derby jars from
> extension classloader down to the common classloader. I can raise an
> issue for this.
>
>
>>Hope it is only me who needs an explanation. What document should I
>>refer to?
>>
>
> The current GlassFish documentation has a good overview on the
> classloader hierarchy [2] of AS9.0 and where a user could place his
> libraries to scope it correctly. June Parks is also working with me on
> updating this document, so we should have some updates to the current
> document soon. As always, welcome your and other's inputs on the doc.
>
> Thanks again for your inputs.
>
> Thanks
> --Siva.
> [1]
> http://fisheye5.cenqua.com/viewrep/glassfish/appserv-core/src/java/com/sun/enterprise/server/PELaunch.java?r=1.16#l298
> [2] https://glassfish.dev.java.net/nonav/javaee5/docs/DG/beade.html
>
>>Thanks,
>>Kedar
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>