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