Hi, Kedar,
I had the same issue with JVM option -verbose a while ago. It seems this
option "-verbose" is intercepted and swallowed by cli, which also has the same
option in "asadmin start-domain --verbose"
So I had to (1) add the JVM -verbose to domain.xml and (2) run "asadmin
start-domain --verbose" to get verbose info from JVM.
I also noticed jsf-api.jar is still in processLauncher.xml and in runtime
classpath, from doing my jbpm exercise. I believe in Glassfish, jsf-api
has been merged into javaee.jar.
-- Cheng
On Sat, 1 Apr 2006, Kedar Mhaswade wrote:
> Hello everyone,
> Had few questions regarding GlassFish build b42.
>
> What does the app server VM have in its classpath?
> 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.,)
>
> (BTW, another handy command is asadmin generate-jvm-report, check it out).
>
> A jar in this classpath does not even exist in
> distribution(appserv-env.jar).
>
> This is very confusing and might be having performance penalties.
>
> 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?
>
> I also observe that javadb classes needed by runtime are actually loaded
> by Extensions Class Loader. Is that intentional?
>
> Hope it is only me who needs an explanation. What document should I
> refer to?
>
> 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
>
>