Jason,
You might be getting the right VS, but that is just because you are
getting lucky. <config name="server-config" ...> happens to be first in
the domain.xml so it's <virtual-server> elements are created first so the
locator.getService(VirtualServer.class, dvs);
gets you the right one. But if you just change the order of the <config>
elements in domain.xml, then this will break.
Tom
On 4/25/13 2: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.
>
> 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