On Jan 18, 2008, at 10:22 AM, Kedar Mhaswade wrote:
>
>
> Bill Shannon wrote:
>> Kedar Mhaswade wrote:
>>>
>>>
>>> Ludovic Champenois wrote:
>>>> Kedar Mhaswade wrote:
>>>>> OK, I built V3 and then started the domain fine. I see that
>>>>> Grizzly comes up fine at port 8080. Then I deploy a war file like:
>>>>>
>>>>> "asadmin deploy --port 8080 foo.war", which successfully deploys.
>>>>>
>>>>> So, does it mean that the administrative commands are handled by
>>>>> the Grizzly listener at 8080, where user applications are
>>>>> deployed?
>>>>>
>>>>> Is this by design, or we are in process of directing asadmin
>>>>> commands
>>>>> to a separate Grizzly listener (usually at 4848, like we do for
>>>>> V2)?
>>>>>
>>>>>
>>>>> Dazed and Confused in Santa Clara :)
>>>> Why?
>>>> The admin area work needs to start on V3:). Welcome aboard.
>>>> For now, 1 single port is the easy workaround (and as a
>>>> developer, I don't mind simple things in the current prototype/
>>>> implementation: no need to understand username/password or master
>>>> password in the current V3).
>>>> Ludo
>>>
>>> It's just that it is not mentioned anywhere. I don't disagree with
>>> the intent,
>>> but it has to be made explicit. Sorry, I am not used to doing
>>> things in
>>> ad hoc manner.
>>>
>>> Having no user name and password (master password is not used in
>>> this case at
>>> all, FYI) is OK in certain cases, but not all.
>>>
>>> Also, the domain.xml has the lines
>>> <http-listener id="admin-listener" address="0.0.0.0"
>>> port="4848" acceptor-threads="1" security-enabled="false" default-
>>> virtual-server="__asadmin" server-name="" xpowered-by="true"
>>> enabled="true" family="inet" blocking-enabled="false"/>
>>>
>>>
>>> What are they for?
>>> What's the use of __asadmin virtual server? Why is it there in
>>> domain.xml by
>>> default when it is not used.
>>>
>>> Sorry Ludo, this needs to be thought through.
>> Maybe you should just assume it's not yet implemented and finish it.
>> Well, ok, "assume" is the wrong word. After checking with Jerome to
>> confirm that it's simply a case of that functionality having not
>> been
>> implemented yet, go ahead and finish it.
>
> I don't understand this mode of operation. But I will bite the bullet
> and do as expected. I am just surprised that this kind of exception
> is not
> surprising to you.
what exactly do you not understand ? That we cannot come up with a new
Appserver implementation overnight ?
If nothing has been decided, that mean we should have backward
compatibility, or status quo. If this is not the case today, it's
because it's not done or finished.
>
>
> One of my basic problems is to know what is "done" and what is
> isn't. Maybe it was just decided that we don't need a separate
> listener
> and VS for admin operations and I was just trying to understand if it
> were the interim decision.
that's fine. It is hard to know what is "done" I have to agree. Again,
if this was not discussed, consider that it does not have to be
changed so your assumption should be that this need more work.
>
>
> I believe sending an e-mail to dev alias is equivalent to checking
> with
> Jerome. Do you disagree?
I don't.
>
>
>> ---------------------------------------------------------------------
>> 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
>