Hi,
On 12/11/12 12:30, Peter Schyma wrote:
Hi Sergey,
I have created a pastebin [1] with the relevant configurations that
helped me.
The OSGi headers register a new ServletContext "/todos" and trigger the
initialization of the Servlets and JSPs. Then I set the
"servetContextPath" to "/todos" in the blueprint for the
RequestDispatcherProvider. With these settings I get my authorization form.
When I do not set "servletContextPath" and let the JSP mapping point to
"/todos/jsp/authorize.jsp" instead, I get again no output. Also I get no
output when I register the JSP via Pax Webs WebContainer#registerJSPs
method and adjust the RequestDispatcherProvider configuration
accordingly. Setting the Web-ContextPath header seems also to be not
sufficient. Therefore, I created a minimal web.xml (just the web-app
root entry with version="2.5") and it worked.
Very helpful, thanks.
I'll answer the other points in a new message.
OK
Cheers, Sergey
Greetings,
Peter
[1] http://pastebin.com/zaCydc6h
Am 12.11.2012 12:09, schrieb Sergey Beryozkin:
Hi Peter
On 07/11/12 16:18, Peter Schyma wrote:
Hi Sergey,
that solved my problem.
Setting the servletContextPath to the context that is registered via
OSGi Headers accompanied by a minimal web.xml makes the JSP visible to
the RequestDispatcherProvider.
This is really good, thanks for making it work. If you can share some
more info on how you did it, it would be useful, definitely for me
trying to get the OAuth demos running in Karaf :-). I guess JSP servlet
is available at some known context, but I did not quite get how OSGI
headers helped to bridge it with RequestDispatcherProvider
I have another question related to this. Now that I have JSPs running, I
would like to report errors (e.g. invalid client while requesting a
grant code) in a JSP.
But regarding the current implementation of
AbstractOAuthService#reportInvalidRequestError this seems impossible
because it binds the OAuthError to "application/json" mime type. So I
have to add OAuthJSONProvider to the server in order to get more than a
"No message body writer has been found for response class OAuthError."
My understanding it won't be OAuth2 compliant, returning the error to do
with the (illegal) client directly to the end user ?
Can you clarify please when would you like to get the error returned as
HTML representation ?
According to the spec, I will not have any success when I register a
custom ExceptionMapper for WebApplicationExceptions because it will only
be invoked when a WebApplicationException with an empty entity body is
thrown.
Not really, the mapper will have a chance to update Response already
available in the caught WebApplicationException, but eventually it will
be up to the providers (MBW) to handle the actual response
Cheers, Sergey
Thanks,
Peter
Am 06.11.2012 17:29, schrieb Sergey Beryozkin:
Hi
On 06/11/12 15:16, Peter Schyma wrote:
Hi,
unfortunately I had no success.
I am able to register and access the JSP using Pax Web Extensions to
HttpService but it is not caught up by the ServletContext that CXF
uses.
So the RequestDispatcher used by RequestDispatcherProvider is not
seeing
it and thus just returns a default servlet that produces no output, I
assume.
This reminded me that RequestDispatcherProvider has
"servletContextPath"
property, if it is set then the current ServletContext will try to
retrieve the other servlet context using the value of
"servletContextPath".
Not sure if that can help but give that a try please
Sergey
What I have not tried yet is to use a Spring based setup using
CXFServlet from web.xml so I have CXF OAuth and the needed JSPs in one
context. But I don't think that this is the best way.
Greetings
Peter
Am 06.11.2012 13:41, schrieb Sergey Beryozkin:
Hi Peter
Have you had any progress with it ?
I haven't had time yet to look into porting OAuth2 demos to Karaf,
and
I'm off from tomorrow till the end of the week.
This is something I'll want to do before 2.7.1 is out anyway, and my
plan is to introduce a light-weight war-bundle (it will only have
web.xml and beans.xml files) and proceed from there. We have a
transformations demo done with the war bundle, but I haven't tried
with
linking to JSP yet...
Cheers, Sergey
On 30/10/12 11:48, Peter Schyma wrote:
Hi,
thank you for your answer.
I tried your suggestions, but none of them works. Every time the
same
result: a zero-length content.
Right now i am using a workaround. I implemented a MessageBodyWriter
that creates the authorization site HTML code in plain Java.
I'll dig deeper into it on the weekend.
Greetings,
Peter
Am 30.10.2012 12:11, schrieb Sergey Beryozkin:
Hi
On 26/10/12 15:54, Peter Schyma wrote:
Hi,
i am trying to setup an OAuth2 Server using CXFs implementation.
Following the documentation[1], i have implemented an
OAuthDataProvider
and wired it to the AuthorizationCodeGrantService.
Everything works fine. But when i request the authorization in my
browser, i only get a blank page/ zero-length content response.
I am attaching an instance of RequestDispatcherProvider to the
jaxrs:server that serves the authorization. Like the documentation
suggested: the OAuthAuthorizationData is to be rendered by an
JSP. In
the logs i see the expected output:
'Setting an instance of
"org.apache.cxf.rs.security.oauth2.common.OAuthAuthorizationData"
as
HttpServletRequest attribute "data" and redirecting the
response to
"/jsp/authorize.jsp"'.
But i see this even when i map to an non-existing JSP without any
errors
in the logs.
It appears the container (Jetty at least) does not enforce, when
locating RequestDispatcher, the existence of the actual handler.
After messing arround with this issue, i tried XSLTJaxbProvider.
This
provider at least emits warning about missing files and as a
result
throws an exception when it tries to render the output: [2].
Disabling both providers display the XML serialization of the
OAuthAuthorizationData instance.
[3] shows a slightly shortend version of the blueprint context
definition i am using to startup the service.
While inspecting the missing resource warning of the
XSLTJaxbProvider
with my debugger, i noticed that it uses the ClassLoader (getting
it by
CXF Bus) of another bundle that is exposing a REST service via
CXF -
because that bundle is started earlier. So i tried to name the
busses of
both bundles. But this doesn't have any impact on the output.
JSP support is active as there is another bundle that uses JSPs to
render web pages but without CXF.
I deactivated both bundles so that the OAuth service bundle is the
only
one that uses CXF or JSPs. But still no output.
I imported Servlet and JSP packages in the service bundle.
Still no
output.
The CXF version is 2.7.0 - but 2.6.2 yields the same result. Karaf
versions 2.2.9 and 2.3.0 yield also the same result with both CXF
versions. The installed features are: cxf, cxf-rs-security-oauth2
(and
their dependencies).
Am i missing something from the docs? Any hints are appreciated.
Actually, the demos I worked upon have not been tested within
Karaf,
which is a shame, I will look into it asap. I believe it is not a
CXF
issue, but at the moment I wonder if it is to do with the fact that
the
application bundle may not have been deployed as a war-bundle ?
Would
setting a RequestDispatcherProvider "dispatcherName" property to
"jsp"
help ? Perhaps jsp resources have to be exported from the app
bundle ?
I guess it is really about getting a jsp resource visible. You are
probably the first person who attempts to do in OSGI - I'm
hoping to
help asap :-)
Cheers, Sergey
Thanks
Peter
[1] http://cxf.apache.org/docs/jax-rs-oauth2.html
[2] http://pastebin.com/vdqmNc0Q
[3] http://pastebin.com/CtCR6qRf
