users@jersey.java.net

Re: [Jersey] _at_SessionParam or _at_SessionAttribute

From: <FSauer_at_dsthealthsolutions.com>
Date: Mon, 25 Jan 2010 12:14:27 -0600

I think that is not a good example. That id should be part of the URI. I
can see limited use of session data - like for security related stuff, but
definitely not for resource identifying information. The URI is the
identifier.




Erdinc Yilmazel <erdinc_at_yilmazel.com>
Sent by: erdincyilmazel_at_gmail.com
01/25/2010 11:15 AM
Please respond to
users_at_jersey.dev.java.net


To
users_at_jersey.dev.java.net
cc

Subject
Re: [Jersey] @SessionParam or @SessionAttribute






Ok, I know that the session concept is not a Rest style approach and It
may not be a best practice, however I believe Jersey is not just the
reference implementation of JAXRS. I know many people using it as a
general purpose web framework including me. When you start using it as a
web framework your resource classes become more like services and you try
to consume these services from other services as much as you can. Imagine
a method which returns an Entity/Resource which requires an Id which will
be looked up from the session. The two alternative implementations would
be like follows:

@GET
public A getA(@Context HttpServletRequest request) {
   HttpSession session = request.getSession();
   session.getAttribute("keyForA");
   /// return A
}

or

@GET
public A getA(@SessionAttribute("keyForA") String key) {
   /// return A
}

I believe the second method is much more efficient in terms of
reusability. You can't simply create a HttpServletRequest object to call
the first method.

I think even if it is not supported as a built-in feature, these kind of
extra utilities can be bundled in an external jar.

Erdinc



On Mon, Jan 25, 2010 at 4:53 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
See #6 at:

http://www.prescod.net/rest/mistakes/

While its possible to use sessions via an injected HttpServletRequest, we
don't want to make it too easy to do the wrong thing.

Marc.

On Jan 25, 2010, at 11:40 AM, Erdinc Yilmazel wrote:

> Sorry if I am mistaken, but I wonder why there isn't a built-in
annotation for injecting session attributes in Jersey? I know you can
inject HttpServletRequest and access session attributes using it, but that
is a lot of typing.
>
> Writing a @SessionAttribute annotation is achievable by just
implementing three classes...
>
> @Target({ElementType.PARAMETER, ElementType.METHOD, ElementType.FIELD})
> @Retention(RetentionPolicy.RUNTIME)
> @Documented
> public @interface SessionAttribute {
> String value();
> }
>
> ------------------
>
> @Provider
> public class SessionParamProvider implements
InjectableProvider<SessionAttribute, Type> {
>
> @Override
> public ComponentScope getScope() {
> return ComponentScope.PerRequest;
> }
>
> @Context
> HttpServletRequest requestProxy;
>
> @Override
> public Injectable<Object> getInjectable(ComponentContext ic,
SessionAttribute a, Type type) {
> return new SessionAttributeInjectable(a.value(), requestProxy);
> }
> }
>
> -------------------
> public class SessionAttributeInjectable implements Injectable<Object> {
> String attributeName;
>
> public SessionAttributeInjectable(String attributeName,
HttpServletRequest requestProxy) {
> this.attributeName = attributeName;
> this.request = requestProxy;
> }
>
> HttpServletRequest request;
>
> @Override
> public Object getValue() {
> HttpSession session = request.getSession(true);
> return session.getAttribute(attributeName);
> }
> }
>
>
> Erdinc


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net




-----------------------------------------
Please consider the environment before printing this email and any
attachments.

This e-mail and any attachments are intended only for the
individual or company to which it is addressed and may contain
information which is privileged, confidential and prohibited from
disclosure or unauthorized use under applicable law. If you are
not the intended recipient of this e-mail, you are hereby notified
that any use, dissemination, or copying of this e-mail or the
information contained in this e-mail is strictly prohibited by the
sender. If you have received this transmission in error, please
return the material received to the sender and delete all copies
from your system.