Kedar Mhaswade wrote:
>
>
> 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.
Thanks for that. An AMX solution will also be welcome,
Ludo
>
> -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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>