Yea after writing the original mail and getting some sleep I realized
the better approach was to override it :) It was a little late when I
wrote it and I was not thinking clearly
Richard
On Mon, Nov 24, 2008 at 8:09 AM, Justin Lee <Justin.Lee_at_sun.com> 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.
>
> 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
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
>