On Thursday 09 February 2012 06:46 PM, John Lister wrote:
>
>>> Also the change in user.dir seems to be important especially if you
>>> are using third party jars (eg database driver). Currently I have
>>> them in the domain lib directory but just using the glassfish.jar
>>> file doesn't seem to include this in the classpath, or at least
>>> glassfish can't find them
>> Not sure what you mean here. user.dir is only useful while resolving
>> relative file URIs. They don't affect class loading.
> I have a number of 3rd party jar files in domains/domain1/lib which if
> I use asadmin are picked up correctly, but when using the
> glassfish.jar directly I get ClassNotFoundExceptions. This directory
> isn't in the classpath in either instance and I seem to remember there
> is a custom classloader that looks in here, so I'm guessing it uses
> the user.dir to derive the expected location of the above lib
> directory, but I could be wrong...
Do you have any exception stack that I can look at? I am pretty sure we
pick up jars from domain_dir/lib/ when started via java -jar glassfish.jar.
>>>
>>> Finally, the only other issue I can see with using upstart is
>>> shutting down glassfish, I was using a "pre-stop" call to "asadmin
>>> stop-domain" to terminate glassfish nicely, but this kills the
>>> process forcing upstart to respawn it thinking it died in error.
>>> What effect if any does simply kill the glassfish process have - I
>>> can imagine this isn't good in a clustered environment - or is there
>>> a way to effectively shutdown the domain while leaving the process
>>> running?
>>>
>> GlassFish process is designed to handle SIGTERM signal (which is what
>> is issued by kill command by default). So, you can issue that signal
>> to kill a glassfish process. Let us know if you see any issues with
>> that.
> I haven't seen any issues, but when stop-domain is issued, there are
> entries in the log to state it is shutting down, etc whereas using
> SIGTERM doesn't result in any additional output. This may be entirely
> normal, but I didn't want to risk some state being corrupted do to bad
> shutdown, etc
>
Do this:
java -jar glassfish/modules/glassfish.jar
Let it start and then Ctrl ^C or kill
You should see some output like
/Completed shutdown of GlassFish runtime/
Occasionally you shall see some exceptions as well, but they are
harmless. The server should be robust enough to take care of any pending
tasks during restart - if it does not, then that's a bug in the server.
How can it expect that it would be always shutdown gracefully? e.g.,
power failure or system crash.
Thanks,
Sahoo
> I appreciate your help
>
> Thanks
>
> John
>