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.
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