[keycloak-dev] release soon?

[Marek Posolda]

ah, ok. I somehow didn't know that jboss-logging is already using this 
delegating approach.

Marek

On 18.11.2014 15:31, Bill Burke wrote:
> Why can't we include jboss logging?  I used to take that approach, but 
> we will eventually have to use jboss logging proxies to 
> internationalize our log messages.
>
> On 11/18/2014 8:54 AM, Marek Posolda wrote:
>> One minor thing related to common adapter, which I am thinking about,
>> could be simple logging spi. As currently tomcat, jetty and other
>> adapters need to have jboss-logging available as keycloak-adapter-core
>> have dependency on it. I wonder about creating something simple like:
>>
>> public interface KeycloakLogger {
>>    boolean isTraceEnabled();
>>    boolean isDebugEnabled();
>>    void trace(Stringm essage);
>>    void debug(String message);
>>    void info(String message);
>>    void warn(String message);
>>    void error(String message);
>>    void warn(String message, Throwable throwable);
>>    void error(String message, Throwable throwable);
>> }
>>
>> Then when you call:
>>
>> KeycloakLogger.getLogger(MyClass.class);
>>
>> it will return delegate based on jboss-logging if jboss-logging could be
>> found by classloader. Otherwise fallback to JDK logging (maybe more
>> fallbacks like log4j could be later added too if needed).
>>
>> This will apply just for keycloak-adapter-core (no need to refactor any
>> server-side code as auth-server is supposed to run on wildfly or EAP6
>> where is jboss-logging always available).
>>
>> There are some 3rd party libs like slf4j, which already works in similar
>> way, but I would rather avoid another deps (and namely slf4j could be
>> problematic) and do something simple on our own.
>>
>> wdyt?
>>
>> Marek
>>
>> On 18.11.2014 14:31, Bill Burke wrote:
>>> I'd like to do a release very soon so we can get the Jetty and Tomcat
>>> adapters into the field.  Since we now have 8 different Java adapters
>>> for 3 different servlet containers, I'm going to work on refactoring 
>>> the
>>> adapters this week to see if I can simplify the design and push more
>>> common code into a common module.
>>>
>>> After that I'd like to take a break from integration work. Maybe work
>>> on IP Filtering and/or claim support.
>>
>