ha! yep! domain.xml has the forced *and* default response type to
text/plain. I'll change that to text/html in the template unless
someone minds... The default values in the java interfaces are
text/html already.
Justin Lee wrote:
> I will double check that. Just as soon as IDEA is done rescanning
> every file I've ever saved to my hard drive. :)
>
> Jeanfrancois Arcand wrote:
>>
>>
>> Justin Lee wrote:
>>> I finally tracked it down thanks to a hint from jfa. I went back to
>>> the grizzly code to try to isolate the failure. When I extended my
>>> test case there I found that grizzly was indeed crossing the streams
>>> (http://is.gd/dpRx). I tracked down that failure to an errant reuse
>>> of the Controller instance being used. Giving each SelectorThread
>>> its own Controller fixed that problem. Back in glassfish land, I
>>> tracked down the same issue there and I'm finally seeing both web
>>> apps at their expected ports. The admin listener correctly pulls up
>>> the admin webapp on 4848 and on 8080 i get the "it works!" page.
>>>
>>> One last issue there and I think we'll have this thing licked. It
>>> returns that page with the content type of text/plain instead of
>>> text/html so I see the source of the page rather than the rendered
>>> version. Any idea why that would be happening? I'll keep digging...
>>
>> OK that means the SelectorThread.setDefaultResponseType get invoked
>> with the text/plain value (which is probably taken from domain.xml
>> http protocol). Could it be?
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>>
>>> Oleksiy Stashok wrote:
>>>> Hi Justin,
>>>>
>>>>> I have breakpoints set in ContainerMapper.map(), both Mapper.map()
>>>>> methods, and ProcessorTask.parseRequest() and it never stops...
>>>> First of all you can try to check if GrizzlyProxy is got built
>>>> properly within GrizzlyProxy.configureGrizzly(...) method.
>>>> Please check that port number is passed correctly, and we create
>>>> new Mapper for a new port.
>>>>
>>>>> Where should I set a break point to watch the incoming requests?
>>>>> When watching the set up, I noticed that it uses the default
>>>>> algorithm of NoParsingAlgorithm. Could that be a problem?
>>>> NoParsingAlgorith is fine.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>>> Justin Lee wrote:
>>>>>> I'm not *100%* sure but it all seems to work under the tests in
>>>>>> grizzly. Of course, those are known to be pretty shallow tests.
>>>>>> I'll dig into ContainerMapper, though. Thanks.
>>>>>>
>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>
>>>>>>>
>>>>>>> Justin Lee wrote:
>>>>>>>> I sent this to another list earlier but haven't heard back yet
>>>>>>>> so I thought I'd cast my net wider.
>>>>>>>>
>>>>>>>> Well, the great news is that I finally have glassfish booting
>>>>>>>> up on top of the grizzly config changes. All the osgi and xml
>>>>>>>> parsing issues seem to be resolved. So that's awesome. What's
>>>>>>>> *not* so awesome, however, is that it appears that even though
>>>>>>>> I see all three network listener configurations being processed
>>>>>>>> and log output about listening to the different ports, if I hit
>>>>>>>> 4848 or 8080 I always just get the one web app. Either the "it
>>>>>>>> works!" page or a horribly broken login.jsf for the admin app.
>>>>>>>> So it would appear that some wires are crossed somewhere and
>>>>>>>> I'm not exactly sure where to look. I'm stepping through
>>>>>>>> GrizzlyProxy and GrizzlyService this morning hoping to see
>>>>>>>> something but that's a lot of code in there. Anyone have any
>>>>>>>> suggestions to explore?
>>>>>>>
>>>>>>> Take a look at the ContainerMapper under the same directory.
>>>>>>> Make sure the mapped container is the one supposed to be
>>>>>>> retrieved, e.g. the AdminAdapter for admin call, the
>>>>>>> CoyoteAdapter for Servlet/Jsp, The GrizzlyStaticAdapter for
>>>>>>> statics resources. Also are you sure Grizzly is properly
>>>>>>> configured (stupid question, just to make sure).
>>>>>>>
>>>>>>> A+
>>>>>>>
>>>>>>> - jeanfrancois
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>