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
>