Re: Yet another logging facade

[Ralph Goers]

See 
http://stackoverflow.com/questions/41633278/can-we-use-all-features-of-log4j2-if-we-use-it-along-with-slf4j-api/41635246#41635246
 
.
 Note that item 10 on this list was recently fixed.

Ralph


> On Apr 7, 2017, at 12:04 PM, Ralph Goers  wrote:
> 
> I just took a look at the list. I don’t see the response that points to 
> bugzilla.
> 
> In your comment you mentioned that Log4j provides an api but you didn’t list 
> the reasons why it is better. Remko posted a stack overflow post that has 10 
> reasons why it is better.  But more importantly, users have been asking for 
> enhancements to the SLF4J API for quite a while. Eventually the API is going 
> to have to be enhanced. How is OSGi going to accommodate for that?
> 
> Ralph
> 
>> On Apr 7, 2017, at 9:40 AM, Matt Sicker > > wrote:
>> 
>> I got a response on the mailing list. There's a public bugzilla we can 
>> comment on apparently which is linked in the PDF.
>> 
>> On 6 April 2017 at 20:02, Matt Sicker > > wrote:
>> I'm not sure where they develop the standards, but there's an osgi-dev 
>> mailing list (where I found this posted today): 
>> https://www.osgi.org/community/mail-lists/ 
>> 
>> 
>> I don't see Apache on this list despite being the foundation behind most of 
>> the open source OSGi projects out there: 
>> https://www.osgi.org/about-us/members/ 
>> 
>> 
>> However, there are many companies on that list who directly contribute to 
>> said Apache projects.
>> 
>> I can't find any info on their site about how to offer feedback. This is 
>> just as (if not more) convoluted than the JCP.
>> 
>> On 6 April 2017 at 19:41, Gary Gregory > > wrote:
>> A quick review of the document appears to have SLF4J as a requirement. Shame 
>> about that. 
>> 
>> Gary
>> 
>> On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers > > wrote:
>> Where does one comment on these?
>> 
>> The problem is that they mention Java 8 support, but SLF4J doesn’t take 
>> advantage of any Java 8 features yet. No support for Lamda’s.  From what I 
>> am seeing the next release will support running in Java 9 and will leverage 
>> StackWalker and support Java modules but Ceki hasn’t mentioned if he is 
>> going to add to the API to support things users have been asking for.
>> 
>> I’d hate to see them base their standard on what was then the current 
>> release of SLF4J and then for it to be enhanced and they are stuck with a 
>> limited API.
>> 
>> I wonder how much input, if any, Ceki had in this.  
>> 
>> As a side note, he also changed the binding mechanism and I am not sure if 
>> it is backward compatible, soI have a feeling log4j-slf4j-impl will need 
>> changes to support that version. 
>> 
>> Ralph
>> 
>> 
>>> On Apr 6, 2017, at 4:00 PM, Remko Popma >> > wrote:
>>> 
>>> Good find. I noticed that the document points to Apache Sling and says 
>>> "uses the most common parts today used for logging: SLF4J for clients and 
>>> logback for processing."  Seems like Sling decided that in 2013 and never 
>>> looked back. Which is fine, but I believe Log4j2 has changed the landscape 
>>> the last 4 years. 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Apr 7, 2017, at 6:08, Matt Sicker >> > wrote:
>>> 
 OSGi is looking at updating their logging API:
 
 https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
  
 
 
 We might want to provide feedback.
 
 -- 
 Matt Sicker >
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>>   
>> 
>> JUnit in Action, Second Edition 
>> 
>>   
>> 
>> Spring Batch in Action 
>> 
>>   

Re: Yet another logging facade

[Ralph Goers]

I just took a look at the list. I don’t see the response that points to 
bugzilla.

In your comment you mentioned that Log4j provides an api but you didn’t list 
the reasons why it is better. Remko posted a stack overflow post that has 10 
reasons why it is better.  But more importantly, users have been asking for 
enhancements to the SLF4J API for quite a while. Eventually the API is going to 
have to be enhanced. How is OSGi going to accommodate for that?

Ralph

