Kohsuke Kawaguchi wrote:
> kedar wrote:
>>>
>>> I've been asking Glassfish guys to give me ways to start/stop the
>>> container more easily, but so far they haven't given it to me :-(
>>>
>> One step at a time, and we all are "GlassFish guys".
>> We have now eliminated few extraneous processes that asadmin
>> start-domain
>> used to create. So, the startup is a bit better.
>> The shutdown of the GlassFish server is even better and faster.
>
> That's a good news. Which version of GF includes this change?
Being tested. Shortly, there will be a notification sent.
The improvements to "asadmin stop-domain" are in recent builds.
>
>> (Thanks to Byron Nevins).
>>
>> Moving on to next thing -- being able to just call a method in an
>> existing
>> JVM is on our agenda. You've got to wait. If you have any suggestions
>> about
>> how it could/should be done, feel free to discuss them at
>> admin_at_dev.glassfish.java.net.
>
> I think the immediate goal could be just a simplified launcher script
> that doesn't fork more than one process and doesn't rely on million
> system properties (assuming that this can be done much quickly than
> true embedded container support) --- something as good as Tomcat, if
> not as good as Jetty.
>
> I say this because not being able to reliably invoke another Java
> process that hosts GF is the biggest show stopper right now. As long
> as Cargo can work reliably, I don't think people like Konsuli would
> mind using it, even if Cargo internally has to do some ugly stuff. It
> gets the job done, after all.
>
I agree. The System Properties are ugly (in this context) and they
simply don't go
away. This is a major obstacle in doing progress.
> Today, it does not work reliably, as we discussed some time ago in
> various bugs, and that's a show-stopper problem IMO.
>
Well, "asadmin start-domain" and doing a Runtime.exec() on it
works "equally reliably", as long as the caller of "asadmin
start-domain" does
some due diligence (redirection of streams, e.g.).
So, I guess I need your help in understanding
why there is a reliability issue here. I agree and accept that
invoking a short-lived script that invokes the long running app server
VM needs a replacement, but I hope reliability is not at stake here.
Can you point me to a location where "asadmin start-domain" works reliably
and Runtime.exec() of it doesn't?
Believe me, we understand the implications of this. Being able to start
server in a given VM is something that we do think (a lot) about.