[slf4j-dev] jcl-over-slf4j module not building

[Jacob Kjome]

At 04:27 PM 2/19/2007, you wrote:
>On 2/19/07, Jacob Kjome <<mailto:hoju at visi.com>hoju at visi.com> wrote:
>
>BTW, if SLF4J used the Service API, I think it would have to be a home grown
>one.  Clearly SLF4J cannot depend on com.sun.* or JDK1.6.  So, the Service
>stuff would have to be written from scratch and shipped with the 
>API.  I'm not
>sure how involved this would be as I'm not sure how much plumbing code would
>need to be written.  Eric, can you address this point?
>
>
>The common practice is use to the sun.misc.* version to get going 
>quickly. Although this is a sun.misc.* class, its actually pretty 
>stable, and they (Sun) do a decent job of keeping it compatible 
>since a lot of people use it - like the Base64Encoder class. If you 
>want to garuntee the solution still works on non-Sun JVMs, or you 
>are just generally more comfortable not using using the sun.misc.* 
>classes, it is fairly trivial to start with the sun.misc.* one for 
>now; and drop in a replacement that we write. Its not too difficult 
>to make up your own - its really a pretty simple class.

I'm quite sure that depending on com.sun.* is not an option for an 
open source project.  I'd never allow it for Log4j and I can't 
imagine the SLF4J developers would allow it.  I suggest that you come 
up with an implementation of the service API for proposed inclusion 
in SLF4J.  There's no guarantee it would be accepted.  In fact, the 
odds seem against it.  However, I highly doubt the SLF4J developers 
are going to take the time to write it.  So, the only way this has a 
chance of moving forward is for someone to write it and propose it as 
SLF4J's non-JDK-specific Services implementation.  Not just 
pseudo-code, but actual fully implemented working code.

Jake



>--
>
>- Eric
>_______________________________________________
>dev mailing list
>dev at slf4j.org
>http://www.slf4j.org/mailman/listinfo/dev