Justin Lee wrote:
> Agreed. and with the subclass route, using a flag would almost be
> redundant. e.g. that method could simply be:
>
> public String getAuthType() {
> if (request == null) {
> throw new IllegalStateException(
> sm.getString("requestFacade.nullRequest"));
> }
> // get OSGi security type out of the HTTP header
> }
>
> There'd be very little need to explicitly track that you were in an OSGi
> context since your subclass would indicate that implicitly.
+1 for #2 as well!
-- Jeanfrancois
>
> Oleksiy Stashok wrote:
>> Hi Richard,
>>
>>>
>>> I've finally decided on how I'm going to implement the OSGi
>>> HttpService and I have a few questions:
>>>
>>> To begin with I going to have to implement a GrizzlyAdapter (which I
>>> knew I was going to have to do) but I want to reuse as much of the
>>> existing code as I can. In particular the current Servlet invocation
>>> code. But to make that work I need to either:
>>> 1) Make some minor mods to the current implementation because I have
>>> to do some things a little different. Not very many but still a
>>> modification. These mods would be very minor basiclly create a new
>>> constructor that would take a flag indicating that the implementation
>>> is running as a OSGi implementation then use that flag in the methods
>>> that need to change for execution in the OSGi environment. For
>>> instance:
>>>
>>>
>>> // NOTE would have to also implement a default constructor so the
>>> existing code would not break.
>>>
>>> public HttpServletRequestImpl(boolean osgiFlag) {
>>> this.osgiFlag = osgiFlag;
>>> }
>>>
>>> And used like so:
>>>
>>> public String getAuthType() {
>>> if (request == null) {
>>> throw new IllegalStateException(
>>> sm.getString("requestFacade.nullRequest"));
>>> }
>>> if(osgiFlag) {
>>> // get OSGi security type out of the HTTP header
>>> } else {
>>> return request.getAuthType();
>>> }
>>> }
>>>
>>>
>>> Or
>>> 2) Extend the current implementations and override the methods I need
>>> to change.
>>>
>>> Personally I would prefer option one mostly because it keeps all the
>>> code in one place.
>> Hmm, IMHO #2 is better solution. Cause core code should stay as
>> general as possible. But it's just my vision, what others think?
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>>
>>>
>>> I have a bunch of other questions but I want to get them clear in my
>>> head first before asking them.
>>>
>>> Thanks
>>> Richard
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>> <mailto:dev-help_at_grizzly.dev.java.net>
>>>
>>