All of the html doc is current. I had sent it to admin alias more than 3
weeks ago. "/admin" has been the GUI URL when 4848 is "removed" from domain.xml
for 5 months now (post TP-2).
I agree regarding the names. I was not sure what should be made public.
I thought __asadmin virtual-server was better than
"admin-listener". Because it is not clear to clients what admin URL is, when the
"admin-listener" is removed.
If __asadmin VS is removed, nothing works anyway. So, that VS getting removed
is not a use-case we should spend a lot of time on.
Another point with parsing the domain.xml by tools was w.r.t. the imminent
change to the Grizzly config in the domain.xml (post Prelude). Thus, if you are
presented with a domain.xml that contains only the proposed (and approved)
network-config configuration of Grizzly, all of "http-listener" parsing is
irrelevant because http-listener elements won't be available in domain.xml
when that happens. Note that virtual servers are here to stay even in the
face of this change.
I am just making sure that tools team is aware of all of this.
-Kedar
Lloyd Chambers wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>