Hi Amy,
On 04/ 9/09 02:41 PM, Amy Roh wrote:
> Kedar Mhaswade wrote:
>> Not sure, Jan.
>>
>> This seems related to admin-console being deployed at the "root"
>> context of __asadmin virtual server.
>>
>> If I understand org.glassfish.api.container.Adapter correctly, only
>> the requests to host:4848/admin ("/admin" is the context-root of
>> AdminConsoleAdapter) should result in a call to its service method.
>> So, I
>> am not quite sure why host:4848/testwebapp be routed to it.
>
> That is my question exactly. The requests to host:4848/testwebapp
> shouldn't even invoke AdminConsoleAdapter and its service(). However,
> the first request (only first) to host:4848/testwebapp always invokes
> AdminConsoleAdapter.service(). In fact, the __admingui is loaded when
> the first request to host:4848/testwebapp is sent (on demand).
>
> After sever start and deploying testwebapp,
>
> virtual-server server has loaded __default-web-module and testwebapp
> virtual-server __asadmin has no webmodules loaded
>
> The first request to host:4848/testwebapp invokes
> AdminConsoleAdapter.service and installs admin console (__admingui is
> finally loaded on __asadmin)
>
> I'm trying to find the code where host:4848/... is mapped with
> AdminConsoleAdapter.
This is done in GrizzlyService#registerAdminConsoleAdapter.
I think the behaviour you have observed is expected, at least for the
most part.
The admingui is deployed at the root context of the corresponding
virtual server, and consequently, the AdminConsoleAdapter is also
registered at the root context of port 4848, since it is responsible
for intercepting any requests to the admingui.
When you first issue a request to port 4848, there is no way to tell
whether the requested resource actually exists, since the admingui has
not yet
been deployed.
http://localhost:4848/TestWebapp
might actually map to a servlet of the admingui - who knows!
Only once the admingui has been deployed is it possible
to tell whether the requested resource exists in the admingui,
and return the appropriate response code.
However, I don't think returning a 200 initially is the right thing to
do, since it is confusing when it is followed by a 404.
Perhaps a 202 response might be more appropriate? It is defined as follows:
The request has been accepted for processing, but the processing has
not been completed.
If that would be an acceptable return value, then we should change our
unit test that uncovered the issue to expect either a 404, or a 202
followed by a 404.
Does the admingui team have any opinion on this?
Thanks,
Jan