> Think "embedded" at the shell script level. If you're packaging GlassFish
> with some larger app you might find it easier to start the server this
> way.
I disagree. First off, we do have an embedded API that helps embed GF in
its truest sense. Secondly, bigger apps must understand what doing "java -jar"
entails. They must understand the downside of launching server that way.
Calling this "embedded" is confusing and unnecessary. (e.g. you had to write
this long to explain to me what it meant to you -- how are we going to
document it?).
A bigger app or anything that bundles GF should know that "asadmin start-domain"
is the only correct way to start a GlassFish instance as a standalone VM under
given configuration, in a non-embedded manner.
Do we want to handle cases like -- "For some reason, security manager can't
be turned on" and debug it backward to arrive at the way users started their
server?
In embedded case, we have made a blanket arrangement that you, as the
owner of embedding process undertake the responsibility of setting the
environment correctly, before embedding GF.
> You really have something against "java -jar", huh? :-)
Not that way. I am not sure people think overhead of a short-lived VM (asadmin)
is unbearable. "java -jar" is "cool", but is it practical?
> Really, it's the same reason people insist on "standalone clients" instead
> of app clients. They already know how to control the "java" command, how
> to pass it arguments to configure it, etc., and they just want to be able
> to do that rather than delegate it to some script they don't understand.
>
> Ya, I don't really get it either, but I accept that it's true.
It's the development-deployment dilemma I guess. But I don't buy that startserv
is not developer friendly. Maybe people dislike domain.xml?