On Sun, Nov 13, 2011 at 10:17 AM, Rupert Westenthaler <
[email protected]> wrote:
> Hi
>
> If we decide for the usage of Servlet Filters to copy over parsed
> "header_{header}"
> parameters to the headers of the Request, than we need to work on two
> things
>
> 1. Providing the ability to (un)register Servlet filters for the different
> OSGI environments
> 2. The Filter that does the actual work
>
> ad (1)
>
> >> Sounds like a good Idea.
> >>
> >> One problem might be that Servlet Filters are not supported by the
> default
> >> OSGI HttpService [1]. Therefore the registration of Filter is OSGI
> platform
> >> specific (e.g the ExtHttpService in the case of Apache Felix [2]). An
> other
> >> option may be the use of PaxWeb [3].
> >>
> >
> > I suggest we just register a javax.servlet.*Filter* service (whiteboard
> > pattern), I think this works both with felix and with pax-web.
> >
> > Cheers,
> > Reto
>
> I do interpret this as:
>
> * Defining an own interface for adding/removing ServletFilters
> * Providing two Implementations for ExtHttpService and PaxWeb and
> registering them as OSGI service. So if the Felix HttpService and/or the
> PaxWeb is available this service will be around.
> * Using a @Reference to this Service to register ServletFilters
>
> @Reto: Is that what you meant?
>
Not exactly, defining a service interface for adding/removing
ServletFilters would be against the white-board pattern. My suggestion was
just to register a service exposing the ServletFilter interface and support
only environments where such a service is picked up (i.e. whiteboard
pattern for ServletFilters is supported). Unfortunately I don't know
exactly which implementations do this (I know it works in sling).
Cheers,
Reto
>
> If yes, we could define this interface and the implementations as an own
> bundle
> within stanbol.commons (with optional dependencies to [2] and [3].
>
> I could work on that, because I would anyway like to use
> this also for registering the SolrDispatchFilters within the
> commons.solr.web bundle.
>
> For (2) I would like if someone else could do the work, because I have
> already
> a lot of things on my TODO list before the next Hackathon [4] .
>
> best
> Rupert
>
> > [2]
> >
> http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheExtHttpService
> > [3] http://team.ops4j.org/wiki//display/paxweb/Pax+Web
>
>
> [4] http://wiki.iks-project.eu/index.php/IntegrationHackathonSalzburg
>
> On 12.11.2011, at 20:35, Szaby Grünwald wrote:
>
> > Dear Stanbol contributors,
> >
> > The point is to be able to use the Stanbol REST API even if technically
> > there's no way to control the request header parameters. (This is the
> case
> > when making a cross-site request from Internet Explorer 8 & 9)
> >
> > So any of the discussed solutions that solve this are fine with me. This
> > feature would bring the usefulness of Stanbol a step forward in
> combination
> > with the VIE javascript library when used from Internet Explorer.
> >
> > I hope someone could implement it soon! Who?
> >
> > Szaby
> >
> > P.S.
> > Some of you stated that this discussion should happen on the stanbol-dev
> > list so I am moving this discussion now from the iks-wip list to the
> > stanbol-dev list. For those of you who are not on the iks-wip mailing
> list
> > here is the whole discussion again started on wednesday (the newest
> message
> > is at the bottom, sorry for that):
> >
> >
> > *VIE, Stanbol and Internet Explorer 8 & 9*
> > 8 messages
> > ------------------------------
> > *Szabolcs Grünwald <[email protected]>* *9 November
> 2011
> > 18:02*
> > To: iks-wip <[email protected]>
> > Dear Stanbol and VIE developers,
> >
> > As you may guess it's a rocky way to get something run on Internet
> > Explorer. Now I'm on this way of getting VIE and its Stanbol
> > Service running on it and I came to a painful point where I see dark in
> > terms of ever solving the problem of sending cross-domain requests (CORS
> is
> > implemented in Stanbol) from Internet Explorer 8 and 9 without to change
> > Stanbol's REST API.
> >
> > In Chrome and Firefox the XMLHttpRequest object of the browser takes care
> > of the preflight requests (OPTIONS request before a cross-domain POST for
> > example). In Explorer this is not that easy. There's another object for
> > handling cross-domain requests, the XDomainRequest. This can be made to
> > allow cross-domain requests depending on trust zones of local, intranet
> and
> > internet. For handling the XDomainRequest we can use a special
> > jQuery.ajaxTransport, but the problem is this: the XDomainRequest object
> > has some limitations. [1]
> >
> > The most painful of these limitations is that it's not possible to set
> > specific accept-headers on the requests, which is essential for using the
> > Stanbol REST API.
> >
> > As Rupert and I tried to figure this out, we could only think about one
> > workaround:
> > Using GET parameters on the request URI for setting the access header.
> >
> > Any ideas and thoughts how to solve this issue?
> >
> > [1]
> >
> http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx
> >
> > --
> > Szaby Grünwald MA
> > Web developer
> > Knowledge and Media Technologies
> > Salzburg Research Forschungsgesellschaft m.b.H.
> > Jakob Haringer Straße 5/3 5020 Salzburg, Austria
> > Phone: +43 662 2288 301
> > Fax: +43 662 2288 222
> > ------------------------------
> > *Olivier Grisel <[email protected]>* *9 November 2011 18:14*
> > To: Szabolcs Grünwald <[email protected]>
> > Cc: iks-wip <[email protected]>
> > I think we could indeed have dual content type negotiation handling.
> > For instance by using the a "format" query parameter if there and
> > falling back to the HTTP "Accept:" header if no "format" query
> > parameter is provided.
> >
> > BTW if we decide to go this we should discuss this on the stanbol-dev
> > mailing list.
> >
> > --
> > Olivier
> > ------------------------------
> > *Stefane Fermigier <[email protected]>**9 November 2011 21:17*
> > To: Olivier Grisel <[email protected]>
> > Cc: Szabolcs Grünwald <[email protected]>, iks-wip <
> > [email protected]>
> >
> > On Nov 9, 2011, at 6:14 PM, Olivier Grisel wrote:
> >
> >> I think we could indeed have dual content type negotiation handling.
> >> For instance by using the a "format" query parameter if there and
> >> falling back to the HTTP "Accept:" header if no "format" query
> >> parameter is provided.
> >
> > Indeed. The CMIS browser binding specs authors seem to have had similar
> > issues, it might be worth looking at how they did solve them:
> >
> >
> http://tools.oasis-open.org/version-control/svn/cmis/trunk/BrowserBinding/specification/cmis-spec-v0.5-browserbinding.doc
> >
> >> BTW if we decide to go this we should discuss this on the stanbol-dev
> >> mailing list.
> >
> > Indeed.
> >
> > S.
> >
> > --
> > Stefane Fermigier
> > http://twitter.com/sfermigier - http://www.linkedin.com/in/sfermigier
> > "Although I suffer from the defeats, I learn to achieve more victories,
> and
> > that's the essence of job satisfaction." - Gerald Weinberg
> > "There's no such thing as can't. You always have a choice." - Ken Gor
> >
> > ------------------------------
> > *Reto Bachmann-Gmür <[email protected]>* *10 November 2011 00:03*
> > To: Olivier Grisel <[email protected]>
> > Cc: Szabolcs Grünwald <[email protected]>, iks-wip <
> > [email protected]>
> > I suggest to have optional query parameters starting with "header_" and
> > followed by the name of the header for any request uri. For this I
> suggest
> > adding a servlet filter that looks for such query parameters and forwards
> > the http request to the chain with the request header set to the value of
> > the query parameters. Such a module would not need to depend on any other
> > Stanbol module, as such it could also be used with other system using the
> > OSGi http service.
> >
> > Reto
> >
> > [Quoted text hidden]
> >
> >> [Quoted text hidden]
> >>
> >> --
> >> Olivier
> >> _______________________________________________
> >> iks-wip mailing list
> >> [email protected]
> >> http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip
> >>
> >
> > ------------------------------
> > *Reto Bachmann-Gmür <[email protected]>**10 November 2011 00:07*
> > To: Olivier Grisel <[email protected]>
> > Cc: Szabolcs Grünwald <[email protected]>, iks-wip <
> > [email protected]>
> > I suggest to have optional query parameters starting with "header_" and
> > followed by the name of the header for any request uri. For this I
> suggest
> > adding a servlet filter that looks for such query parameters and forwards
> > the http request to the chain with the request header set to the value of
> > the query parameters. Such a module would not need to depend on any other
> > Stanbol module, as such it could also be used with other system using the
> > OSGi http service.
> >
> > Reto
> >
> > On Wed, Nov 9, 2011 at 6:14 PM, Olivier Grisel <[email protected]>
> wrote:
> >
> >> [Quoted text hidden]
> >>
> >> --
> >> Olivier
> >> _______________________________________________
> >> iks-wip mailing list
> >> [email protected]
> >> http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip
> >>
> >
> >
> > ------------------------------
> > *Rupert Westenthaler <[email protected]>* *10
> > November 2011 08:15*
> > To: Reto Bachmann-Gmür <[email protected]>
> > Cc: iks-wip <[email protected]>
> >
> > On 10.11.2011, at 00:07, Reto Bachmann-Gmür wrote:
> >
> > I suggest to have optional query parameters starting with "header_" and
> > followed by the name of the header for any request uri. For this I
> suggest
> > adding a servlet filter that looks for such query parameters and forwards
> > the http request to the chain with the request header set to the value of
> > the query parameters. Such a module would not need to depend on any other
> > Stanbol module, as such it could also be used with other system using the
> > OSGi http service.
> >
> > Sounds like a good Idea.
> >
> > One problem might be that Servlet Filters are not supported by the
> default
> > OSGI HttpService [1]. Therefore the registration of Filter is OSGI
> platform
> > specific (e.g the ExtHttpService in the case of Apache Felix [2]). An
> other
> > option may be the use of PaxWeb [3].
> >
> > any experiences?
> > Rupert
> >
> > BTW: I do already use Filters based on the Apache Felix ExtHttpService
> for
> > registering SolrDispatchFilters - so a Solution that works independent of
> > the used OSGI platform would also be great for this functionality
> >
> > [1]
> http://www.osgi.org/javadoc/r4v42/org/osgi/service/http/HttpService.html
> > [2]
> >
> http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheExtHttpService
> > [3] http://team.ops4j.org/wiki//display/paxweb/Pax+Web
> >
> > Reto
> >
> > On Wed, Nov 9, 2011 at 6:14 PM, Olivier Grisel <[email protected]>
> wrote:
> >
> >> I think we could indeed have dual content type negotiation handling.
> >> For instance by using the a "format" query parameter if there and
> >> falling back to the HTTP "Accept:" header if no "format" query
> >> parameter is provided.
> >>
> >> BTW if we decide to go this we should discuss this on the stanbol-dev
> >> mailing list.
> >>
> >> --
> >> Olivier
> >>
> >
> > ------------------------------
> > *Reto Bachmann-Gmür <[email protected]>**10 November 2011 10:53*
> > To: Rupert Westenthaler <[email protected]>
> > Cc: iks-wip <[email protected]>
> >
> >
> > On Thu, Nov 10, 2011 at 8:15 AM, Rupert Westenthaler <
> > [email protected]> wrote:
> >
> >>
> >> On 10.11.2011, at 00:07, Reto Bachmann-Gmür wrote:
> >>
> >> I suggest to have optional query parameters starting with "header_" and
> >> followed by the name of the header for any request uri. For this I
> suggest
> >> adding a servlet filter that looks for such query parameters and
> forwards
> >> the http request to the chain with the request header set to the value
> of
> >> the query parameters. Such a module would not need to depend on any
> other
> >> Stanbol module, as such it could also be used with other system using
> the
> >> OSGi http service.
> >>
> >> Sounds like a good Idea.
> >>
> >> One problem might be that Servlet Filters are not supported by the
> default
> >> OSGI HttpService [1]. Therefore the registration of Filter is OSGI
> platform
> >> specific (e.g the ExtHttpService in the case of Apache Felix [2]). An
> other
> >> option may be the use of PaxWeb [3].
> >>
> >
> > I suggest we just register a javax.servlet.*Filter* service (whiteboard
> > pattern), I think this works both with felix and with pax-web.
> >
> > Cheers,
> > Reto
> >
> >
> >>
> >> any experiences?
> >> Rupert
> >>
> >> BTW: I do already use Filters based on the Apache Felix ExtHttpService
> for
> >> registering SolrDispatchFilters - so a Solution that works independent
> of
> >> the used OSGI platform would also be great for this functionality
> >>
> >> [1]
> >>
> http://www.osgi.org/javadoc/r4v42/org/osgi/service/http/HttpService.html
> >> [2]
> >>
> http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheExtHttpService
> >> [3] http://team.ops4j.org/wiki//display/paxweb/Pax+Web
> >>
> >> Reto
> >>
> >> On Wed, Nov 9, 2011 at 6:14 PM, Olivier Grisel <[email protected]>
> wrote:
> >>
> >>> I think we could indeed have dual content type negotiation handling.
> >>> For instance by using the a "format" query parameter if there and
> >>> falling back to the HTTP "Accept:" header if no "format" query
> >>> parameter is provided.
> >>>
> >>> BTW if we decide to go this we should discuss this on the stanbol-dev
> >>> mailing list.
> >>>
> >>> --
> >>> Olivier
> >>> _______________________________________________
> >>> iks-wip mailing list
> >>> [email protected]
> >>>
> http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip
> >>>
> >>
> >>
> >> _______________________________________________
> >> iks-wip mailing list
> >> [email protected]
> >> http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip
> >>
> >>
>
>
