Jersey 2.x is using same Java util logging as Jersey 1.x. There is no difference I would be aware of. The root logger name "org.glassfish.jersey" is correct. You should only need CONFIG level to get the list of resources etc. It seems to me that the problem is somewhere in your SLF4J configuration.
For instance, if I take any jersey example, e.g. this one and create a custom JUL logging.properties file with this content:
#All attributes details
handlers=java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=FINEST
java.util.logging.SimpleFormatter.format=%4$-7s [%3$s] %5$s%6$s%n
#All log level details
.level=INFO
org.glassfish.jersey.level=CONFIG
in the example root directory, and then run the example (in this case via embedded jetty servlet maven plugin):
$ mvn jetty:run -Djava.util.logging.config.file=logging.properties
I can see the following information getting logged at the startup:
INFO [org.glassfish.jersey.server.ApplicationHandler] Initiating Jersey application, version Jersey: 2.5.1-SNAPSHOT 2013-12-18 18:48:21...
CONFIG [org.glassfish.jersey.process.internal.RequestExecutorFactory] "No custom request executor provider registrations found - using default: [org.glassfish.jersey.server.ServerManagedAsyncExecutorFactory$1]."
CONFIG [org.glassfish.jersey.server.ApplicationHandler] Jersey application initialized.
Root Resource Classes:
org.glassfish.jersey.examples.flight.resources.FlightsResource
org.glassfish.jersey.examples.flight.resources.FlightSimResource
org.glassfish.jersey.examples.flight.resources.AircraftsResource
Pre-match Filters:
org.glassfish.jersey.server.filter.HttpMethodOverrideFilter
Global Request Filters:
org.glassfish.jersey.examples.flight.providers.ContainerAuthFilter
Global Reader Interceptors:
org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor
Global Writer Interceptors:
org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor
org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor
org.glassfish.jersey.server.mvc.internal.TemplateMethodInterceptor
Dynamic Features:
org.glassfish.jersey.server.filter.RolesAllowedDynamicFeature_at_2f3c02d4
Message Body Readers:
org.glassfish.jersey.moxy.json.internal.FilteringMoxyJsonProvider
Message Body Writers:
org.glassfish.jersey.moxy.json.internal.FilteringMoxyJsonProvider
org.glassfish.jersey.server.validation.internal.ValidationErrorMessageBodyWriter
org.glassfish.jersey.media.sse.OutboundEventWriter
In other words, the logging works if configured properly.
Marek
On 14 Dec 2013, at 19:24, Robert DiFalco <robert.difalco_at_gmail.com> wrote:
> Sorry, with 2.4.1 I cannot figure out server-side logging, I had it working in 1.9.
>
> I use the following logging setup during initialization:
>
> // Optionally remove existing handlers attached to j.u.l root logger
> SLF4JBridgeHandler.removeHandlersForRootLogger(); // (since SLF4J 1.6.5)
>
> // add SLF4JBridgeHandler to j.u.l's root logger, should be done once during
> // the initialization phase of your application
> SLF4JBridgeHandler.install();
>
>
> Then I put this into my logback.xml file:
>
> <logger name="org.glassfish.jersey" level="DEBUG" />
>
> I'm looking for things like resources being loaded, etc. but I'm seeing nothing. How should I be doing this?
>
> Thanks!
>
>