Shing Wai? Amy? Any thoughts on this?
On 04/25/2013 04: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
>>>>>> 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
--
Jason Lee
Principal Member of Technical Staff
GlassFish Team
Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com