Re: log4j2 API and JUL logging framework

2023-01-25 Thread Usha Nayak
Thank you again..


On Wed, Jan 25, 2023 at 10:45 AM Ralph Goers 
wrote:

> Volkan,
>
> I am not sure what question you are answering but it doesn’t look like the
> question that was asked. To answer his question you would need to replace
> log4j-core with log4j-to-jul as a dependency.
>
> Ralph
>
> > On Jan 25, 2023, at 2:05 AM, Volkan Yazıcı  wrote:
> >
> > That is a really good question addressing a concern that should be shared
> > by every single Java library developer out there, Usha. We sadly don't
> have
> > an official answer to this – we should and maybe who knows, you can
> > contribute that to the Log4j manual! But let me share my take on the
> matter.
> >
> > Libraries should only depend on logging APIs (SLF4J, Log4j, JUL, JCL,
> JPL,
> > etc.) and only provide an implementation (Log4j, Logback, etc.) for their
> > tests. Let me try to get it as concrete as possible by sharing what you
> > need to have in your `pom.xml`:
> >
> > 
> >  
> >
> >
> >  org.apache.logging.log4j
> >  log4j-bom
> >  ${log4j2.version}
> >  pom
> >  import
> >
> >
> >  
> > 
> >
> > 
> >
> >  
> >org.apache.logging.log4j
> >log4j-api
> >  
> >
> >  
> >org.apache.logging.log4j
> >log4j-core
> >test
> >  
> >
> >  
> >
> > 
> >
> > Next you add a minimal `log4j2.xml` to `src/test/resources` and you are
> > done.
> >
> > It is the responsibility of the application which will be glueing all
> these
> > libraries together to decide on where to and how to bind all these
> logging
> > APIs. As a matter of fact, many modern application frameworks provide
> > goodies to save you from that burden; consider
> `spring-boot-starter-log4j2`.
> >
> > On Wed, Jan 25, 2023 at 12:01 AM Usha Nayak  wrote:
> >
> >> Hello All,
> >>
> >> As a library owner, if I were to use the log4j2 API and the application
> >> that uses my library has a java.util.logging ( JUL ) framework.
> >>
> >> What adapter or routing jars will be needed at runtime by application
> such
> >> that all the logs, both from the library and the application, end up
> using
> >> the same logging framework implementation (JUL) ?
> >>
> >> Any help greatly appreciated
> >>
> >> Thanks
> >>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>


Re: log4j2 API and JUL logging framework

2023-01-25 Thread Ralph Goers
Volkan,

I am not sure what question you are answering but it doesn’t look like the 
question that was asked. To answer his question you would need to replace 
log4j-core with log4j-to-jul as a dependency.

Ralph

> On Jan 25, 2023, at 2:05 AM, Volkan Yazıcı  wrote:
> 
> That is a really good question addressing a concern that should be shared
> by every single Java library developer out there, Usha. We sadly don't have
> an official answer to this – we should and maybe who knows, you can
> contribute that to the Log4j manual! But let me share my take on the matter.
> 
> Libraries should only depend on logging APIs (SLF4J, Log4j, JUL, JCL, JPL,
> etc.) and only provide an implementation (Log4j, Logback, etc.) for their
> tests. Let me try to get it as concrete as possible by sharing what you
> need to have in your `pom.xml`:
> 
> 
>  
> 
>
>  org.apache.logging.log4j
>  log4j-bom
>  ${log4j2.version}
>  pom
>  import
>
> 
>  
> 
> 
> 
> 
>  
>org.apache.logging.log4j
>log4j-api
>  
> 
>  
>org.apache.logging.log4j
>log4j-core
>test
>  
> 
>  
> 
> 
> 
> Next you add a minimal `log4j2.xml` to `src/test/resources` and you are
> done.
> 
> It is the responsibility of the application which will be glueing all these
> libraries together to decide on where to and how to bind all these logging
> APIs. As a matter of fact, many modern application frameworks provide
> goodies to save you from that burden; consider `spring-boot-starter-log4j2`.
> 
> On Wed, Jan 25, 2023 at 12:01 AM Usha Nayak  wrote:
> 
>> Hello All,
>> 
>> As a library owner, if I were to use the log4j2 API and the application
>> that uses my library has a java.util.logging ( JUL ) framework.
>> 
>> What adapter or routing jars will be needed at runtime by application such
>> that all the logs, both from the library and the application, end up using
>> the same logging framework implementation (JUL) ?
>> 
>> Any help greatly appreciated
>> 
>> Thanks
>> 


-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org



Re: log4j2 API and JUL logging framework

2023-01-25 Thread Volkan Yazıcı
That is a really good question addressing a concern that should be shared
by every single Java library developer out there, Usha. We sadly don't have
an official answer to this – we should and maybe who knows, you can
contribute that to the Log4j manual! But let me share my take on the matter.

Libraries should only depend on logging APIs (SLF4J, Log4j, JUL, JCL, JPL,
etc.) and only provide an implementation (Log4j, Logback, etc.) for their
tests. Let me try to get it as concrete as possible by sharing what you
need to have in your `pom.xml`:


  


  org.apache.logging.log4j
  log4j-bom
  ${log4j2.version}
  pom
  import


  




  
org.apache.logging.log4j
log4j-api
  

  
org.apache.logging.log4j
log4j-core
test
  

  



Next you add a minimal `log4j2.xml` to `src/test/resources` and you are
done.

It is the responsibility of the application which will be glueing all these
libraries together to decide on where to and how to bind all these logging
APIs. As a matter of fact, many modern application frameworks provide
goodies to save you from that burden; consider `spring-boot-starter-log4j2`.

On Wed, Jan 25, 2023 at 12:01 AM Usha Nayak  wrote:

> Hello All,
>
> As a library owner, if I were to use the log4j2 API and the application
> that uses my library has a java.util.logging ( JUL ) framework.
>
> What adapter or routing jars will be needed at runtime by application such
> that all the logs, both from the library and the application, end up using
> the same logging framework implementation (JUL) ?
>
> Any help greatly appreciated
>
> Thanks
>