Kedar,
I read the "admin-user-port-separation.html" doc. Is it all
current"? I though the context root was /admingui.
Anyway, Ludo's question about defaults is a good one. How does a
client determine which server is the default one, and which http
listener is the default one? Should I be defining some constants in
the AMX API for this? Or is there a programmatic way and I should be
exposing a getDASServerName() or some such thing?
Lloyd
..............................................
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish team, LSARC member
On Sep 18, 2008, at 2:19 AM, Kedar Mhaswade wrote:
>
>
> Peter Williams wrote:
>> 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'd appreciate it if you could answer the use case question,
>> above. It's relevant to whether it's worth it to even consider the
>> sorts of problems you're hypothesizing.
>
> There's no hypothesis here.
> See https://glassfish.dev.java.net/nonav/v3/admin/planning/prelude/admin-user-port-separation.html
>
> for you to understand the use-case. Let me know (offline) if you
> don't.
>
> Also, use better editor to search of __asadmin on virtual-server in
> domain.xml.
>
>>>>
>>>> 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?
>> Yes.
>>> That may not serve any admin requests.
>> Ok, fine. I'll bite. Assume there are 4 http listeners labeled A
>> through D, 4 https listeners labeled AS through DS and no admin
>> listener. These are listed in arbitrary order in domain.xml. What
>> is the rule, if any, for determining which of those 8 to fall back
>> on when admin-listener is not found. Or is this non-
>> deterministic? How does Admin GUI handle this problem? How does
>> the user know what URL to use to launch Admin GUI in the first place?
>> You mentioned something below about a fallback listener being
>> defined in the __asadmin virtual server, but the default domain.xml
>> shows no such field. Only a reference to admin-listener, which,
>> for purposes of this discussion, you said does not exist. Did I
>> miss something?
>>> Again, I am trying to find out what you might have to rely on or
>>> what
>>> you already rely on.
>> I appreciate this, but I assumed you already knew. We discussed
>> this at length and I implemented exactly the solution we
>> discussed. I was very specific about my requirements for the
>> express purpose of avoiding the types of confusion you are now
>> suggesting could be a problem.
>>> So, this is an information gathering exercise on my part.
>> Remember, NetBeans is a *development* environment. It is *not* a
>> server administration GUI.
>
> Thanks for letting me know.
>
> Also, what specifically did we discuss?
>
>> I'm sure there are conceivable server configurations that NetBeans
>> doesn't support "out of the box". It's too expensive to support
>> them all. However, the odds of a *developer* using one of those
>> configurations *and* wanting to manipulate it with NetBeans are
>> extremely low if not zero.
>> Even then, I could probably tell such a developer some simple flags
>> or entries to change to make things work.
>> Don't forget the 80/20 rule, although in this case, it's more like
>> the 99/1 rule.
>
> OK. I don't know about the percentages. You be happy if you believe
> they
> are a ball park number.
>
>> -Peter
>>>
>>> -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
>>>
>> ---------------------------------------------------------------------
>> 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
>