I would like start coding OAuth support finally and I have some questions
regarding that:
1. We agreed to use OAuth 1.0 spec, I assume to use:
http://tools.ietf.org/html/draft-hammer-oauth-10
as is suggested in: http://oauth.net/core/1.0a/. WDYT?
2. There are existing Java OAuth libraries. I am w
Hi -
For internal service logging needs, is there a way to retrieve the full
REST request url on the service method?
Thanks,
T.
Hi Łukasz
On Wed, Jun 2, 2010 at 12:26 PM, Łukasz Moreń wrote:
> I would like start coding OAuth support finally and I have some questions
> regarding that:
>
> 1. We agreed to use OAuth 1.0 spec, I assume to use:
> http://tools.ietf.org/html/draft-hammer-oauth-10
> as is suggested in: http://oau
On Wednesday 02 June 2010 7:26:31 am Łukasz Moreń wrote:
> I would like start coding OAuth support finally and I have some questions
> regarding that:
>
> 1. We agreed to use OAuth 1.0 spec, I assume to use:
> http://tools.ietf.org/html/draft-hammer-oauth-10
> as is suggested in: http://oauth.net
dkulp wrote:
>
>> 2. There are existing Java OAuth libraries. I am wondering if we could
>> use
>> one of them. From one hand maybe it is not good idea to make
>> cxf dependent on such library, but on the other
>> it's already tested and used by developers (mainly I mean Scribe lib). I
>> can wr
This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
reason for the releases is to fix a potential security vulnerability that will
be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us not
really "supporting" those branches anymore.
The only change
> dkulp wrote:
> >
> >> 2. There are existing Java OAuth libraries. I am wondering if we could
> >> use
> >> one of them. From one hand maybe it is not good idea to make
> >> cxf dependent on such library, but on the other
> >> it's already tested and used by developers (mainly I mean Scribe lib).
+1
On Wed, Jun 2, 2010 at 6:46 PM, Daniel Kulp wrote:
>
> This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The
> main
> reason for the releases is to fix a potential security vulnerability that
> will
> be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us
+1
Glen
dkulp wrote:
>
> This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The
> main
> reason for the releases is to fix a potential security vulnerability that
> will
> be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us
> not
> really "supporting
+1
Jeff
On Jun 2, 2010, at 11:46 AM, Daniel Kulp wrote:
>
> This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
> reason for the releases is to fix a potential security vulnerability that
> will
> be disclosed soon. That is why 2.0.13 and 2.1.10 are included despit
+1
Am 02.06.2010 19:46, schrieb Daniel Kulp:
This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
reason for the releases is to fix a potential security vulnerability that will
be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us not
really "supporti
Hi
On Wed, Jun 2, 2010 at 12:55 PM, Tamar Furman (tfurman)
wrote:
>
> Hi -
>
> For internal service logging needs, is there a way to retrieve the full
> REST request url on the service method?
>
You can have a JAXRS UriInfo context injected as a field :
@Context UriInfo ui;
and then do either
Hi Sergey,
Some comments below...
On 13 May 2010 12:42, Sergey Beryozkin wrote:
>> So now that we have a passing RI I think it would make sense to start
>> planning a CXF-DOSGi release. I'm wondering what we should do before
>> that...
>> 1. There are some SEVERE 'warnings' coming up, I believe
+1
Freeman
On 2010-6-3, at 上午1:46, Daniel Kulp wrote:
This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9.
The main
reason for the releases is to fix a potential security vulnerability
that will
be disclosed soon. That is why 2.0.13 and 2.1.10 are included
despite us not
+1
Willem
Daniel Kulp wrote:
This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
reason for the releases is to fix a potential security vulnerability that will
be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us not
really "supporting" those bra
+1 Non important person.
>
>
>>
>> This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
>> reason for the releases is to fix a potential security vulnerability that
>> will
>> be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us
>> not
>> really "
+1
Thanks,
Bharath
On Thursday, June 3, 2010, Johan Edstrom wrote:
> +1 Non important person.
>
>>
>>
>>>
>>> This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
>>> reason for the releases is to fix a potential security vulnerability that
>>> will
>>> be disclosed soon
+1
David
On 02/06/2010, Daniel Kulp wrote:
>
> This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
> reason for the releases is to fix a potential security vulnerability that
> will
> be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us
> not
> real
+1
On Wed, Jun 2, 2010 at 7:46 PM, Daniel Kulp wrote:
>
> This is a vote to release CXF versions 2.0.13, 2.1.10, and 2.2.9. The main
> reason for the releases is to fix a potential security vulnerability that will
> be disclosed soon. That is why 2.0.13 and 2.1.10 are included despite us not
19 matches
Mail list logo
