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.
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."
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.
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
