>> I'm only slightly concerned about reading the domain.xml file to find
>> the port number; as others have said it's pretty close to a public
>> interface already.
> I actually think reading the http, ssl, and admin port numbers correctly
> is more difficult than locating and patching the JVM config options.
> The parsing code I wrote is quite flexible so if the rules on how to
> locate this information changed, it ought to require only a minor update
> to fix.
Does it mean you rely on the id's of the http-listeners? If that's the
case, we better agree upon those id's as well. e.g. How do you decide
that the "admin port" is 4848 in your parsing sequence?
>
>> I was more concerned about the "substituting a
>> few variables" part. Getting that to behave exactly the same way it
>> does in the GlassFish code could be more problematic.
> I'm not sure what you mean unless it's ensuring we have the same
> definitions for the variables.
>
> The list so far is merely
>
> ${com.sun.aas.javaRoot}
I don't think this is currently respected.
> ${com.sun.aas.installRoot}
> ${com.sun.aas.derbyRoot}
> ${path.separator}
>
> which are all well defined. If the user adds additional fields the
> plugin does not recognize, there is a way to provide that information to
> the plugin so things still work correctly. A single method is
> responsible for handling arbitrary substitutions on each config
> parameter and is easily unit tested.
>
<skip>
> On the original topic of "why do we need/want to invoke java -jar
> directly), here's further information:
>
> It is helpful (and relied upon currently, or will be as soon as Vince
> fixes it) to use an arbitrary debug port defined by the plugin for JVM
> debugging rather than the setting hard coded into domain.xml.
> Otherwise, we will have to either (a) possibly update domain.xml with a
> new debug port just before starting the server if the current
> designation is busy or (b) ensure all registered server instances have
> unique debug ports (and then we still have a problem (a) if the port is
> busy for other reasons). The alternative is (c) debugging fails because
> the port is in use, which is a poor excuse on our part.
> We also add additional JVM -J-D options beyond what is in domain.xml.
> For example, injecting ruby debug parameters for use by the JRuby
> Adapter to enable ruby debugging.
Would a user require these additional settings even when the server is
started outside of the IDE?
It looks to me that there is a legitimate need for passing additional
system properties on asadmin start-domain command line. e.g.
asadmin start-domain [--sysprops -Dfoo=bar,-DDebugPort=9111] ...
so that all these system properties are set in the server VM before
it starts up. I will file this as an RFE.
-Kedar