Kedar Mhaswade wrote:
>
>>> 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?
The way you told me to when we discussed this last April. It's the one
named "admin-listener".
>
>
>>
>>> 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. These ideas have been discussed
before. It's not as simple as it sounds or presumably this would have
been supported/fixed long ago.
-Peter
>
> -Kedar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>