users@jersey.java.net

Re: Re: [Jersey] Resource Filter Factory injectables

From: John Lister <john.lister_at_kickstone.com>
Date: Tue, 13 Apr 2010 20:01:39 +0100

Hi Paul, thanks for your pointers, I seem to have solved it...

Firstly, I was trying to increase the logging level and was failing
miserably, so download the source code (should have done this ages ago)
and ended up stepping through the creation of my objects.

A few things are going on.
Firstly I seemed to have been using the wrong ManagedBean annotation
javax.faces.jsf instead of javax.annotation - I'm sure I had tried the
latter originally with no luck hence the switch. Also did 1.1.5 change
anything as I recently updated the jersey libs on my glassfish box.

Secondly if I include the constructor, then using @ManagedBean cause an
error on deployment because cdi can't find a default constructor. Using
@ApplicationScope doesn't generate an error but doesn't inject anything.

Finally, removing the constructor and using either annotation does
indeed work as expected - Again thought I had tried this combination
before...

Either way thanks for your pointers

John


Paul Sandoz wrote:
> Hi John,
>
> Can you send your servlet log output. I would like to see the JCDI
> related info logging.
>
> The strange thing is that if CDI was enabled I would have expected
> deployment to fail because CDI will not know what to do with the
> constructor.
>
> If you use @ManagedBean and CDI is enabled Jersey will defer to the
> CDI framework for instantiation, which should perform injection.
> Otherwise, Jersey will defer to the GF EJB framework for
> instantiation, which should perform EE-artifact injection like for
> @PersistenceContext.
>
> If you use @ManagedBean with a Jersey scope annotation then Jersey
> will manage the life-cycle otherwise if you use a CDI scope annotation
> then CDI will manage the life-cycle. But in either case CDI-related
> artifacts should be injected.
>
> Thus when using CDI @ManagedBean is actually redundant, and the
> simplest thing is not to use it.
>
> For CDI try this:
>
> @ApplicationScoped
> public class PriceGoblinResourceFilterFactory implements
> ResourceFilterFactory {
> @Inject @TestBean bean;
>
> @PersistenceContext(unitName="PU")
> private EntityManager em;
>
> // default constructor
> // public PriceGoblinResourceFilterFactory() {}
> }
>
> Paul.
>
> On Apr 12, 2010, at 11:32 PM, John Lister wrote:
>
>> Hi paul, see below for my factory class, nothing too complicated...
>>
>> for reference using glassfish v3 with jersey 1.1.5-1. In addition I'm
>> using jersey as a servlet filter with the
>> com.sun.jersey.spi.container.ResourceFilters paramter set to my
>> factory class which is listed below:
>>
>> *******************************
>> package com.kickstone.pricegoblin.filters;
>>
>> import com.kickstone.pricegoblin.annotations.AuthorisationFilterRef;
>> import com.kickstone.pricegoblin.annotations.Authorised;
>> import com.sun.jersey.api.model.AbstractMethod;
>> import com.sun.jersey.api.model.AbstractResourceMethod;
>> import com.sun.jersey.spi.container.ResourceFilter;
>> import com.sun.jersey.spi.container.ResourceFilterFactory;
>> import java.util.Collections;
>> import java.util.List;
>> import javax.faces.bean.ManagedBean;
>> import javax.persistence.EntityManagerFactory;
>> import javax.servlet.http.HttpServletRequest;
>> import javax.ws.rs.core.Context;
>>
>> // tried it with and without this:
>> @ManagedBean
>> public class PriceGoblinResourceFilterFactory implements
>> ResourceFilterFactory {
>>
>> // doesn't get injected..
>> // where MyBean is a SessionScoped CDI bean that works in other
>> contexts.
>> @Inject @TestBean bean;
>>
>> // neither does this
>> @PersistenceContext(unitName="PU")
>> private EntityManager em;
>>
>> private final HttpServletRequest hsr;
>>
>> // This does get injected either in the constructor form or as a
>> annotated field
>> // removing this constructor makes no difference to the above
>> public PriceGoblinResourceFilterFactory(@Context HttpServletRequest
>> hsr){
>> this.hsr=hsr;
>> }
>>
>> // make some checks and return the filter - I've stripped the
>> checks as they just clog up the class...
>> public List<ResourceFilter> create(AbstractMethod am) {
>> // Is the class, method flagged as authorised
>> if (someCheck)
>> return Collections.<ResourceFilter>singletonList(new
>> AuthorisationResourceFilter(hsr, bean, em));
>> return null;
>> }
>> }
>> *******************************
>>
>>
>> Hope this sheds some light on things... I noticed that in a standard
>> non-factory produced filter, all of the above injections seem to work
>> fine (see my other post) but no matter what I try, I can't seem to
>> get it to work with a factory...
>>
>> Thanks for your help
>>
>> John
>>
>> Paul Sandoz wrote:
>>> Hi John,
>>>
>>> Can you share your ResourceFilterFactory code?
>>>
>>> Paul.
>>>
>>> On Apr 11, 2010, at 9:32 PM, John Lister wrote:
>>>
>>>> Hi, I'm trying to create a resource filter by using a factory that
>>>> determines which filter is required based on a number of factors
>>>> but struggling with one issue.
>>>>
>>>> Because I create the filter objects in the factory class using new,
>>>> I cannot use any injectable content within them, to get around this
>>>> I'm injecting some things into the factory object and passing them
>>>> as parameters to the filter classes. However I'm struggling to find
>>>> a way to inject some types of content and wondered if any one can
>>>> give me any advice. For example I would like to inject a
>>>> @SessionScoped (or RequestScoped) bean and additionally an
>>>> EntityManager but when I do using either Inject or Context I get
>>>> nulls.
>>>>
>>>> To get around this at the minute I have a global resource filter
>>>> that I can inject things into with no problems and I'm setting
>>>> attributes on a HttpServletRequest object and retrieving them
>>>> within the factory generated filters.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks
>>>>
>>>> John
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> </div>