Exactly,
http://yatel.kramolis.cz/2013/11/how-to-configure-jdk-logging-for-jersey.html
On 18 Dec 2013, at 20:38, Marek Potociar <marek.potociar_at_oracle.com> wrote:
> 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!
>>
>>
>