Peter Williams wrote:
>
>
> Kedar Mhaswade wrote:
>>
>>>> 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 is the use case for this? Are developers expected to work with a
> server configured thusly? Is this a supported configuration?
>
> I don't think virtual servers were supported in V3 at the time our
> startup code was written so no, this is not handled. In this case,
> there will be no admin port. I suspect we will default it 4848 in this
> case and the plugin will be relatively broken. The user could update
> the port manually in the instance attributes, but would not likely know
> where to do that (no UI for that at the moment).
>
> We could direct the code to use the http port when the admin port is not
> found. That might be better.
>
What if there are 4 listeners? You would take the first one?
That may not serve any admin requests.
Again, I am trying to find out what you might have to rely on or what
you already rely on. So, this is an information gathering exercise on my part.
-Kedar
> -Peter
>
>>
>> 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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>