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
>>>>> address http://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
>>>> Blog http://blogs.steeplesoft.com
>>>
>>
>>
>> --
>> Jason Lee
>> Principal Member of Technical Staff
>> GlassFish Team
>>
>> Oracle Corporation
>> Phone +1 405-216-3193
>> Blog http://blogs.steeplesoft.com
>
--
Jason Lee
Principal Member of Technical Staff
GlassFish Team
Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com