> On Apr 7, 2017, at 9:40 AM, Matt Sicker  wrote:
> 
> I got a response on the mailing list. There's a public bugzilla we can 
> comment on apparently which is linked in the PDF.
> 
> On 6 April 2017 at 20:02, Matt Sicker  > wrote:
> I'm not sure where they develop the standards, but there's an osgi-dev 
> mailing list (where I found this posted today): 
> https://www.osgi.org/community/mail-lists/ 
> 
> 
> I don't see Apache on this list despite being the foundation behind most of 
> the open source OSGi projects out there: 
> https://www.osgi.org/about-us/members/ 
> 
> 
> However, there are many companies on that list who directly contribute to 
> said Apache projects.
> 
> I can't find any info on their site about how to offer feedback. This is just 
> as (if not more) convoluted than the JCP.
> 
> On 6 April 2017 at 19:41, Gary Gregory  > wrote:
> A quick review of the document appears to have SLF4J as a requirement. Shame 
> about that. 
> 
> Gary
> 
> On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers  > wrote:
> Where does one comment on these?
> 
> The problem is that they mention Java 8 support, but SLF4J doesn’t take 
> advantage of any Java 8 features yet. No support for Lamda’s.  From what I am 
> seeing the next release will support running in Java 9 and will leverage 
> StackWalker and support Java modules but Ceki hasn’t mentioned if he is going 
> to add to the API to support things users have been asking for.
> 
> I’d hate to see them base their standard on what was then the current release 
> of SLF4J and then for it to be enhanced and they are stuck with a limited API.
> 
> I wonder how much input, if any, Ceki had in this.  
> 
> As a side note, he also changed the binding mechanism and I am not sure if it 
> is backward compatible, soI have a feeling log4j-slf4j-impl will need changes 
> to support that version. 
> 
> Ralph
> 
> 
>> On Apr 6, 2017, at 4:00 PM, Remko Popma > > wrote:
>> 
>> Good find. I noticed that the document points to Apache Sling and says "uses 
>> the most common parts today used for logging: SLF4J for clients and logback 
>> for processing."  Seems like Sling decided that in 2013 and never looked 
>> back. Which is fine, but I believe Log4j2 has changed the landscape the last 
>> 4 years. 
>> 
>> Sent from my iPhone
>> 
>> On Apr 7, 2017, at 6:08, Matt Sicker > > wrote:
>> 
>>> OSGi is looking at updating their logging API:
>>> 
>>> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
>>>  
>>> 
>>> 
>>> We might want to provide feedback.
>>> 
>>> -- 
>>> Matt Sicker >
> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
>   
> 
> JUnit in Action, Second Edition 
> 
>   
> 
> Spring Batch in Action 
> 
>   
> 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 
> 
> 
> -- 
> Matt Sicker >
> 
> 
> 
> -- 
> Matt Sicker >

Re: Yet another logging facade

[Matt Sicker]

I got a response on the mailing list. There's a public bugzilla we can
comment on apparently which is linked in the PDF.

On 6 April 2017 at 20:02, Matt Sicker  wrote:

> I'm not sure where they develop the standards, but there's an osgi-dev
> mailing list (where I found this posted today): https://www.osgi.org/
> community/mail-lists/
>
> I don't see Apache on this list despite being the foundation behind most
> of the open source OSGi projects out there: https://www.osgi.org/
> about-us/members/
>
> However, there are many companies on that list who directly contribute to
> said Apache projects.
>
> I can't find any info on their site about how to offer feedback. This is
> just as (if not more) convoluted than the JCP.
>
> On 6 April 2017 at 19:41, Gary Gregory  wrote:
>
>> A quick review of the document appears to have SLF4J as a requirement.
>> Shame about that.
>>
>> Gary
>>
>> On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers 
>> wrote:
>>
>>> Where does one comment on these?
>>>
>>> The problem is that they mention Java 8 support, but SLF4J doesn’t take
>>> advantage of any Java 8 features yet. No support for Lamda’s.  >From what I
>>> am seeing the next release will support running in Java 9 and will leverage
>>> StackWalker and support Java modules but Ceki hasn’t mentioned if he is
>>> going to add to the API to support things users have been asking for.
>>>
>>> I’d hate to see them base their standard on what was then the current
>>> release of SLF4J and then for it to be enhanced and they are stuck with a
>>> limited API.
>>>
>>> I wonder how much input, if any, Ceki had in this.
>>>
>>> As a side note, he also changed the binding mechanism and I am not sure
>>> if it is backward compatible, soI have a feeling log4j-slf4j-impl will need
>>> changes to support that version.
>>>
>>> Ralph
>>>
>>>
>>> On Apr 6, 2017, at 4:00 PM, Remko Popma  wrote:
>>>
>>> Good find. I noticed that the document points to Apache Sling and says
>>> "uses the most common parts today used for logging: SLF4J for clients and
>>> logback for processing."  Seems like Sling decided that in 2013 and never
>>> looked back. Which is fine, but I believe Log4j2 has changed the landscape
>>> the last 4 years.
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 7, 2017, at 6:08, Matt Sicker  wrote:
>>>
>>> OSGi is looking at updating their logging API:
>>>
>>> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-
>>> 0219-LogService-Update.pdf
>>>
>>> We might want to provide feedback.
>>>
>>> --
>>> Matt Sicker 
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker 
>



-- 
Matt Sicker 

Re: Yet another logging facade

[Matt Sicker]

I'm not sure where they develop the standards, but there's an osgi-dev
mailing list (where I found this posted today):
https://www.osgi.org/community/mail-lists/

I don't see Apache on this list despite being the foundation behind most of
the open source OSGi projects out there:
https://www.osgi.org/about-us/members/

However, there are many companies on that list who directly contribute to
said Apache projects.

I can't find any info on their site about how to offer feedback. This is
just as (if not more) convoluted than the JCP.

On 6 April 2017 at 19:41, Gary Gregory  wrote:

