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
>