users@jersey.java.net

Re: [Jersey] Re: _at_RolesAllowed

From: Christopher Piggott <cpiggott_at_gmail.com>
Date: Wed, 9 Jun 2010 09:45:42 -0400

Yes, I figured it out. I had several problems. One was that when I did this:

        sa.addServletListener(ProtobufServletConfig.class.getName());

The thing I had incorrectly specified caused it, for some reason, to
create a brand new ServletModule every time, causing the warnings.
This sort of bug bothers me. I really wish .addServletListener()
would take a <? extends ServletModule> instead of a string. I don't
like things that take strings when they really mean class names.

Another problem was just stupidity.... my server registration was:

        serve("/").with(something)

This didn't work at all... it needed to be serve("*"). It took me a
while to find this, too, because the result was a 200 OK with no
content, regardless of the request.

The way I figured this out was by starting a brand new project from
scratch, and adding in pieces one at a time. When I got to the end it
worked, so I then went back line by line to figure out what was
different.

Logging helped a lot. I didn't exactly know what logging to turn on,
so I turned on everything, identified what I wanted, and then turned
on those specific things. For example:

        org.apache.log4j.Logger.getLogger("com.google.inject.internal.Stopwatch").setLevel(Level.OFF);
        org.apache.log4j.Logger.getLogger("com.google.inject").setLevel(Level.INFO);

lets me see more or less what guice is doing, but without all the
noisy Stopwatch messages that I don't care about (at least right now).

        org.apache.log4j.Logger.getLogger("com.sun.grizzly").setLevel(Level.ALL);


gives you some idea what grizzly is doing, but also tells you a lot of
things that are fairly difficult to understand (less verbose levels
like INFO are perhaps more helpful).

On the jersey side, watching
com.sun.jersey.api.core.ScanningResourceConfig lets me see what the
package scanner finds (both resources and providers).

So, the logging really does help.

BTW if you're wondering why I'm referring to log4j there ... jersey
writes to java.util.logging but in my case, I have a number of
components that of course use their own logging frameworks. To
resolve this, I use slf4j to capture j.u.l and jcl, then forward all
of that to the logger I really want to use under the hood, log4j. I
set up a log4j socket appender so that I can pick the logging up live
with chainsaw. It's all very useful for debugging.

--C



On Wed, Jun 9, 2010 at 12:42 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Hi Christopher,
>
> Does this mean you have solved your Guice configuration issues?
>
>
> On Jun 9, 2010, at 1:07 AM, Christopher Piggott wrote:
>
>> Seems like I can't do this, the PROPERTY_CONTAINER_REQUEST_FILTERS
>> seem to need to have a default constructor... unless somebody knows
>> some trick.
>>
>>
>
> Can you share some code?
>
> The registered AuthenticationFilter class will be treated as a component so
> injection should be possible. Are there any errors in the logs related to
> instantiation of that class?
>
> Note that Jersey's support for @RolesAllowed is only supported on resource
> classes.
>
> Paul.
>
>
>>
>>
>>
>> On Tue, Jun 8, 2010 at 4:48 PM, Christopher Piggott <cpiggott_at_gmail.com>
>> wrote:
>>>
>>> My configuration is
>>>  grizzly-servlet-webserver 2.0.0-M3 (and required friends)
>>>  jersey-server 1.2
>>>  jersey-guice 1.2
>>>  guice 2.0
>>>
>>>
>>>
>>> I'm not doing much to initialize it.  My ServletAdapter is configured
>>> with:
>>>
>>>
>>> sa.addInitParameter(ResourceConfig.PROPERTY_CONTAINER_REQUEST_FILTERS,
>>>               AuthenticationFilter.class.getName());
>>>
>>> sa.addInitParameter(ResourceConfig.PROPERTY_RESOURCE_FILTER_FACTORIES,
>>>               RolesAllowedResourceFilterFactory.class.getName());
>>>       sa.addServletListener(ProtobufServletConfig.class.getName());
>>>       sa.addFilter(new GuiceFilter(), "guiceFilter", null);
>>>
>>> AuthenticationFilter.class is mine, jersey is working fine / answering
>>> requests but @RolesAllowed does nothing to restrict its behavior and,
>>> in fact, no instance of my AuthenticationFilter ever gets
>>> instantiated.
>>>
>>> Is it OK that my AuthenticationFilter wants to be created by
>>> injection?  I'm not seeing any guice errors saying it can't do so, and
>>> in my ServletModule.configureServlets() I'm binding the
>>> AuthenticationProvider class to a specific implementation.
>>>
>>> Does that sound correct?
>>>
>>> --C
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>