You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2012/11/06 13:41:20 UTC
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
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
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Peter Schyma <ps...@adeece.com>.
Yes. I'll check it out.
Thank you
Am 13.11.2012 18:09, schrieb Sergey Beryozkin:
> Hi
>
> I've typed some code to get the error reported without enforcing JSON
> enforced too early in the case when the error needs to be returned
> directly to the client:
>
> http://svn.apache.org/viewvc?rev=1408832&view=rev
>
> Can you experiment with this code please in a day or two, after the
> snapshots have been redeployed ?
>
> Thanks, Sergey
>
> On 12/11/12 15:16, Sergey Beryozkin wrote:
>> Hi Peter
>> On 12/11/12 14:34, Peter Schyma wrote:
>>> Hi Sergey,
>>>
>>> sorry, we had a meeting right after I started to answer.
>>>
>> no problems, whenever you get the time to reply is OK
>>>
>>> > 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 ?
>>>
>>> But it is returning the JSON to the end user. We are in the current
>>> redirection based flow:
>>> 1. Client requests
>>> "/authorize?client_id=X&redirect_uri=Y&response_type=code&..."
>>> 2. Client is validated
>>> 3. Based on the result of the validation:
>>> 3a. An authorization form is shown to the end user, or
>>> 3b. an error is raised
>>>
>>> In case 3a the user sees a HTML page (or JSON/ XML depending on the
>>> request headers) that describes the request and asks for the
>>> authorization. Independent of the decision a redirect is made to the
>>> client.
>>>
>>> Case 3b should now display the error in a human friendly manner or
>>> handle it appropriately (e.g. redirect to client with error code?).
>>
>> Actually, you are right. The spec says that the client validation
>> failure should result in the error returned directly to the end user.
>>
>>
>>>
>>> Currently, in CXF the following is happening in case 3b.
>>> 1. OAuthDataProvider#getClient is called to obtain the client instance
>>> 2. Regardless of whether OAuthDataProvider#getClient returns a null
>>> value or raises an exception, a new WebApplicationException (even
>>> discarding the OAuthError from the original exception) is thrown by
>>> calling AbstractOAuthServer#reportInvalidRequest.
>>>
>>> Here I can only register OAuthJSONProvider or a custom Provider that
>>> pretends to render JSON but actually renders something else.
>>
>> Sure, I'll deal with it...
>>
>>>
>>>
>>> > 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
>>>
>>> The spec [1] says that I should not be able to do this. The
>>> WebApplicationExceptions that is thrown out of
>>> AbstractOAuthServer#reportInvalidRequest contains already an entity that
>>> must be used.
>>>
>> Interesting. I guess at the moment CXF will let custom
>> WebApplicationException mappers to modify the original Response
>> available from WebApplicationException, but it is really up to the
>> custom mapper if that is to be done or not, definitely not something
>> that CXF itself will do (ie, it won't modify the custom
>> WebApplicationException resposne if any).
>>
>>
>> I'll probably seek some clarifications on this specific point. IMHO the
>> custom mapper should be able to see all WebApplicationException
>> instances, even the ones which may already contain Response, example,
>> for some custom logging purposes
>>
>> Thanks, Sergey
>>
>>>
>>> Greetings,
>>> Peter
>>>
>>> [1]
>>> http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
>>>
>>>
>>>
>>
>>
>
>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Peter,
regarding your earlier comment about WAE,
>>>>> > 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
>>>>>
>>>>> The spec [1] says that I should not be able to do this. The
>>>>> WebApplicationExceptions that is thrown out of
>>>>> AbstractOAuthServer#reportInvalidRequest contains already an entity
>>>>> that
>>>>> must be used.
>>>>>
>>>> Interesting. I guess at the moment CXF will let custom
>>>> WebApplicationException mappers to modify the original Response
>>>> available from WebApplicationException, but it is really up to the
>>>> custom mapper if that is to be done or not, definitely not something
>>>> that CXF itself will do (ie, it won't modify the custom
>>>> WebApplicationException resposne if any).
>>>>
>>>>
>>>> I'll probably seek some clarifications on this specific point. IMHO the
>>>> custom mapper should be able to see all WebApplicationException
>>>> instances, even the ones which may already contain Response, example,
>>>> for some custom logging purposes
Indeed, the spec text specifically mentions that if WAE Response has an
entity - then avoid using the mapper.
We've had the discussion and it is unfortunate this optimization will
stay in the spec text because of the BC concerns, however CXF will
continue checking the mapper by default (same as RestEasy too) - simply
because the properly written mapper will not lose the original response,
and very likely, if the mapper has been registered, then the mapper will
want to see all WAE exceptions - this won't break the compatibility in
any way, because it is just an optimization.
Furthermore, at the moment the spec text is actually buggy because if
the application code throws WAE with Response having an entity and this
WAE having a cause exception set (obviously for the purpose of the
mapper doing something with the cause) then if this optimization is
implemented then the cause gets lost for the mapper...
However, those users who actually do mean bypassing the mapper by
throwing WAE with Response having a non-empty entity can set
"support.wae.spec.optimization" contextual property and instruct the
runtime to ignore the mapper
Thanks, Sergey
>>>>
>>>> Thanks, Sergey
>>>>
>>>>>
>>>>> Greetings,
>>>>> Peter
>>>>>
>>>>> [1]
>>>>> http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Peter
On 20/11/12 09:16, Peter Schyma wrote:
> Hello Sergey,
>
> I found some time today in the morning to test it, finally.
>
> It works like a charm. Having a RequestDispatcherProvider provider
> configured to dispatch OAuthError to a specific JSP I get the custom
> HTML view for the error.
>
Very good, thanks for spending the time
> Do you need additional tests on it?
It works for you so that is good enough for me. I'll resolve CXF-4633
for now - please reopen in case some more relevant fixes are needed
Cheers, Sergey
>
> Peter
>
> Am 13.11.2012 18:09, schrieb Sergey Beryozkin:
>> Hi
>>
>> I've typed some code to get the error reported without enforcing JSON
>> enforced too early in the case when the error needs to be returned
>> directly to the client:
>>
>> http://svn.apache.org/viewvc?rev=1408832&view=rev
>>
>> Can you experiment with this code please in a day or two, after the
>> snapshots have been redeployed ?
>>
>> Thanks, Sergey
>>
>> On 12/11/12 15:16, Sergey Beryozkin wrote:
>>> Hi Peter
>>> On 12/11/12 14:34, Peter Schyma wrote:
>>>> Hi Sergey,
>>>>
>>>> sorry, we had a meeting right after I started to answer.
>>>>
>>> no problems, whenever you get the time to reply is OK
>>>>
>>>> > 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 ?
>>>>
>>>> But it is returning the JSON to the end user. We are in the current
>>>> redirection based flow:
>>>> 1. Client requests
>>>> "/authorize?client_id=X&redirect_uri=Y&response_type=code&..."
>>>> 2. Client is validated
>>>> 3. Based on the result of the validation:
>>>> 3a. An authorization form is shown to the end user, or
>>>> 3b. an error is raised
>>>>
>>>> In case 3a the user sees a HTML page (or JSON/ XML depending on the
>>>> request headers) that describes the request and asks for the
>>>> authorization. Independent of the decision a redirect is made to the
>>>> client.
>>>>
>>>> Case 3b should now display the error in a human friendly manner or
>>>> handle it appropriately (e.g. redirect to client with error code?).
>>>
>>> Actually, you are right. The spec says that the client validation
>>> failure should result in the error returned directly to the end user.
>>>
>>>
>>>>
>>>> Currently, in CXF the following is happening in case 3b.
>>>> 1. OAuthDataProvider#getClient is called to obtain the client instance
>>>> 2. Regardless of whether OAuthDataProvider#getClient returns a null
>>>> value or raises an exception, a new WebApplicationException (even
>>>> discarding the OAuthError from the original exception) is thrown by
>>>> calling AbstractOAuthServer#reportInvalidRequest.
>>>>
>>>> Here I can only register OAuthJSONProvider or a custom Provider that
>>>> pretends to render JSON but actually renders something else.
>>>
>>> Sure, I'll deal with it...
>>>
>>>>
>>>>
>>>> > 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
>>>>
>>>> The spec [1] says that I should not be able to do this. The
>>>> WebApplicationExceptions that is thrown out of
>>>> AbstractOAuthServer#reportInvalidRequest contains already an entity
>>>> that
>>>> must be used.
>>>>
>>> Interesting. I guess at the moment CXF will let custom
>>> WebApplicationException mappers to modify the original Response
>>> available from WebApplicationException, but it is really up to the
>>> custom mapper if that is to be done or not, definitely not something
>>> that CXF itself will do (ie, it won't modify the custom
>>> WebApplicationException resposne if any).
>>>
>>>
>>> I'll probably seek some clarifications on this specific point. IMHO the
>>> custom mapper should be able to see all WebApplicationException
>>> instances, even the ones which may already contain Response, example,
>>> for some custom logging purposes
>>>
>>> Thanks, Sergey
>>>
>>>>
>>>> Greetings,
>>>> Peter
>>>>
>>>> [1]
>>>> http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Peter Schyma <ps...@adeece.com>.
Hello Sergey,
I found some time today in the morning to test it, finally.
It works like a charm. Having a RequestDispatcherProvider provider
configured to dispatch OAuthError to a specific JSP I get the custom
HTML view for the error.
Do you need additional tests on it?
Peter
Am 13.11.2012 18:09, schrieb Sergey Beryozkin:
> Hi
>
> I've typed some code to get the error reported without enforcing JSON
> enforced too early in the case when the error needs to be returned
> directly to the client:
>
> http://svn.apache.org/viewvc?rev=1408832&view=rev
>
> Can you experiment with this code please in a day or two, after the
> snapshots have been redeployed ?
>
> Thanks, Sergey
>
> On 12/11/12 15:16, Sergey Beryozkin wrote:
>> Hi Peter
>> On 12/11/12 14:34, Peter Schyma wrote:
>>> Hi Sergey,
>>>
>>> sorry, we had a meeting right after I started to answer.
>>>
>> no problems, whenever you get the time to reply is OK
>>>
>>> > 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 ?
>>>
>>> But it is returning the JSON to the end user. We are in the current
>>> redirection based flow:
>>> 1. Client requests
>>> "/authorize?client_id=X&redirect_uri=Y&response_type=code&..."
>>> 2. Client is validated
>>> 3. Based on the result of the validation:
>>> 3a. An authorization form is shown to the end user, or
>>> 3b. an error is raised
>>>
>>> In case 3a the user sees a HTML page (or JSON/ XML depending on the
>>> request headers) that describes the request and asks for the
>>> authorization. Independent of the decision a redirect is made to the
>>> client.
>>>
>>> Case 3b should now display the error in a human friendly manner or
>>> handle it appropriately (e.g. redirect to client with error code?).
>>
>> Actually, you are right. The spec says that the client validation
>> failure should result in the error returned directly to the end user.
>>
>>
>>>
>>> Currently, in CXF the following is happening in case 3b.
>>> 1. OAuthDataProvider#getClient is called to obtain the client instance
>>> 2. Regardless of whether OAuthDataProvider#getClient returns a null
>>> value or raises an exception, a new WebApplicationException (even
>>> discarding the OAuthError from the original exception) is thrown by
>>> calling AbstractOAuthServer#reportInvalidRequest.
>>>
>>> Here I can only register OAuthJSONProvider or a custom Provider that
>>> pretends to render JSON but actually renders something else.
>>
>> Sure, I'll deal with it...
>>
>>>
>>>
>>> > 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
>>>
>>> The spec [1] says that I should not be able to do this. The
>>> WebApplicationExceptions that is thrown out of
>>> AbstractOAuthServer#reportInvalidRequest contains already an entity that
>>> must be used.
>>>
>> Interesting. I guess at the moment CXF will let custom
>> WebApplicationException mappers to modify the original Response
>> available from WebApplicationException, but it is really up to the
>> custom mapper if that is to be done or not, definitely not something
>> that CXF itself will do (ie, it won't modify the custom
>> WebApplicationException resposne if any).
>>
>>
>> I'll probably seek some clarifications on this specific point. IMHO the
>> custom mapper should be able to see all WebApplicationException
>> instances, even the ones which may already contain Response, example,
>> for some custom logging purposes
>>
>> Thanks, Sergey
>>
>>>
>>> Greetings,
>>> Peter
>>>
>>> [1]
>>> http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
>>>
>>>
>>>
>>
>>
>
>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
I've typed some code to get the error reported without enforcing JSON
enforced too early in the case when the error needs to be returned
directly to the client:
http://svn.apache.org/viewvc?rev=1408832&view=rev
Can you experiment with this code please in a day or two, after the
snapshots have been redeployed ?
Thanks, Sergey
On 12/11/12 15:16, Sergey Beryozkin wrote:
> Hi Peter
> On 12/11/12 14:34, Peter Schyma wrote:
>> Hi Sergey,
>>
>> sorry, we had a meeting right after I started to answer.
>>
> no problems, whenever you get the time to reply is OK
>>
>> > 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 ?
>>
>> But it is returning the JSON to the end user. We are in the current
>> redirection based flow:
>> 1. Client requests
>> "/authorize?client_id=X&redirect_uri=Y&response_type=code&..."
>> 2. Client is validated
>> 3. Based on the result of the validation:
>> 3a. An authorization form is shown to the end user, or
>> 3b. an error is raised
>>
>> In case 3a the user sees a HTML page (or JSON/ XML depending on the
>> request headers) that describes the request and asks for the
>> authorization. Independent of the decision a redirect is made to the
>> client.
>>
>> Case 3b should now display the error in a human friendly manner or
>> handle it appropriately (e.g. redirect to client with error code?).
>
> Actually, you are right. The spec says that the client validation
> failure should result in the error returned directly to the end user.
>
>
>>
>> Currently, in CXF the following is happening in case 3b.
>> 1. OAuthDataProvider#getClient is called to obtain the client instance
>> 2. Regardless of whether OAuthDataProvider#getClient returns a null
>> value or raises an exception, a new WebApplicationException (even
>> discarding the OAuthError from the original exception) is thrown by
>> calling AbstractOAuthServer#reportInvalidRequest.
>>
>> Here I can only register OAuthJSONProvider or a custom Provider that
>> pretends to render JSON but actually renders something else.
>
> Sure, I'll deal with it...
>
>>
>>
>> > 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
>>
>> The spec [1] says that I should not be able to do this. The
>> WebApplicationExceptions that is thrown out of
>> AbstractOAuthServer#reportInvalidRequest contains already an entity that
>> must be used.
>>
> Interesting. I guess at the moment CXF will let custom
> WebApplicationException mappers to modify the original Response
> available from WebApplicationException, but it is really up to the
> custom mapper if that is to be done or not, definitely not something
> that CXF itself will do (ie, it won't modify the custom
> WebApplicationException resposne if any).
>
>
> I'll probably seek some clarifications on this specific point. IMHO the
> custom mapper should be able to see all WebApplicationException
> instances, even the ones which may already contain Response, example,
> for some custom logging purposes
>
> Thanks, Sergey
>
>>
>> Greetings,
>> Peter
>>
>> [1]
>> http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
>>
>>
>>
>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Peter
On 12/11/12 14:34, Peter Schyma wrote:
> Hi Sergey,
>
> sorry, we had a meeting right after I started to answer.
>
no problems, whenever you get the time to reply is OK
>
> > 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 ?
>
> But it is returning the JSON to the end user. We are in the current
> redirection based flow:
> 1. Client requests
> "/authorize?client_id=X&redirect_uri=Y&response_type=code&..."
> 2. Client is validated
> 3. Based on the result of the validation:
> 3a. An authorization form is shown to the end user, or
> 3b. an error is raised
>
> In case 3a the user sees a HTML page (or JSON/ XML depending on the
> request headers) that describes the request and asks for the
> authorization. Independent of the decision a redirect is made to the
> client.
>
> Case 3b should now display the error in a human friendly manner or
> handle it appropriately (e.g. redirect to client with error code?).
Actually, you are right. The spec says that the client validation
failure should result in the error returned directly to the end user.
>
> Currently, in CXF the following is happening in case 3b.
> 1. OAuthDataProvider#getClient is called to obtain the client instance
> 2. Regardless of whether OAuthDataProvider#getClient returns a null
> value or raises an exception, a new WebApplicationException (even
> discarding the OAuthError from the original exception) is thrown by
> calling AbstractOAuthServer#reportInvalidRequest.
>
> Here I can only register OAuthJSONProvider or a custom Provider that
> pretends to render JSON but actually renders something else.
Sure, I'll deal with it...
>
>
> > 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
>
> The spec [1] says that I should not be able to do this. The
> WebApplicationExceptions that is thrown out of
> AbstractOAuthServer#reportInvalidRequest contains already an entity that
> must be used.
>
Interesting. I guess at the moment CXF will let custom
WebApplicationException mappers to modify the original Response
available from WebApplicationException, but it is really up to the
custom mapper if that is to be done or not, definitely not something
that CXF itself will do (ie, it won't modify the custom
WebApplicationException resposne if any).
I'll probably seek some clarifications on this specific point. IMHO the
custom mapper should be able to see all WebApplicationException
instances, even the ones which may already contain Response, example,
for some custom logging purposes
Thanks, Sergey
>
> Greetings,
> Peter
>
> [1] http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
>
>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Peter Schyma <ps...@adeece.com>.
Hi Sergey,
sorry, we had a meeting right after I started to answer.
> 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 ?
But it is returning the JSON to the end user. We are in the current
redirection based flow:
1. Client requests
"/authorize?client_id=X&redirect_uri=Y&response_type=code&..."
2. Client is validated
3. Based on the result of the validation:
3a. An authorization form is shown to the end user, or
3b. an error is raised
In case 3a the user sees a HTML page (or JSON/ XML depending on the
request headers) that describes the request and asks for the
authorization. Independent of the decision a redirect is made to the client.
Case 3b should now display the error in a human friendly manner or
handle it appropriately (e.g. redirect to client with error code?).
Currently, in CXF the following is happening in case 3b.
1. OAuthDataProvider#getClient is called to obtain the client instance
2. Regardless of whether OAuthDataProvider#getClient returns a null
value or raises an exception, a new WebApplicationException (even
discarding the OAuthError from the original exception) is thrown by
calling AbstractOAuthServer#reportInvalidRequest.
Here I can only register OAuthJSONProvider or a custom Provider that
pretends to render JSON but actually renders something else.
> 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
The spec [1] says that I should not be able to do this. The
WebApplicationExceptions that is thrown out of
AbstractOAuthServer#reportInvalidRequest contains already an entity that
must be used.
Greetings,
Peter
[1] http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Peter Schyma <ps...@adeece.com>.
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.
I'll answer the other points in a new message.
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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Peter Schyma <ps...@adeece.com>.
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
>>>>>
>>>>
>>>
>>>
>>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>>>
>>>
>>
>>
>
Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Posted by Peter Schyma <ps...@adeece.com>.
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.
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
>>>
>>
>
>