Hi Jason,
This is my observation with the patch you sent out earlier.
If I start the domain with default domain.xml (no change to the
domain.xml <virtual-server id="__asadmin"
network-listeners="admin-listener"></virtual-server>),
I see
http://localhost:4848 -> GF index.html (INCORRECT)
Also, I cannot stop the domain using asadmin stop-domain with
"glassfish4/glassfish/domains/domain1 is not running" although I see the
process running.
If I explicitly add "hosts="localhost, test1" to "__asadmin" virtual
server (<virtual-server id="__asadmin" hosts="localhost, test1"
network-listeners="admin-listener"></virtual-server>),
it looks like admingui gets loaded in the server.log,
[2013-04-26T10:33:33.651-0700] [glassfish 4.0] [INFO]
[AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=115
_ThreadName=Thread-13] [timeMillis: 1366997613651] [levelValue: 800] [[
Loading application [__admingui] at [/]]]
[2013-04-26T10:33:33.652-0700] [glassfish 4.0] [INFO] [NCLS-CORE-00022]
[javax.enterprise.system.core] [tid: _ThreadID=115
_ThreadName=Thread-13] [timeMillis: 1366997613652] [levelValue: 800] [[
Loading application __admingui done in 5,697 ms]]
However, the browser only shows the admin console loading page and
doesn't get redirected.
GlassFish Server Administration Console
*Welcome to BG Server 4.0 (build aroh-private).*
Status indicator image. *Status:* The Admin Console application is loaded.
If the browser does not refresh the page automatically please reload the
page.
Is this what you are observing? Do you know what admin console is
"loaded" but does not get redirected to admin console page?
Amy
On 4/25/13 2:20 PM, Jason Lee wrote:
> On 04/25/2013 03:50 PM, Amy Roh wrote:
>> On 4/25/13 12:00 PM, Jason Lee wrote:
>>> As best as I can tell, it's returning the correct VS. I think
>>> everything is working as expected except the console, as I noted,
>>> but I can't figure out why not. I need some input from the web
>>> container group. The system-application is installed, but, for some
>>> reason, the system still hands the request to the
>>> AdminConsoleAdapter, rather than the web container. I'm guessing
>>> that's happening somewhere in ContainerMapper, but I haven't been
>>> able to ascertain where or why.
>>
>> Don't we want to keep the same behavior of handing over admin
>> requests to the AdminConsoleAdapter but modify the
>> AdminConsoleAdapter so that it allows access based on the --hosts
>> value of "__asadmin" virtual server? Can you explain why we want web
>> container to handle admin requests now to fix 18235?
> As I understand things, once the Console app is installed and loaded,
> the AdminConsoleAdapter is never accessed again until the server is
> restarted. Once the app is up and running, the web container handles
> those requests. That being the case, we can't put these restrictions
> in this Adapter, as they will be bypassed once the app is running. I
> tried that approach, and it doesn't work.
>
>> The changes in V3Mapper seem to undo the fix for
>> https://java.net/jira/browse/GLASSFISH-5664. IMO, we should continue
>> to not register any admin related artifacts on a non-admin listener
>> as this will cause issues. In general, web container handles
>> "__asadmin" virtual server and "admin-listener" network-listener
>> differently from standard virtual servers/network listener/web module.
> For the time being, since we're changing the name of the "virtual
> server" we're storing, I've disabled those checks to make things
> simpler. Once (and if) we get the overall change working as requested
> by the user, I'll reenable and clean up those checks to handle things
> appropriately for the final state of the change. For now, it's just
> easier to disable those and worry about them down the line a bit.
>
>> Amy
>>>
>>> I've attached the current state of the change. I'll keep poking, but
>>> I could use another set of eyes.
>>>
>>> On 04/24/2013 10:04 AM, Tom Mueller wrote:
>>>> Great work Jason and Ryan.
>>>>
>>>> On 4/24/13 9:52 AM, Jason Lee wrote:
>>>>> Here's the current status and diff for this issue. With the
>>>>> attached diff, asadmin and REST traffic are restricted as
>>>>> expected. For this configuration (with localhost, test1, and
>>>>> test2 all resolving to 127.0.0.1):
>>>>>
>>>>> <virtual-server id="__asadmin" hosts="localhost, test1"
>>>>> network-listeners="admin-listener"></virtual-server>
>>>>>
>>>>> *host/operation*
>>>>> *REST**
>>>>> * *Console**
>>>>> * *asadmin*
>>>>> *localhost*
>>>>> Expected response
>>>>> 200 with empty body
>>>>> Expected response
>>>>> *test1*
>>>>> Expected response 200 with empty body
>>>>> Expected response
>>>>> *test2*
>>>>> 404
>>>>> 404
>>>>> 404/Command failed
>>>>>
>>>>>
>>>>> There seems, then, to be more work done on the web-glue side to
>>>>> make this correct.
>>>> When you say "200 with empty body" for the Console, does that mean
>>>> that console access is still not working? i.e., is there a missing
>>>> "to be" in the sentence above?
>>>>
>>>> Regarding the diffs, please take a look at
>>>> + VirtualServer vs = locator.getService(VirtualServer.class, dvs);
>>>>
>>>> There could be multiple virtual servers with a given name in
>>>> different configs. In fact there are 2 by default with the name
>>>> __asadmin, one in server-config and one in domain-config. So this
>>>> line might not fetch the right VirtualServer.
>>>>
>>>> Thanks.
>>>> Tom
>>>>
>>>>>
>>>>> One final point: with the current state of this diff, if the
>>>>> virtual-server configuration is left with its defaults, nothing
>>>>> seems to work. I'll try to figure that out once the issues above
>>>>> are ironed out.
>>>>>
>>>>> Many thanks, by the way, to Ryan Lubke for his help on this issue.
>>>>>
>>>>>
>>>>> On 04/19/2013 10:40 AM, Jason Lee wrote:
>>>>>> Per Shreedar's request, attached is the diff of my current attempt to
>>>>>> addresshttp://java.net/jira/browse/GLASSFISH-18235
>>>>>>
>>>>>> The changes in addHost() and addContent() is a less than elegant attempt
>>>>>> to work around the sanity checks mentioned in the source comments.
>>>>>> Ideally, we'd probably pass the VS in, but these methods override those
>>>>>> in the Grizzly base class, so it's not that simple, it seems, but
>>>>>> something that can be addressed once we make it work.
>>>>>>
>>>>>> At any rate, the net effect of this change so far is that all traffic to
>>>>>> port 4848 (Console, REST, and Asadmin) returns a 404, for reasons I've
>>>>>> not yet been able to determine. If anyone has any tips, I'm all ears. :)
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jason Lee
>>>>> Principal Member of Technical Staff
>>>>> GlassFish Team
>>>>>
>>>>> Oracle Corporation
>>>>> Phone +1 405-216-3193
>>>>> Bloghttp://blogs.steeplesoft.com
>>>>
>>>
>>>
>>> --
>>> Jason Lee
>>> Principal Member of Technical Staff
>>> GlassFish Team
>>>
>>> Oracle Corporation
>>> Phone +1 405-216-3193
>>> Bloghttp://blogs.steeplesoft.com
>>
>
>
> --
> Jason Lee
> Principal Member of Technical Staff
> GlassFish Team
>
> Oracle Corporation
> Phone +1 405-216-3193
> Bloghttp://blogs.steeplesoft.com