> A quick review of the document appears to have SLF4J as a requirement.
> Shame about that.
>
> Gary
>
> On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers 
> wrote:
>
>> Where does one comment on these?
>>
>> The problem is that they mention Java 8 support, but SLF4J doesn’t take
>> advantage of any Java 8 features yet. No support for Lamda’s.  From what I
>> am seeing the next release will support running in Java 9 and will leverage
>> StackWalker and support Java modules but Ceki hasn’t mentioned if he is
>> going to add to the API to support things users have been asking for.
>>
>> I’d hate to see them base their standard on what was then the current
>> release of SLF4J and then for it to be enhanced and they are stuck with a
>> limited API.
>>
>> I wonder how much input, if any, Ceki had in this.
>>
>> As a side note, he also changed the binding mechanism and I am not sure
>> if it is backward compatible, soI have a feeling log4j-slf4j-impl will need
>> changes to support that version.
>>
>> Ralph
>>
>>
>> On Apr 6, 2017, at 4:00 PM, Remko Popma  wrote:
>>
>> Good find. I noticed that the document points to Apache Sling and says
>> "uses the most common parts today used for logging: SLF4J for clients and
>> logback for processing."  Seems like Sling decided that in 2013 and never
>> looked back. Which is fine, but I believe Log4j2 has changed the landscape
>> the last 4 years.
>>
>> Sent from my iPhone
>>
>> On Apr 7, 2017, at 6:08, Matt Sicker  wrote:
>>
>> OSGi is looking at updating their logging API:
>>
>> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-
>> 0219-LogService-Update.pdf
>>
>> We might want to provide feedback.
>>
>> --
>> Matt Sicker 
>>
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker 

Re: Yet another logging facade

[Gary Gregory]

A quick review of the document appears to have SLF4J as a requirement.
Shame about that.

Gary

On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers 
wrote:

> Where does one comment on these?
>
> The problem is that they mention Java 8 support, but SLF4J doesn’t take
> advantage of any Java 8 features yet. No support for Lamda’s.  From what I
> am seeing the next release will support running in Java 9 and will leverage
> StackWalker and support Java modules but Ceki hasn’t mentioned if he is
> going to add to the API to support things users have been asking for.
>
> I’d hate to see them base their standard on what was then the current
> release of SLF4J and then for it to be enhanced and they are stuck with a
> limited API.
>
> I wonder how much input, if any, Ceki had in this.
>
> As a side note, he also changed the binding mechanism and I am not sure if
> it is backward compatible, soI have a feeling log4j-slf4j-impl will need
> changes to support that version.
>
> Ralph
>
>
> On Apr 6, 2017, at 4:00 PM, Remko Popma  wrote:
>
> Good find. I noticed that the document points to Apache Sling and says
> "uses the most common parts today used for logging: SLF4J for clients and
> logback for processing."  Seems like Sling decided that in 2013 and never
> looked back. Which is fine, but I believe Log4j2 has changed the landscape
> the last 4 years.
>
> Sent from my iPhone
>
> On Apr 7, 2017, at 6:08, Matt Sicker  wrote:
>
> OSGi is looking at updating their logging API:
>
> https://github.com/osgi/design/blob/master/rfcs/
> rfc0219/rfc-0219-LogService-Update.pdf
>
> We might want to provide feedback.
>
> --
> Matt Sicker 
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Yet another logging facade

[Ralph Goers]

Where does one comment on these?

The problem is that they mention Java 8 support, but SLF4J doesn’t take 
advantage of any Java 8 features yet. No support for Lamda’s.  From what I am 
seeing the next release will support running in Java 9 and will leverage 
StackWalker and support Java modules but Ceki hasn’t mentioned if he is going 
to add to the API to support things users have been asking for.

I’d hate to see them base their standard on what was then the current release 
of SLF4J and then for it to be enhanced and they are stuck with a limited API.

I wonder how much input, if any, Ceki had in this.  

As a side note, he also changed the binding mechanism and I am not sure if it 
is backward compatible, soI have a feeling log4j-slf4j-impl will need changes 
to support that version. 

Ralph


> On Apr 6, 2017, at 4:00 PM, Remko Popma  wrote:
> 
> Good find. I noticed that the document points to Apache Sling and says "uses 
> the most common parts today used for logging: SLF4J for clients and logback 
> for processing."  Seems like Sling decided that in 2013 and never looked 
> back. Which is fine, but I believe Log4j2 has changed the landscape the last 
> 4 years. 
> 
> Sent from my iPhone
> 
> On Apr 7, 2017, at 6:08, Matt Sicker  > wrote:
> 
>> OSGi is looking at updating their logging API:
>> 
>> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
>>  
>> 
>> 
>> We might want to provide feedback.
>> 
>> -- 
>> Matt Sicker >

Re: Yet another logging facade

[Remko Popma]

Good find. I noticed that the document points to Apache Sling and says "uses 
the most common parts today used for logging: SLF4J for clients and logback for 
processing."  Seems like Sling decided that in 2013 and never looked back. 
Which is fine, but I believe Log4j2 has changed the landscape the last 4 years. 

Sent from my iPhone

> On Apr 7, 2017, at 6:08, Matt Sicker  wrote:
> 
> OSGi is looking at updating their logging API:
> 
> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
> 
> We might want to provide feedback.
> 
> -- 
> Matt Sicker