On Mon, Nov 14, 2011 at 8:56 AM, Reto Bachmann-Gmür <[email protected]> wrote: >> @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). > Looked it up ...
It is part of the "org.apache.felix.http.whiteboard" Bundle. The documentation and an Example for Apache Felix can be found at [1] PaxWeb also supports this Pattern [2], but expects different properties. So there should be a possibility to support both if we add both properties variants to the metadata of the registration. best Rupert [1] http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheWhiteboard [2] http://team.ops4j.org/wiki/display/paxweb/Whiteboard+Extender > 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 >> >> >> >> >> >> > -- | Rupert Westenthaler [email protected] | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
