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.
>>
>> 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.
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.
-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
>