*********Shortly, the following form of injection will also be supported***** :

Does it answer your question ?


Cheers, Sergey


@Context
void setSecurityContext(SecurityContext sc) {}

That doesn't work either due to a compile error:

annotation type not applicable to this kind of declaration
   [javac]    @Context
   [javac]     ^
   [javac] 1 error

Are you absolutely sure this setter logic will work through a REST call? I
haven't tried a WS call yet, I'd like one solution for both types of
service.


John

About ServletContext : only @Resource annotated field of this type
can be injected. @Context annotated fields of this type (and
setters and parameters) will also be supported shortly.

Cheers, Sergey




> Sergey,
>
> To confirm, if I remove the Webservice configuration and annotate a
> parameter to a method, the SecurityContext is set as expected.
>
> So what i'm looking for is a solution for a bean exposed through WS
and
> REST, and given we can't expose a bean through a WS when a method has
been
> annotated, a setter seems the only way forward  -  but that currently
> doesn't work.
>
>
> John Baker
> -- > Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL:  http://websso.cto.gt.intranet.db.com
>
>
>
>
> John-M Baker <[EMAIL PROTECTED]>
> 23/06/2008 12:08
> Please respond to
> users@cxf.apache.org
>
>
> To
> users@cxf.apache.org
> cc
> users@cxf.apache.org
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
> Sergey,
>
> Thanks for your feedback, and congratulations on the new 2.1.1.
release of
>
> CXF.  I'm using this release I can not get access to the
ServletContext or
>
> SecurityContext within a bean when called via REST.  Here's what I've
> added:
>
> private ServletContext sc;
>
> public void setServletContext(@Context  ServletContext sc)
> { this.sc = sc; }
>
> and
>
> private SecurityContext sc;
>
> public void setServletContext(@Context  SecurityContext sc)
> { this.sc = sc; }
>
> sc is null in both cases when a REST call is made.  Are more
annotations
> required?
>
> Any thoughts?
>
>
> John Baker
> -- > Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL:  http://websso.cto.gt.intranet.db.com
>
>
>
>
> "Sergey Beryozkin" <[EMAIL PROTECTED]>
> 23/06/2008 11:20
> Please respond to
> users@cxf.apache.org
>
>
> To
> <users@cxf.apache.org>
> cc
>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
> Yes, I don't remember offhand how, have a look at the JAX-WS docs
please,
> I think it can be injected through a field or through a
> setter. Perhaps using a setter is better in cases like this, as you
can
> then extract the common info from either JAX-WS
> WebServiceContext or JAX-RS SecurityContext.
>
> Perhaps, in the future, things like SecurityContext in both JAX-WS and
> JAX-RS can rely on some shared (CXF utility) code so that
> they can be casted to a common class to be used by the application...
>
> Cheers, Sergey
>
> ----- Original Message ----- > From: "John-M Baker" <[EMAIL PROTECTED]>
> To: <users@cxf.apache.org>
> Sent: Monday, June 23, 2008 9:36 AM
> Subject: Re: Roles and permissions
>
>
>> And how is that done?  Via a set method of some kind?
>>
>> John Baker
>> -- >> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL:  http://websso.cto.gt.intranet.db.com
>>
>>
>>
>>
>> Daniel Kulp <[EMAIL PROTECTED]>
>> 20/06/2008 18:13
>> Please respond to
>> users@cxf.apache.org
>>
>>
>> To
>> users@cxf.apache.org
>> cc
>>
>> Subject
>> Re: Roles and permissions
>>
>>
>>
>>
>>
>>
>>
>> On Jun 20, 2008, at 11:23 AM, John-M Baker wrote:
>>
>>> Hi,
>>>
>>> What was the solution to this problem?  Only apply it to the REST
>>> service?
>>> Will a future release of CXF fix it for SOAP?
>>>
>>
>> Well, JAX-WS has it's own security stuff.    Thus, for jax-ws/soap,
>> you would need the WebServiceContext injected which has the
principal/
>> role on it.
>>
>> Dan
>>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
>
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If
you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in
this
> e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> additional EU corporate and regulatory disclosures.
>
>
> ---
>
> This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or have received
this
> e-mail in error) please notify the sender immediately and delete
this e-mail. Any unauthorized copying, disclosure or distribution
> of the material in this e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm
for additional EU corporate and regulatory disclosures.

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland


---

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Reply via email to