>> 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?
> The way you told me to when we discussed this last April. It's the one
> named "admin-listener".
I am just confirming. There are two ways to get
to the admin port. One is http-listener named specifically and one is
from default the http-listeners of a virtual-server. The admin virtual
server is named "__asadmin".
It's the question of depending on the listener id or virtual-server id.
In case you don't know, there was a case where admin-listener would be
removed from domain.xml and the server, administration would still work
fine at:
http://host:8080/admin,
http://host:8080/__asadmin.
What would you do in that case? The server falls back to the http-listener
that's pointed to by __asadmin virtual server.
>
>>
>>
>>>
>>>> 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.
> Did you file a bug?
>
> I just glanced at the command I used to launch B24 an hour ago -- it
> shows javaRoot being substituted fine. What are you talking about?
>
>>
>>> ${com.sun.aas.installRoot}
>>> ${com.sun.aas.derbyRoot}
>>> ${path.separator}
> Here's another one.
>
> ${com.sun.aas.instanceRoot}
>>
>>>
>>> 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?
> Well, that depends on which property you are talking about.
>
> Certainly, the rdebug settings are a private contract between NetBeans
> and GlassFish. At such time that the Ruby Debugger in NetBeans supports
> attach functionality, this can be discussed, but I suspect at that time,
> I'll want to solve the problem in a different manner.
>
>>
>> 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.
> How about --port (or -Dhttpport=XXXX) for the http port which the
> GlassFish gem requested a year ago.
Are you the gem developer?
Anyway, there is a tool called issue tracker, file an RFE there. Can you
point me to the RFE, please?
> These ideas have been discussed
> before. It's not as simple as it sounds or presumably this would have
> been supported/fixed long ago.
Nothing is as simple as it sounds.