On Jan 18, 2008, at 8:44 AM, 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?
so far they were not used. but lucky you I fixed all that in the last
few days since we finally have the web container working for simple
apps. I will check it in in a matter of minutes now
so now we open all kinds of ports like we did in v2, the __asadmin is
available on all of them.
>
> 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.
>
true and not true. it needs to be thought through but you need to
understand that things can be in a state now that does not reflect
where it will eventually end up. We cannot necessarily have all the
solutions implemented completely immediately... This is why you saw
that behaviour.
jerome
> - Kedar
>
>>>
>>> - Kedar
>>>
>>> ---------------------------------------------------------------------
>>> 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
>