Nabble - Slf4J

Re: migrating user@slf4j.org

2009-11-26T15:42:26Z

Someone should also migrate http://old.nabble.com/Slf4J-f13198.html

I don't know who has admin access there..

Gili

Holger Hoffstaette wrote:

> On Thu, 26 Nov 2009 17:32:04 +0100, Ceki Gülcü wrote:
>
>> Since it is is somewhat non-trivial to run an SMTP server, especially in
>> case of replicating servers, I would like to shut down the slf4j.org SMTP
>> server and migrate the various mailing lists to qos.ch. As such, the
>> slf4j.org mailing lists, that is dev@... and user@... will be
>> migrated to qos.ch as slf4j-dev@... and respectively as
>> slf4j-user@.... The announce@... mailing list will be merged into
>> announce@....
>>
>> Existing subscriptions will be migrated automatically.
>
> Thanks for the notice, but could you please also notify Gmane
> (www.gmane.org) about the changes? Otherwise the subscriptions for slf4j
> and logback will be zombies. If I remember correctly they have a
> mostly-self-service web form for subscriptions, so it should be quick.
> Would be very much appreciated.
>
> thanks
> Holger
>
>
> _______________________________________________
> slf4j-user mailing list
> slf4j-user@...
> http://qos.ch/mailman/listinfo/slf4j-user

_______________________________________________
slf4j-user mailing list
slf4j-user@...
http://qos.ch/mailman/listinfo/slf4j-user

From forum: Slf4J - user

Re: migrating user@slf4j.org

2009-11-26T15:40:23Z

Hi Ceki,

I suspect Google Apps will host the mail server for you for free. Take
a look.

Gili

Holger Hoffstaette wrote:

_______________________________________________
slf4j-user mailing list
slf4j-user@...
http://qos.ch/mailman/listinfo/slf4j-user

From forum: Slf4J - user

Re: migrating user@slf4j.org

2009-11-26T10:16:50Z

On Thu, 26 Nov 2009 17:32:04 +0100, Ceki Gülcü wrote:

> Since it is is somewhat non-trivial to run an SMTP server, especially in
> case of replicating servers, I would like to shut down the slf4j.org SMTP
> server and migrate the various mailing lists to qos.ch. As such, the
> slf4j.org mailing lists, that is dev@... and user@... will be
> migrated to qos.ch as slf4j-dev@... and respectively as
> slf4j-user@.... The announce@... mailing list will be merged into
> announce@....
>
> Existing subscriptions will be migrated automatically.

Thanks for the notice, but could you please also notify Gmane
(www.gmane.org) about the changes? Otherwise the subscriptions for slf4j
and logback will be zombies. If I remember correctly they have a
mostly-self-service web form for subscriptions, so it should be quick.
Would be very much appreciated.

thanks
Holger

_______________________________________________
slf4j-user mailing list
slf4j-user@...
http://qos.ch/mailman/listinfo/slf4j-user

From forum: Slf4J - user

Re: slf4j-osgi-api module

2009-11-26T09:32:03Z

On Thu, Nov 26, 2009 at 2:25 AM, Ceki Gülcü <ceki@...> wrote:
> Hello Hugues,
>
Hi!

Thanks for your interest in this experiment to get rid of the cyclic
dependency between slf4j-api and a bundle that provides an slf4j
implementation (bug #75).

>
> From what I could gather looking at the slf4j-api-osgi module, it
> looks like the slf4j-api-osgi module is responsible for binding
> slf4j-api with the underlying logging framework using the resolution
> functionality offered by OSGi. Given that slf4j-api-osgi module itself
> exports the org.slf4j.impl package, I was wondering how you were going
> to avoid recursing endlessly into slf4j-api-osgi or mistakenly export
> the org.slf4j.impl package found in slf4j-api-osgi instead of a
> real/desired implementation. slf4j-api-osgi avoids that undesirable
> predicament by exporting the o.s.impl package only if the exporting
> bundle is not itself. It also registers listeners in case the desired
> bundle is installed later on. Nice.

Thanks!

I tested this scenario to make sure the listeners are working as expected:
- start everything with logback-classic
- do some logging: loggers are provided by logback-classic
- stop logback-classic.
- get a new Logger returns the NOP-logger
- start logback-classic again
- getting a new logger return loggers provided by logback classic again.

>
> However, I still don't see what happens if the slf4j-api-osgi is
> exported by another bundle *before* the slf4j-api-osgi bundle is
> installed and before it has a chance to act.

OSGi will only start a bundle once all its dependencies are resolved
as bundles and those are started.
As all bundles that provide o.s.impl import the package o.slf4j; it is
guaranteed that slf4j-api is installed first before them.

slf4j-api-osgi bundle is a fragment hosted by slf4j-api.
When slf4j-api is installed by the OSGi container the slf4j-api-osgi
is "attached" to slf4j-api.
The OSGi spec says that fragments are not started, they are "attached"
to their host bundle.
Hence when slf4j-api is started we also have slf4j-api-osgi acting inside it.
The org.slf4j.impl package provided by slf4j-api-osgi is placed in the
very same classloader than org.slf4j.Logger

So when org.slf4j.LoggerFactory imports
org.slf4j.impl.StaticLoggerBinder it finds the one provided by
slf4j-api-osgi.

There is another way to achieve the exact same situation: place the
classes of slf4j-api-osgi as a jar embedded inside slf4j-api. It is
taken into account only by osgi and it would save us having to carry a
new jar for the OSGi support.

>
> Much more importantly, I am worryingly missing the big picture. Even
> if the org.slf4j.impl is exported according to our wishes, how is the
> org.slf4j package imported and by who? In other words, how does client
> code wishing to use the org.slf4j.Logger class get hold of it and what
> is the relationship between that client code and OSGi?

Client bundles that depend on slf4j state in their manifest:
Import-Package: org.slf4j
The osgi container resolves this into a dependency on slf4j-api and
everything works on the client side.

On the logger implementation side: we need logback-classic or another
bundle that provides o.s.impl to be set to start automatically. slf4j
logs with NOPLogger until logback-classic is started

Let me know if this makes sense,
Cheers,
Hugues

>
> Many thanks in advance for your response,
>
> --
> Ceki
>
> ps. I am CCing dev@... so that others can follow the discussion.
>
_______________________________________________
slf4j-dev mailing list
slf4j-dev@...
http://qos.ch/mailman/listinfo/slf4j-dev

From forum: Slf4J - dev

Re: Static binding...

2009-11-26T08:55:45Z

Hi Joern,

Well, it's more of a java question than slf4j. The difference is between
direct method call and a method call via reflection. The latter is known
to be a bit slower and is also harder to read. There might also be
subtle class loader differences.

Joern Huxhorn wrote:

> I was wondering if there is a real substantial difference between
>
> a) ILoggerFactory
> factory=org.slf4j.impl.StaticLoggerBinder.getLoggerFactory();
>
> and
>
> b) ILoggerFactory factory=(ILoggerFactory)
> Class.forName("org.slf4j.impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null);
>
>
> I mean, are the classes resolved any different?
>
> Beside a compile-time error in case of a) if the class is missing, of
> course.
>
> Regards,
> Joern.

--
Ceki
_______________________________________________
slf4j-dev mailing list
slf4j-dev@...
http://qos.ch/mailman/listinfo/slf4j-dev

From forum: Slf4J - dev

testing, please ignore

2009-11-26T08:49:20Z

testing automatic forwarding to slf4j-dev@...
_______________________________________________
slf4j-dev mailing list
slf4j-dev@...
http://qos.ch/mailman/listinfo/slf4j-dev

From forum: Slf4J - dev

migrating user@slf4j.org

2009-11-26T08:32:04Z

Hello,

Since it is is somewhat non-trivial to run an SMTP server, especially
in case of replicating servers, I would like to shut down the
slf4j.org SMTP server and migrate the various mailing lists to
qos.ch. As such, the slf4j.org mailing lists, that is dev@...
and user@... will be migrated to qos.ch as slf4j-dev@... and
respectively as slf4j-user@.... The announce@... mailing list
will be merged into announce@....

Existing subscriptions will be migrated automatically.

Best regards,

--
Ceki
_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

From forum: Slf4J - user

Static binding...

2009-11-26T08:31:25Z

I was wondering if there is a real substantial difference between

a) ILoggerFactory
factory=org.slf4j.impl.StaticLoggerBinder.getLoggerFactory();

and

b) ILoggerFactory factory=(ILoggerFactory)
Class
.forName
("org
.slf4j
.impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null);

I mean, are the classes resolved any different?

Beside a compile-time error in case of a) if the class is missing, of
course.

Regards,
Joern.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

slf4j-osgi-api module

2009-11-26T02:25:32Z

Hello Hugues,

From what I could gather looking at the slf4j-api-osgi module, it
looks like the slf4j-api-osgi module is responsible for binding
slf4j-api with the underlying logging framework using the resolution
functionality offered by OSGi. Given that slf4j-api-osgi module itself
exports the org.slf4j.impl package, I was wondering how you were going
to avoid recursing endlessly into slf4j-api-osgi or mistakenly export
the org.slf4j.impl package found in slf4j-api-osgi instead of a
real/desired implementation. slf4j-api-osgi avoids that undesirable
predicament by exporting the o.s.impl package only if the exporting
bundle is not itself. It also registers listeners in case the desired
bundle is installed later on. Nice.

However, I still don't see what happens if the slf4j-api-osgi is
exported by another bundle *before* the slf4j-api-osgi bundle is
installed and before it has a chance to act.

Much more importantly, I am worryingly missing the big picture. Even
if the org.slf4j.impl is exported according to our wishes, how is the
org.slf4j package imported and by who? In other words, how does client
code wishing to use the org.slf4j.Logger class get hold of it and what
is the relationship between that client code and OSGi?

Many thanks in advance for your response,

--
Ceki

ps. I am CCing dev@... so that others can follow the discussion.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

Re: Unit testing OSGi bundles

2009-11-25T13:43:09Z

On 25.11.2009, at 22:15, Ceki Gülcü wrote:

> Hello all,
>
> I am wondering if anyone here has knowledge on testing OSGi bundles,
> and in particular, in embedding an OSGi framework within the unit
> test (using helper classes). Has anyone done that?
>

I'd also be interested in something like that.
And I could really use some help OSGifying my Lilith appenders - but I
have no personal experience with OSGi at all, so far.

Joern.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

Unit testing OSGi bundles

2009-11-25T13:15:24Z

Hello all,

I am wondering if anyone here has knowledge on testing OSGi bundles, and
in particular, in embedding an OSGi framework within the unit test
(using helper classes). Has anyone done that?

--
Ceki
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 160] New: slf4j throw NullPointerException in singed applet

2009-11-25T04:59:00Z

http://bugzilla.slf4j.org/show_bug.cgi?id=160

Summary: slf4j throw NullPointerException in singed applet
Product: SLF4J
Version: 1.5.x
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: critical
Priority: P1
Component: Core API
AssignedTo: dev@...
ReportedBy: moonumi@...

package slf4j;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.applet.Applet;

public class sl4jTest extends Applet {
private Logger dev = LoggerFactory.getLogger(sl4jTest.class);
@Override
public void init() {
super.init();
}

@Override
public void start() {
super.start();
}

@Override
public void stop() {
super.stop();
}

@Override
public void destroy() {
super.destroy();
}

public sl4jTest() {
dev.debug("test");
}
}
==========================================================
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head><title>G2B applet test page</title>
<script src="http://www.java.com/js/deployJava.js"></script>
<script language="javascript">
var attributes = {id: "slf",
name: "slf",
codebase:'http://localhost:8080',
code:'slf4j.sl4jTest',
archive:'/slf.jar',
width:1, height:1
} ;
var parameters = {fontSize:16} ;
var version = '1.6' ;
deployJava.runApplet(attributes, parameters, version);
</script>
<script language="javascript">
function openChild() {
var child = window.open('childApplet.jsp', 'childWin')
//parent.setChildWindow(child);
}
</script>

</head>
<body>
</body>
</html>

===============================================

java console windows show NullPointerException when run tomcat and request jsp.

private Logger dev = LoggerFactory.getLogger(sl4jTest.class); <= error

================java applet console ================
basic: 추가된 진행 수신기:
sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@bc6349
cache: Skip blacklist check as cached value is ok.
network: 캐시 항목이 있습니다. [url: http://localhost:8080/slf.jar,
버전: null]
network: http://localhost:8080/slf.jar을(를) proxy=DIRECT과(와) 연결 중
network: http://localhost:8080/을(를) proxy=DIRECT과(와) 연결 중
network: http://localhost:8080/slf.jar을(를)
"JSESSIONID=1082B3D3B082F1DB9CC154B801227A9A" 쿠키와 연결 중
network: http://localhost:8080/slf.jar 응답 코드: 304
network: http://localhost:8080/slf.jar 인코딩: null
network: http://localhost:8080/slf.jar과(와) 연결 끊기
Reading certificates from 2042 http://localhost:8080/slf.jar | C:\Documents and
Settings\Administrator\Application
Data\Sun\Java\Deployment\cache\6.0\12\43fc354c-6ceaa523.idx
security: C:\Java\jre6\lib\security\cacerts에서 루트 CA 인증서를
로드하는 중
security: C:\Java\jre6\lib\security\cacerts에서 루트 CA 인증서를
로드함
security: C:\Documents and Settings\Administrator\Application
Data\Sun\Java\Deployment\security\trusted.certs에서 배포 인증서를
로드하는 중
security: C:\Documents and Settings\Administrator\Application
Data\Sun\Java\Deployment\security\trusted.certs에서 배포 인증서를
로드함
security: 배포 세션 인증서 저장소에서 인증서를 로드하는 중
security: 배포 세션 인증서 저장소에서 인증서를 로드함
security: Internet Explorer ROOT 인증서 저장소에서 인증서를
로드하는 중
security: Internet Explorer ROOT 인증서 저장소에서 인증서를
로드함
security: Internet Explorer TrustedPublisher 인증서 저장소에서
인증서를 로드하는 중
security: Internet Explorer TrustedPublisher 인증서 저장소에서
인증서를 로드함
security: CertPath API를 사용하여 인증서 체인 검증
security: 루트 CA 인증 저장소에서 인증서 모음 얻기
security: 루트 CA 인증 저장소에서 인증서 모음 얻기
security: 사용 가능한 타임스탬프 정보가 없습니다.
security: jurisdiction 목록 파일을 찾았습니다.
security: 이 인증서에 대해 신뢰할 수 있는 확장자를 확인할
필요가 없습니다.
security: CRL 지원을 사용할 수 없습니다.
security: OCSP 지원을 사용할 수 없습니다.
security: 배포 거부 인증 저장소에 인증서가 있는지 확인하기
security: 배포 영구 인증서 저장소에 인증서가 있는지
확인하는 중
basic: 예외 오류: null.
java.lang.NullPointerException
at sun.plugin2.applet.Plugin2Manager.findAppletJDKLevel(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at
sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
예외: java.lang.NullPointerException
Ignored exception: java.lang.NullPointerException

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

Re: Feature Request

2009-11-24T05:15:26Z

RE: [slf4j-dev] Feature Request

Hey Guys,

I thought I could just write a little implementation. Basically it is your LocLogger, with a few lines changed.

package org.slf4j.cal10n;

import org.slf4j.Logger;

import org.slf4j.Marker;

import org.slf4j.MarkerFactory;

import org.slf4j.ext.LoggerWrapper;

import org.slf4j.spi.LocationAwareLogger;

import ch.qos.cal10n.IMessageConveyor;

import ch.qos.cal10n.MessageParameterObj;

/**

* A logger specialized in localized logging. Localization is based in the <a

* href="http://cal10n.qos.ch">CAL10N project</p>.

* @author Ceki Gülcü

public class CodeLocLogger extends LoggerWrapper implements Logger {

private static final String FQCN = CodeLocLogger.class.getName();

/**

* Every localized message logged by a LocLogger will bear this marker. It

* allows marker-aware implementations to perform additional processing on

* localized messages.

static Marker LOCALIZED = MarkerFactory.getMarker("LOCALIZED");

final IMessageConveyor imc;

public CodeLocLogger(Logger logger, IMessageConveyor imc) {

super(logger, LoggerWrapper.class.getName());

if(imc == null) {

throw new IllegalArgumentException("IMessageConveyor cannot be null");

}

this.imc = imc;

}

/**

* Log a localized message at the TRACE level.

* @param key

* the key used for localization

* @param args

* optional arguments

public void trace(Enum<?> key, Object... args) {

if (!logger.isTraceEnabled()) {

return;

}

String translatedMsg = imc.getMessage(key, args);

MessageParameterObj mpo = new MessageParameterObj(key, args);

String msg = " [" + key.getClass().getName() + key.toString() + "] " + translatedMsg;

if (instanceofLAL) {

((LocationAwareLogger) logger).log(LOCALIZED, FQCN,

LocationAwareLogger.TRACE_INT, msg, null);

} else {

logger.trace(LOCALIZED, msg, mpo);

}

/**

* Log a localized message at the DEBUG level.

* @param key

* the key used for localization

* @param args

* optional arguments

public void debug(Enum<?> key, Object... args) {

if (!logger.isDebugEnabled()) {

return;

}

String translatedMsg = imc.getMessage(key, args);

MessageParameterObj mpo = new MessageParameterObj(key, args);

String msg = " [" + key.getClass().getName() + key.toString() + "] " + translatedMsg;

if (instanceofLAL) {

((LocationAwareLogger) logger).log(LOCALIZED, FQCN,

LocationAwareLogger.DEBUG_INT, msg, null);

} else {

logger.debug(LOCALIZED, msg, mpo);

}

/**

* Log a localized message at the INFO level.

* @param key

* the key used for localization

* @param args

* optional arguments

public void info(Enum<?> key, Object... args) {

if (!logger.isInfoEnabled()) {

return;

}

String translatedMsg = imc.getMessage(key, args);

MessageParameterObj mpo = new MessageParameterObj(key, args);

String msg = " [" + key.getClass().getName() + key.toString() + "] " + translatedMsg;

if (instanceofLAL) {

((LocationAwareLogger) logger).log(LOCALIZED, FQCN,

LocationAwareLogger.INFO_INT, msg, null);

} else {

logger.info(LOCALIZED, msg, mpo);

}

/**

* Log a localized message at the WARN level.

* @param key

* the key used for localization

* @param args

* optional arguments

public void warn(Enum<?> key, Object... args) {

if (!logger.isWarnEnabled()) {

return;

}

String translatedMsg = imc.getMessage(key, args);

MessageParameterObj mpo = new MessageParameterObj(key, args);

String msg = " [" + key.getClass().getName() + key.toString() + "] " + translatedMsg;

if (instanceofLAL) {

((LocationAwareLogger) logger).log(LOCALIZED, FQCN,

LocationAwareLogger.WARN_INT, msg, null);

} else {

logger.warn(LOCALIZED, msg, mpo);

}

/**

* Log a localized message at the ERROR level.

* @param key

* the key used for localization

* @param args

* optional arguments

public void error(Enum<?> key, Object... args) {

if (!logger.isErrorEnabled()) {

return;

}

String translatedMsg = imc.getMessage(key, args);

MessageParameterObj mpo = new MessageParameterObj(key, args);

String msg = " [" + key.getClass().getName() + key.toString() + "] " + translatedMsg;

if (instanceofLAL) {

((LocationAwareLogger) logger).log(LOCALIZED, FQCN,

LocationAwareLogger.ERROR_INT, msg, null);

} else {

logger.error(LOCALIZED, msg, mpo);

}

_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

Feature Request

2009-11-24T04:49:44Z

Feature Request

Hey slf4j guys,

I have a feature Request regarding Localized Logging.

Since a localized Message is localized ;-) it is hard to google it. I have had that issue with some java programs already. Because there is no way I could know the english message, when the program runs in german.

Therefore I would appreciate a standardized API that allows to have a common part (like an error code) and a localized part on any localized message. For example

#The properties file

APPLICATION_STARTED=Application {0} has started.

//EITHER like this (which does not actually feel that good): enum Production
{
    APPLICATION_STARTED("MyApp001");
    public String CODE;
    private Production(String CODE)
    {
        this.CODE = CODE;
    }
}
 //used like this
locLogger.info(Production.APPLICATION_STARTED, Production.APPLICATION_STARTED.CODE, "fooApp");
//output: [MyApp001] Application fooApp has started.


//--------------------------------------------------------------
//OR maybe another way
locLogger.info("fooApp". Production.APPLICATION_STARTED);
//output: [Production.APPLICATION_STARTED] Application fooApp has started.


I hope I can at least open a discussion.

Thanks a lot for reading.

Michael

_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

branch, master, updated. v1.5.9.RC1-6-gbd6f4a9

2009-11-23T16:06:52Z

The branch, master has been updated
via bd6f4a930aa5fed314d3fc54f39a283103551b6d (commit)
from e5bbca3f28f08327497f591c72b5aac429e15f65 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=bd6f4a930aa5fed314d3fc54f39a283103551b6d
http://github.com/ceki/slf4j/commit/bd6f4a930aa5fed314d3fc54f39a283103551b6d

commit bd6f4a930aa5fed314d3fc54f39a283103551b6d
Author: Ceki Gulcu <ceki@...>
Date: Tue Nov 24 01:06:27 2009 +0100

-updates news.html

diff --git a/slf4j-site/src/site/pages/news.html b/slf4j-site/src/site/pages/news.html
index 076af3a..d3657d0 100644
--- a/slf4j-site/src/site/pages/news.html
+++ b/slf4j-site/src/site/pages/news.html
@@ -71,6 +71,12 @@
href="http://bugzilla.slf4j.org/show_bug.cgi?id=117">bug 117</a>.
</p>

+ <p>OSGi manifests produced by SLF4J now replace the '-' character by
+ '.' in compliance with the OSGi specification. This fixes <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=152">bug 152</a>
+ according to the patch supplied by Hugues Malphettes.
+ </p>
+
<p>Fixed packaging issue in jcl104-over-slf4j which inadvertently
produced a jar file as described in <a
href="http://bugzilla.slf4j.org/show_bug.cgi?id=151">bug 151</a> by

-----------------------------------------------------------------------

Summary of changes:
slf4j-site/src/site/pages/news.html | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)

hooks/post-receive
--
SLF4J: Simple Logging Facade for Java
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 152] Bundle manifest headers have invalid version specifications in SLF4J version 1 .5.9-RC0

2009-11-23T15:43:01Z

http://bugzilla.slf4j.org/show_bug.cgi?id=152

Ceki Gulcu <listid@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #6 from Ceki Gulcu <listid@...> 2009-11-24 00:43:32 ---
Applied patch 65. See
http://github.com/ceki/slf4j/commit/e5bbca3f28f08327497f591c72b5aac429e15f65

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

branch, master, updated. v1.5.9.RC1-5-ge5bbca3

2009-11-23T15:40:24Z

The branch, master has been updated
via e5bbca3f28f08327497f591c72b5aac429e15f65 (commit)
from 83b7bf33691bcff75575f9e9ea94e586f3e58469 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=e5bbca3f28f08327497f591c72b5aac429e15f65
http://github.com/ceki/slf4j/commit/e5bbca3f28f08327497f591c72b5aac429e15f65

commit e5bbca3f28f08327497f591c72b5aac429e15f65
Author: Ceki Gulcu <ceki@...>
Date: Tue Nov 24 00:21:59 2009 +0100

Applied Hugues Malphettes's patch #65 as given in [1]

[1] http://bugzilla.slf4j.org/show_bug.cgi?id=152

diff --git a/jcl-over-slf4j/pom.xml b/jcl-over-slf4j/pom.xml
index 100fae0..bee0bd5 100644
--- a/jcl-over-slf4j/pom.xml
+++ b/jcl-over-slf4j/pom.xml
@@ -49,7 +49,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/jcl-over-slf4j/src/main/resources/META-INF/MANIFEST.MF b/jcl-over-slf4j/src/main/resources/META-INF/MANIFEST.MF
index 3a39037..390f3c1 100644
--- a/jcl-over-slf4j/src/main/resources/META-INF/MANIFEST.MF
+++ b/jcl-over-slf4j/src/main/resources/META-INF/MANIFEST.MF
@@ -6,4 +6,4 @@ Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.3
Export-Package: org.apache.commons.logging;version=1.1.1,
org.apache.commons.logging.impl;version=1.1.1
-Import-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}
+Import-Package: org.slf4j;version=${parsedVersion.osgiVersion}, org.slf4j.spi;version=${parsedVersion.osgiVersion}
diff --git a/log4j-over-slf4j/pom.xml b/log4j-over-slf4j/pom.xml
index b340f98..4f4c621 100644
--- a/log4j-over-slf4j/pom.xml
+++ b/log4j-over-slf4j/pom.xml
@@ -54,7 +54,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/pom.xml b/pom.xml
index a81545d..ad9ef2f 100644
--- a/pom.xml
+++ b/pom.xml
@@ -176,6 +176,21 @@
</configuration>
</plugin>

+
+ 
+ <plugin>
+ <groupId>org.codehaus.mojo</groupId>
+ <artifactId>build-helper-maven-plugin</artifactId>
+ <version>1.3</version>
+ <executions>
+ <execution>
+ <id>parse-version</id>
+ <goals>
+ <goal>parse-version</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
</plugins>

</build>
diff --git a/slf4j-api/pom.xml b/slf4j-api/pom.xml
index e2f5002..42e3133 100644
--- a/slf4j-api/pom.xml
+++ b/slf4j-api/pom.xml
@@ -44,7 +44,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/slf4j-api/src/main/resources/META-INF/MANIFEST.MF b/slf4j-api/src/main/resources/META-INF/MANIFEST.MF
index 9cb6230..732e527 100644
--- a/slf4j-api/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-api/src/main/resources/META-INF/MANIFEST.MF
@@ -4,5 +4,5 @@ Bundle-SymbolicName: slf4j.api
Bundle-Name: slf4j-api
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.3
-Export-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}
+Export-Package: org.slf4j;version=${parsedVersion.osgiVersion}, org.slf4j.spi;version=${parsedVersion.osgiVersion}, org.slf4j.helpers;version=${parsedVersion.osgiVersion}
Import-Package: org.slf4j.impl;version=${slf4j.api.minimum.compatible.version}
diff --git a/slf4j-ext/pom.xml b/slf4j-ext/pom.xml
index 1867652..1aec725 100644
--- a/slf4j-ext/pom.xml
+++ b/slf4j-ext/pom.xml
@@ -81,7 +81,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
<Premain-Class>org.slf4j.agent.AgentPremain</Premain-Class>
diff --git a/slf4j-ext/src/main/resources/META-INF/MANIFEST.MF b/slf4j-ext/src/main/resources/META-INF/MANIFEST.MF
index 2235ed7..f90c7af 100644
--- a/slf4j-ext/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-ext/src/main/resources/META-INF/MANIFEST.MF
@@ -4,5 +4,5 @@ Bundle-SymbolicName: slf4j.ext
Bundle-Name: slf4j-log4j12
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.5
-Export-Package: org.slf4j.profiler;version=${project.version}, org.slf4j.cal10n;version=${project.version}, org.slf4j.ext;version=${project.version}
-Import-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}, ch.qos.cal10n;version=${cal10n.version}
+Export-Package: org.slf4j.profiler;version=${parsedVersion.osgiVersion}, org.slf4j.cal10n;version=${parsedVersion.osgiVersion}, org.slf4j.ext;version=${parsedVersion.osgiVersion}
+Import-Package: org.slf4j;version=${parsedVersion.osgiVersion}, org.slf4j.spi;version=${parsedVersion.osgiVersion}, org.slf4j.helpers;version=${parsedVersion.osgiVersion}, ch.qos.cal10n;version=${cal10n.version}
diff --git a/slf4j-jcl/pom.xml b/slf4j-jcl/pom.xml
index 6859807..49cdfd4 100644
--- a/slf4j-jcl/pom.xml
+++ b/slf4j-jcl/pom.xml
@@ -41,7 +41,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/slf4j-jcl/src/main/resources/META-INF/MANIFEST.MF b/slf4j-jcl/src/main/resources/META-INF/MANIFEST.MF
index fa43185..a905c8f 100644
--- a/slf4j-jcl/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-jcl/src/main/resources/META-INF/MANIFEST.MF
@@ -5,6 +5,6 @@ Bundle-Name: slf4j-jcl
Bundle-Vendor: SLF4J.ORG
Require-Bundle: slf4j.api
Bundle-RequiredExecutionEnvironment: J2SE-1.3
-Export-Package: org.slf4j.impl;version=${project.version}
-Import-Package: org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}, org.apache.commons.logging
+Export-Package: org.slf4j.impl;version=${parsedVersion.osgiVersion}
+Import-Package: org.slf4j.spi;version=${parsedVersion.osgiVersion}, org.slf4j.helpers;version=${parsedVersion.osgiVersion}, org.apache.commons.logging
Fragment-Host: slf4j.api
\ No newline at end of file
diff --git a/slf4j-jdk14/pom.xml b/slf4j-jdk14/pom.xml
index ab33b77..ab08cac 100644
--- a/slf4j-jdk14/pom.xml
+++ b/slf4j-jdk14/pom.xml
@@ -55,7 +55,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/slf4j-jdk14/src/main/resources/META-INF/MANIFEST.MF b/slf4j-jdk14/src/main/resources/META-INF/MANIFEST.MF
index 5bb3ad9..4838f9d 100644
--- a/slf4j-jdk14/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-jdk14/src/main/resources/META-INF/MANIFEST.MF
@@ -4,6 +4,6 @@ Bundle-SymbolicName: slf4j.jdk14
Bundle-Name: slf4j-jdk14
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.3
-Export-Package: org.slf4j.impl;version=${project.version}
-Import-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}
+Export-Package: org.slf4j.impl;version=${parsedVersion.osgiVersion}
+Import-Package: org.slf4j;version=${parsedVersion.osgiVersion}, org.slf4j.spi;version=${parsedVersion.osgiVersion}, org.slf4j.helpers;version=${parsedVersion.osgiVersion}
Fragment-Host: slf4j.api
\ No newline at end of file
diff --git a/slf4j-log4j12/pom.xml b/slf4j-log4j12/pom.xml
index 2082425..6719753 100644
--- a/slf4j-log4j12/pom.xml
+++ b/slf4j-log4j12/pom.xml
@@ -42,7 +42,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/slf4j-log4j12/src/main/resources/META-INF/MANIFEST.MF b/slf4j-log4j12/src/main/resources/META-INF/MANIFEST.MF
index 1de0956..d925dcc 100644
--- a/slf4j-log4j12/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-log4j12/src/main/resources/META-INF/MANIFEST.MF
@@ -4,6 +4,6 @@ Bundle-SymbolicName: slf4j.log4j12
Bundle-Name: slf4j-log4j12
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.3
-Export-Package: org.slf4j.impl;version=${project.version}
-Import-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}, org.apache.log4j
+Export-Package: org.slf4j.impl;version=${parsedVersion.osgiVersion}
+Import-Package: org.slf4j;version=${parsedVersion.osgiVersion}, org.slf4j.spi;version=${parsedVersion.osgiVersion}, org.slf4j.helpers;version=${parsedVersion.osgiVersion}, org.apache.log4j
Fragment-Host: slf4j.api
\ No newline at end of file
diff --git a/slf4j-nop/pom.xml b/slf4j-nop/pom.xml
index 1175b87..10b80cb 100644
--- a/slf4j-nop/pom.xml
+++ b/slf4j-nop/pom.xml
@@ -37,7 +37,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/slf4j-nop/src/main/resources/META-INF/MANIFEST.MF b/slf4j-nop/src/main/resources/META-INF/MANIFEST.MF
index 970f28e..3623e74 100644
--- a/slf4j-nop/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-nop/src/main/resources/META-INF/MANIFEST.MF
@@ -4,6 +4,6 @@ Bundle-SymbolicName: slf4j.nop
Bundle-Name: slf4j-nop
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.3
-Export-Package: org.slf4j.impl;version=${project.version}
-Import-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}
+Export-Package: org.slf4j.impl;version=${parsedVersion.osgiVersion}
+Import-Package: org.slf4j;version=${parsedVersion.osgiVersion}, org.slf4j.spi;version=${parsedVersion.osgiVersion}, org.slf4j.helpers;version=${parsedVersion.osgiVersion}
Fragment-Host: slf4j.api
\ No newline at end of file
diff --git a/slf4j-simple/pom.xml b/slf4j-simple/pom.xml
index 0ecee77..8fb801a 100644
--- a/slf4j-simple/pom.xml
+++ b/slf4j-simple/pom.xml
@@ -32,7 +32,7 @@
<configuration>
<archive>
<manifestEntries>
- <Bundle-Version>${project.version}</Bundle-Version>
+ <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Bundle-Description>${project.description}</Bundle-Description>
<Implementation-Version>${project.version}</Implementation-Version>
</manifestEntries>
diff --git a/slf4j-simple/src/main/resources/META-INF/MANIFEST.MF b/slf4j-simple/src/main/resources/META-INF/MANIFEST.MF
index 84ebee0..b2aa0c0 100644
--- a/slf4j-simple/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-simple/src/main/resources/META-INF/MANIFEST.MF
@@ -5,6 +5,6 @@ Bundle-Name: slf4j-simple
Bundle-Vendor: SLF4J.ORG
Require-Bundle: slf4j.api
Bundle-RequiredExecutionEnvironment: J2SE-1.3
-Export-Package: org.slf4j.impl;version=${project.version}
-Import-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}
+Export-Package: org.slf4j.impl;version=${parsedVersion.osgiVersion}
+Import-Package: org.slf4j;version=${parsedVersion.osgiVersion}, org.slf4j.spi;version=${parsedVersion.osgiVersion}, org.slf4j.helpers;version=${parsedVersion.osgiVersion}
Fragment-Host: slf4j.api
\ No newline at end of file

-----------------------------------------------------------------------

Summary of changes:
jcl-over-slf4j/pom.xml | 2 +-
.../src/main/resources/META-INF/MANIFEST.MF | 2 +-
log4j-over-slf4j/pom.xml | 2 +-
pom.xml | 15 +++++++++++++++
slf4j-api/pom.xml | 2 +-
slf4j-api/src/main/resources/META-INF/MANIFEST.MF | 2 +-
slf4j-ext/pom.xml | 2 +-
slf4j-ext/src/main/resources/META-INF/MANIFEST.MF | 4 ++--
slf4j-jcl/pom.xml | 2 +-
slf4j-jcl/src/main/resources/META-INF/MANIFEST.MF | 4 ++--
slf4j-jdk14/pom.xml | 2 +-
.../src/main/resources/META-INF/MANIFEST.MF | 4 ++--
slf4j-log4j12/pom.xml | 2 +-
.../src/main/resources/META-INF/MANIFEST.MF | 4 ++--
slf4j-nop/pom.xml | 2 +-
slf4j-nop/src/main/resources/META-INF/MANIFEST.MF | 4 ++--
slf4j-simple/pom.xml | 2 +-
.../src/main/resources/META-INF/MANIFEST.MF | 4 ++--
18 files changed, 38 insertions(+), 23 deletions(-)

hooks/post-receive
--
SLF4J: Simple Logging Facade for Java
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 31] Varargs for Logger methods

2009-11-23T10:58:15Z

http://bugzilla.slf4j.org/show_bug.cgi?id=31

--- Comment #68 from Joern Huxhorn <joern@...> 2009-11-23 19:59:25 ---
(In reply to comment #65)

> Janos (boci.boci@...),
>
> Even if everyone on the planet was using JDK 1.7, SLF4J would still need to
> ensure binary compatibility with previous versions.
>
> If in project P you have dependency D1 using slf4j 1.5 and dependency D2 using
> the newest coolest versions of slf4j, say 1.6, then for D1 and D2 to cohabit,
> slf4j versions 1.5 and 1.6 need to be binary compatible. It has little to do
> with the JDK version actually. Before writing that you disagree, read this over
> until you change your mind.

Well, the new version of SLF4J with varargs would be binary compatible with the
old one - but only if the used JDK would be >= 1.5. Below that startup would
fail because the new SLF4J would use a class file version that would not be
understood by JVM < 1.5.

This could be a problem for projects that want to stay compatible with 1.4.

I'm not 100% sure what will create a bigger outcry, especially since I don't
know if the resulting error message would be clear enough for the name-calling
users with ropes mentioned in comment #54.

If we'd keep SLF4J as it is, moving it into maintenance mode, and defined new
LoggerFactory/Logger in a different package then we'd make sure that no one in
that part of the community (depending on <= 1.4) would run into any problems.

AFAIK, the only SLF4J binding that requires JDK 1.5 is Logback.
Log4J 1.2 will stay 1.4 compatible, 1.3 has been abandoned and 2.0 is supposed
to be 1.5 only but is only vaporware at the moment, I think.

commons-logging is still supporting Java 1.2 (even Java 1.1 to some degree) - I
think for the exact same reason, fear of users...

I've just taken a glance at some of the projects using SLF4J:
http://mvnrepository.com/artifact/org.slf4j/slf4j-api/1.5.6
and there are projects that still explicitly support 1.4, e.g. jGuard.

Leaving SLF4J as it is would prevent any name-calling while bumping the
requirement to 1.5 might just spark it.

I'm not saying "Don't do it!", I'm merely asking "Are you really sure?"...

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

branch, master, updated. v1.5.9.RC1-4-g83b7bf3

2009-11-23T08:36:29Z

The branch, master has been updated
via 83b7bf33691bcff75575f9e9ea94e586f3e58469 (commit)
from f67363eb62173c7c6a42d79020d22b8d17f3805a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=83b7bf33691bcff75575f9e9ea94e586f3e58469
http://github.com/ceki/slf4j/commit/83b7bf33691bcff75575f9e9ea94e586f3e58469

commit 83b7bf33691bcff75575f9e9ea94e586f3e58469
Author: Ceki Gulcu <ceki@...>
Date: Mon Nov 23 17:36:15 2009 +0100

upped version to 1.5.10-SNAPSHOT

diff --git a/integration/pom.xml b/integration/pom.xml
index 59bf402..092b264 100644
--- a/integration/pom.xml
+++ b/integration/pom.xml
@@ -6,7 +6,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/jcl-over-slf4j/pom.xml b/jcl-over-slf4j/pom.xml
index a793148..100fae0 100644
--- a/jcl-over-slf4j/pom.xml
+++ b/jcl-over-slf4j/pom.xml
@@ -3,7 +3,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/jcl104-over-slf4j/pom.xml b/jcl104-over-slf4j/pom.xml
index 0523e5a..7076ce0 100644
--- a/jcl104-over-slf4j/pom.xml
+++ b/jcl104-over-slf4j/pom.xml
@@ -3,7 +3,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/jul-to-slf4j/pom.xml b/jul-to-slf4j/pom.xml
index e64564a..04e4d5c 100644
--- a/jul-to-slf4j/pom.xml
+++ b/jul-to-slf4j/pom.xml
@@ -6,7 +6,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/log4j-over-slf4j/pom.xml b/log4j-over-slf4j/pom.xml
index c89cdc1..b340f98 100644
--- a/log4j-over-slf4j/pom.xml
+++ b/log4j-over-slf4j/pom.xml
@@ -5,7 +5,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/osgi-over-slf4j/pom.xml b/osgi-over-slf4j/pom.xml
index 9f241f4..901e2b9 100644
--- a/osgi-over-slf4j/pom.xml
+++ b/osgi-over-slf4j/pom.xml
@@ -3,7 +3,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/pom.xml b/pom.xml
index 71e8ce4..a81545d 100644
--- a/pom.xml
+++ b/pom.xml
@@ -5,7 +5,7 @@

<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>

<packaging>pom</packaging>
<name>SLF4J</name>
diff --git a/slf4j-api/pom.xml b/slf4j-api/pom.xml
index b96f4bf..e2f5002 100644
--- a/slf4j-api/pom.xml
+++ b/slf4j-api/pom.xml
@@ -5,7 +5,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-api/src/main/java/org/slf4j/impl/StaticLoggerBinder.java b/slf4j-api/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
index bddc36a..23e0444 100644
--- a/slf4j-api/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
+++ b/slf4j-api/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
@@ -61,7 +61,7 @@ public class StaticLoggerBinder {
* The value of this field is usually modified with each release.
*/
// to avoid constant folding by the compiler, this field must *not* be final
- public static String REQUESTED_API_VERSION = "1.5.9.RC1"; // !final
+ public static String REQUESTED_API_VERSION = "1.5.10"; // !final

private StaticLoggerBinder() {
throw new UnsupportedOperationException("This code should have never made it into the jar");
diff --git a/slf4j-ext/pom.xml b/slf4j-ext/pom.xml
index 2dc65fb..1867652 100644
--- a/slf4j-ext/pom.xml
+++ b/slf4j-ext/pom.xml
@@ -5,7 +5,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-jcl/pom.xml b/slf4j-jcl/pom.xml
index a52fe22..6859807 100644
--- a/slf4j-jcl/pom.xml
+++ b/slf4j-jcl/pom.xml
@@ -3,7 +3,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-jcl/src/main/java/org/slf4j/impl/StaticLoggerBinder.java b/slf4j-jcl/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
index 794bc9e..6c63536 100644
--- a/slf4j-jcl/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
+++ b/slf4j-jcl/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
@@ -65,7 +65,7 @@ public class StaticLoggerBinder implements LoggerFactoryBinder {
*/

//to avoid constant folding by the compiler, this field must *not* be final
- public static String REQUESTED_API_VERSION = "1.5.9.RC1";
+ public static String REQUESTED_API_VERSION = "1.5.10";

// Binding specific code:
private static final String loggerFactoryClassStr = JCLLoggerFactory.class
diff --git a/slf4j-jdk14/pom.xml b/slf4j-jdk14/pom.xml
index 3a2fd27..ab33b77 100644
--- a/slf4j-jdk14/pom.xml
+++ b/slf4j-jdk14/pom.xml
@@ -6,7 +6,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-jdk14/src/main/java/org/slf4j/impl/StaticLoggerBinder.java b/slf4j-jdk14/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
index 5c423b9..b32a59d 100644
--- a/slf4j-jdk14/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
+++ b/slf4j-jdk14/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
@@ -66,7 +66,7 @@ public class StaticLoggerBinder implements LoggerFactoryBinder {
* The value of this field is usually modified with each release.
*/
// to avoid constant folding by the compiler, this field must *not* be final
- public static String REQUESTED_API_VERSION = "1.5.9.RC1"; // !final
+ public static String REQUESTED_API_VERSION = "1.5.10"; // !final

private static final String loggerFactoryClassStr = org.slf4j.impl.JDK14LoggerFactory.class.getName();
diff --git a/slf4j-log4j12/pom.xml b/slf4j-log4j12/pom.xml
index d0ae4bc..2082425 100644
--- a/slf4j-log4j12/pom.xml
+++ b/slf4j-log4j12/pom.xml
@@ -6,7 +6,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-log4j12/src/main/java/org/slf4j/impl/StaticLoggerBinder.java b/slf4j-log4j12/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
index e2e7461..03543ca 100644
--- a/slf4j-log4j12/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
+++ b/slf4j-log4j12/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
@@ -66,7 +66,7 @@ public class StaticLoggerBinder implements LoggerFactoryBinder {
* against. The value of this field is usually modified with each release.
*/
// to avoid constant folding by the compiler, this field must *not* be final
- public static String REQUESTED_API_VERSION = "1.5.9.RC1"; // !final
+ public static String REQUESTED_API_VERSION = "1.5.10"; // !final

private static final String loggerFactoryClassStr = Log4jLoggerFactory.class
.getName();
diff --git a/slf4j-migrator/pom.xml b/slf4j-migrator/pom.xml
index c2b65b3..8b5595a 100644
--- a/slf4j-migrator/pom.xml
+++ b/slf4j-migrator/pom.xml
@@ -7,7 +7,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-nop/pom.xml b/slf4j-nop/pom.xml
index 4d002f5..1175b87 100644
--- a/slf4j-nop/pom.xml
+++ b/slf4j-nop/pom.xml
@@ -6,7 +6,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-nop/src/main/java/org/slf4j/impl/StaticLoggerBinder.java b/slf4j-nop/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
index 1e622ee..3295871 100644
--- a/slf4j-nop/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
+++ b/slf4j-nop/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
@@ -66,7 +66,7 @@ public class StaticLoggerBinder implements LoggerFactoryBinder {
* The value of this field is usually modified with each release.
*/
// to avoid constant folding by the compiler, this field must *not* be final
- public static String REQUESTED_API_VERSION = "1.5.9.RC1"; // !final
+ public static String REQUESTED_API_VERSION = "1.5.10"; // !final

private static final String loggerFactoryClassStr = NOPLoggerFactory.class.getName();

diff --git a/slf4j-osgi-integration-test/pom.xml b/slf4j-osgi-integration-test/pom.xml
index 147a1bb..4cd8468 100644
--- a/slf4j-osgi-integration-test/pom.xml
+++ b/slf4j-osgi-integration-test/pom.xml
@@ -6,7 +6,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-osgi-test-bundle/pom.xml b/slf4j-osgi-test-bundle/pom.xml
index ce8cab8..0955253 100644
--- a/slf4j-osgi-test-bundle/pom.xml
+++ b/slf4j-osgi-test-bundle/pom.xml
@@ -6,7 +6,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-simple/pom.xml b/slf4j-simple/pom.xml
index 849e6cf..0ecee77 100644
--- a/slf4j-simple/pom.xml
+++ b/slf4j-simple/pom.xml
@@ -3,7 +3,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>
diff --git a/slf4j-simple/src/main/java/org/slf4j/impl/StaticLoggerBinder.java b/slf4j-simple/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
index 51c6901..87914be 100644
--- a/slf4j-simple/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
+++ b/slf4j-simple/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
@@ -58,7 +58,7 @@ public class StaticLoggerBinder implements LoggerFactoryBinder {
* against. The value of this field is usually modified with each release.
*/
// to avoid constant folding by the compiler, this field must *not* be final
- public static String REQUESTED_API_VERSION = "1.5.9.RC1"; // !final
+ public static String REQUESTED_API_VERSION = "1.5.10"; // !final

private static final String loggerFactoryClassStr = SimpleLoggerFactory.class.getName();

diff --git a/slf4j-site/pom.xml b/slf4j-site/pom.xml
index 6cb0e64..852d41a 100644
--- a/slf4j-site/pom.xml
+++ b/slf4j-site/pom.xml
@@ -5,7 +5,7 @@
<parent>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-parent</artifactId>
- <version>1.5.9.RC1</version>
+ <version>1.5.10-SNAPSHOT</version>
</parent>

<modelVersion>4.0.0</modelVersion>

-----------------------------------------------------------------------

Summary of changes:
integration/pom.xml | 2 +-
jcl-over-slf4j/pom.xml | 2 +-
jcl104-over-slf4j/pom.xml | 2 +-
jul-to-slf4j/pom.xml | 2 +-
log4j-over-slf4j/pom.xml | 2 +-
osgi-over-slf4j/pom.xml | 2 +-
pom.xml | 2 +-
slf4j-api/pom.xml | 2 +-
.../java/org/slf4j/impl/StaticLoggerBinder.java | 2 +-
slf4j-ext/pom.xml | 2 +-
slf4j-jcl/pom.xml | 2 +-
.../java/org/slf4j/impl/StaticLoggerBinder.java | 2 +-
slf4j-jdk14/pom.xml | 2 +-
.../java/org/slf4j/impl/StaticLoggerBinder.java | 2 +-
slf4j-log4j12/pom.xml | 2 +-
.../java/org/slf4j/impl/StaticLoggerBinder.java | 2 +-
slf4j-migrator/pom.xml | 2 +-
slf4j-nop/pom.xml | 2 +-
.../java/org/slf4j/impl/StaticLoggerBinder.java | 2 +-
slf4j-osgi-integration-test/pom.xml | 2 +-
slf4j-osgi-test-bundle/pom.xml | 2 +-
slf4j-simple/pom.xml | 2 +-
.../java/org/slf4j/impl/StaticLoggerBinder.java | 2 +-
slf4j-site/pom.xml | 2 +-
24 files changed, 24 insertions(+), 24 deletions(-)

hooks/post-receive
--
SLF4J: Simple Logging Facade for Java
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

branch, master, updated. v1.5.9.RC1-3-gf67363e

2009-11-23T08:31:19Z

The branch, master has been updated
via f67363eb62173c7c6a42d79020d22b8d17f3805a (commit)
from 8c91c8ff649bc3222753049d487b276a240ec182 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=f67363eb62173c7c6a42d79020d22b8d17f3805a
http://github.com/ceki/slf4j/commit/f67363eb62173c7c6a42d79020d22b8d17f3805a

commit f67363eb62173c7c6a42d79020d22b8d17f3805a
Author: Ceki Gulcu <ceki@...>
Date: Mon Nov 23 17:29:50 2009 +0100

Applied Hugues Malphettes patch #66 [1] as attached to bug 75 [2]

[1] http://bugzilla.slf4j.org/attachment.cgi?id=66
[2] http://bugzilla.slf4j.org/show_bug.cgi?id=75

diff --git a/pom.xml b/pom.xml
index 9d2650a..71e8ce4 100644
--- a/pom.xml
+++ b/pom.xml
@@ -27,6 +27,7 @@
</licenses>

<properties>
+ <slf4j.api.minimum.compatible.version>1.5.5</slf4j.api.minimum.compatible.version>
<cal10n.version>0.7.2</cal10n.version>
</properties>

diff --git a/slf4j-api/src/main/resources/META-INF/MANIFEST.MF b/slf4j-api/src/main/resources/META-INF/MANIFEST.MF
index 8c6fdd1..9cb6230 100644
--- a/slf4j-api/src/main/resources/META-INF/MANIFEST.MF
+++ b/slf4j-api/src/main/resources/META-INF/MANIFEST.MF
@@ -5,4 +5,4 @@ Bundle-Name: slf4j-api
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.3
Export-Package: org.slf4j;version=${project.version}, org.slf4j.spi;version=${project.version}, org.slf4j.helpers;version=${project.version}
-Import-Package: org.slf4j.impl;version=${project.version}
+Import-Package: org.slf4j.impl;version=${slf4j.api.minimum.compatible.version}

-----------------------------------------------------------------------

Summary of changes:
pom.xml | 1 +
slf4j-api/src/main/resources/META-INF/MANIFEST.MF | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)

hooks/post-receive
--
SLF4J: Simple Logging Facade for Java
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 159] Default to a behavior when no adapter found in the classpath

2009-11-21T15:08:11Z

http://bugzilla.slf4j.org/show_bug.cgi?id=159

--- Comment #1 from Ceki Gulcu <listid@...> 2009-11-22 00:09:26 ---
I started working this issue. Unfortunately, the required changes are more
extensive than I had expected. I am going it to leave it as is for the time
being.

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

Re: Best practice for logging XML and other byte oriented formats with slf4j?

2009-11-20T11:17:59Z

On Fri, Nov 20, 2009 at 7:44 PM, Thorbjoern Ravn Andersen <ravn@...> wrote:

Maarten Bosteels skrev:

XMLEncoder will have a severe impact on performance, I've tested
this extensively.
Have a look at
http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance
In my testcases, XMLEncoder serialized 300 events while a protobuf
serializer managed to handle nearly 10.000!
I'd therefore suggest that you take a mixed approach. Using
protobuf to serialize the events to a file and writing an
additional converter to convert that files to whatever you'd like
as XML-Output as needed

I think I didn't catch on to that discussion when you had it. Probably because I didn't understand it enough from a brief skim :)

A discussion about such a topic was started here:
http://marc.info/?l=logback-dev&m=124905434331308&w=2
<http://marc.info/?l=logback-dev&m=124905434331308&w=2> but I
completely forgot to file an RFE for it.
I've done just that now, thanks for the reminder!
http://jira.qos.ch/browse/LBCORE-128

I agree with Joern that XMLEncoder is not really suited when throughput is important to you.

For our purpose these "log this complex object" happen rarely enough that we are willing to accept a penalty here, to get a humanly readable rendering.

It's not about logging complex objects. It's about the number of log events that you can write per second. And the CPU cycles that you waste by generating XML.

> My current thoughts is to use a ByteArrayOutputStream and
generate a String using the UTF-8 decoding. The resulting string
contains a <?xml ... encoding="UTF-8"?> which is stripped
resulting in an XML String containing Unicode chars (instead of
encoded bytes).

What is the difference between "Unicode chars" and "encoded bytes" ?

I am talking about internal representation as char's and the encoded version which is a stream of bytes (which usually is put raw in a file).

Every unicode codepoint has to be encoded somehow, no ? UTF-8 is one way to encode the codepoint (and imho the encoding everyone should use)

This can then be flattened to an ASCII version, by converting all
characters outside 32..127 to their numeric entity (Ӓ), and
THAT can be safely logged. I guess :)
>

If you want to use XML, then I really don't see the problem with leaving it in UTF-8 ?

There is absolutely no guarantee that the final destination of the log string will be able to handle UTF-8 encoded strings. How does UTF-8 encoded strings end up looking when written using MacRoman under OS X?

IMHO, you should embrace UTF-8 instead of being afraid of it. Tools that are not able to handle UTF-8 are simply not worth using.

1) from http://www.w3.org/TR/xml11/#charencoding: "All XML processors MUST be able to read entities in both the UTF-8 and UTF-16 encodings."
2) I don't know MacRoman but from http://en.wikipedia.org/wiki/Mac_OS_Roman : "With the release of Mac OS X, Mac OS Roman was replaced by UTF-8 as the standard character encoding for the Macintosh operating system."

regards,
Maarten

Especially since you state that "a humanly readable transport format will be preferred." I would prefer to see Σ instead of Σ

Of course, it should be possible to tell the XMLEncoder which encoding to use (instead of using the default encoding of the platform).

XMLEncoder does not have the encoding public. Bah :)

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

From forum: Slf4J - user

Re: Best practice for logging XML and other byte oriented formats with slf4j?

2009-11-20T10:44:17Z

Maarten Bosteels skrev:

>
>
> XMLEncoder will have a severe impact on performance, I've tested
> this extensively.
> Have a look at
> http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance
> In my testcases, XMLEncoder serialized 300 events while a protobuf
> serializer managed to handle nearly 10.000!
> I'd therefore suggest that you take a mixed approach. Using
> protobuf to serialize the events to a file and writing an
> additional converter to convert that files to whatever you'd like
> as XML-Output as needed
>

I think I didn't catch on to that discussion when you had it. Probably
because I didn't understand it enough from a brief skim :)

> A discussion about such a topic was started here:
> http://marc.info/?l=logback-dev&m=124905434331308&w=2
> <http://marc.info/?l=logback-dev&m=124905434331308&w=2> but I
> completely forgot to file an RFE for it.
> I've done just that now, thanks for the reminder!
> http://jira.qos.ch/browse/LBCORE-128
>
>
> I agree with Joern that XMLEncoder is not really suited when
> throughput is important to you.

For our purpose these "log this complex object" happen rarely enough
that we are willing to accept a penalty here, to get a humanly readable
rendering.

>
>
> > My current thoughts is to use a ByteArrayOutputStream and
> generate a String using the UTF-8 decoding. The resulting string
> contains a <?xml ... encoding="UTF-8"?> which is stripped
> resulting in an XML String containing Unicode chars (instead of
> encoded bytes).
>
>
> What is the difference between "Unicode chars" and "encoded bytes" ?

I am talking about internal representation as char's and the encoded
version which is a stream of bytes (which usually is put raw in a file).

> Every unicode codepoint has to be encoded somehow, no ? UTF-8 is one
> way to encode the codepoint (and imho the encoding everyone should use)
>
> This can then be flattened to an ASCII version, by converting all
> characters outside 32..127 to their numeric entity (Ӓ), and
> THAT can be safely logged. I guess :)
> >
>
>
> If you want to use XML, then I really don't see the problem with
> leaving it in UTF-8 ?

There is absolutely no guarantee that the final destination of the log
string will be able to handle UTF-8 encoded strings. How does UTF-8
encoded strings end up looking when written using MacRoman under OS X?

> Especially since you state that "a humanly readable transport format
> will be preferred." I would prefer to see Σ instead of Σ
>
> Of course, it should be possible to tell the XMLEncoder which encoding
> to use (instead of using the default encoding of the platform).
>
XMLEncoder does not have the encoding public. Bah :)

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

From forum: Slf4J - user

Re: Best practice for logging XML and other byte oriented formats with slf4j?

2009-11-19T15:04:06Z

On Thu, Nov 19, 2009 at 10:33 PM, Joern Huxhorn <jhuxhorn@...> wrote:

On 19.11.2009, at 19:06, Thorbjoern Ravn Andersen wrote:

> Hi.
>
> We have reached a situation where I basically want to log a data structure in order to be able to process it later.
>
> After a bit of pondering, I have concluded that the best approach for us to do this would be to use the XMLEncoder/XMLDecoder in Java 1.4+ and log the generated XML snippets.
>
> The issue I want to solve is that the XMLEncoder writes an UTF-8 encoded XML file to an OutputStream, i.e. a byte oriented destination. To the best of my knowledge the slf4j backends all deal with Strings, i.e. character oriented destinations and the output files are written in the default encoding for the platform.
>
> The question now is, what is the best way to handle the OutputStream generated by XMLEncoder so it will survive all attempts to mess up any unicode characters inside due to encoding differences on the way. I will be using a custom layout anyway so much can be done :) A humanly readable transport format will be preferred.
>

XMLEncoder will have a severe impact on performance, I've tested this extensively.
Have a look at http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance
In my testcases, XMLEncoder serialized 300 events while a protobuf serializer managed to handle nearly 10.000!
I'd therefore suggest that you take a mixed approach. Using protobuf to serialize the events to a file and writing an additional converter to convert that files to whatever you'd like as XML-Output as needed.

A discussion about such a topic was started here: http://marc.info/?l=logback-dev&m=124905434331308&w=2 but I completely forgot to file an RFE for it.
I've done just that now, thanks for the reminder!
http://jira.qos.ch/browse/LBCORE-128

I agree with Joern that XMLEncoder is not really suited when throughput is important to you.

> My current thoughts is to use a ByteArrayOutputStream and generate a String using the UTF-8 decoding. The resulting string contains a <?xml ... encoding="UTF-8"?> which is stripped resulting in an XML String containing Unicode chars (instead of encoded bytes).

What is the difference between "Unicode chars" and "encoded bytes" ?
Every unicode codepoint has to be encoded somehow, no ? UTF-8 is one way to encode the codepoint (and imho the encoding everyone should use)

This can then be flattened to an ASCII version, by converting all characters outside 32..127 to their numeric entity (Ӓ), and THAT can be safely logged. I guess :)
>

If you want to use XML, then I really don't see the problem with leaving it in UTF-8 ?
Especially since you state that "a humanly readable transport format will be preferred." I would prefer to see Σ instead of Σ

Of course, it should be possible to tell the XMLEncoder which encoding to use (instead of using the default encoding of the platform).

regards,
Maarten

That would probably work but it would further decrease the serialization speed.
Logback (assuming you use Logback) should really support binary, i.e. byte-based, logfiles since this would really make a major performance difference. This should be discussed over at logback-dev, though.

> I'd appreciate comments on my thoughts, as this is a rather important intermediate step in us using log files to store information which can be used to simulate an external system when replaying an interesting sesion.
>
>

HTH,
Joern.

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

From forum: Slf4J - user

Re: Best practice for logging XML and other byte oriented formats with slf4j?

2009-11-19T13:33:06Z

On 19.11.2009, at 19:06, Thorbjoern Ravn Andersen wrote:

> Hi.
>
> We have reached a situation where I basically want to log a data structure in order to be able to process it later.
>
> After a bit of pondering, I have concluded that the best approach for us to do this would be to use the XMLEncoder/XMLDecoder in Java 1.4+ and log the generated XML snippets.
>
> The issue I want to solve is that the XMLEncoder writes an UTF-8 encoded XML file to an OutputStream, i.e. a byte oriented destination. To the best of my knowledge the slf4j backends all deal with Strings, i.e. character oriented destinations and the output files are written in the default encoding for the platform.
>
> The question now is, what is the best way to handle the OutputStream generated by XMLEncoder so it will survive all attempts to mess up any unicode characters inside due to encoding differences on the way. I will be using a custom layout anyway so much can be done :) A humanly readable transport format will be preferred.
>

XMLEncoder will have a severe impact on performance, I've tested this extensively.
Have a look at http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance
In my testcases, XMLEncoder serialized 300 events while a protobuf serializer managed to handle nearly 10.000!
I'd therefore suggest that you take a mixed approach. Using protobuf to serialize the events to a file and writing an additional converter to convert that files to whatever you'd like as XML-Output as needed.

A discussion about such a topic was started here: http://marc.info/?l=logback-dev&m=124905434331308&w=2 but I completely forgot to file an RFE for it.
I've done just that now, thanks for the reminder!
http://jira.qos.ch/browse/LBCORE-128

> My current thoughts is to use a ByteArrayOutputStream and generate a String using the UTF-8 decoding. The resulting string contains a <?xml ... encoding="UTF-8"?> which is stripped resulting in an XML String containing Unicode chars (instead of encoded bytes). This can then be flattened to an ASCII version, by converting all characters outside 32..127 to their numeric entity (Ӓ), and THAT can be safely logged. I guess :)
>

That would probably work but it would further decrease the serialization speed.
Logback (assuming you use Logback) should really support binary, i.e. byte-based, logfiles since this would really make a major performance difference. This should be discussed over at logback-dev, though.

> I'd appreciate comments on my thoughts, as this is a rather important intermediate step in us using log files to store information which can be used to simulate an external system when replaying an interesting sesion.
>
>

HTH,
Joern.

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

From forum: Slf4J - user

Re: Best practice for logging XML and other byte oriented formats with slf4j?

2009-11-19T10:18:55Z

Depending on the content of the XML you may want to consider logging the
base64 encoded octet stream. Trying to covert the octet stream in to a
String is very difficult to get write and can cause all sorts of
problems if your XML is signed or encrypted.

Thorbjoern Ravn Andersen wrote:

> Hi.
>
> We have reached a situation where I basically want to log a data
> structure in order to be able to process it later.
>
> After a bit of pondering, I have concluded that the best approach for us
> to do this would be to use the XMLEncoder/XMLDecoder in Java 1.4+ and
> log the generated XML snippets.
>
> The issue I want to solve is that the XMLEncoder writes an UTF-8 encoded
> XML file to an OutputStream, i.e. a byte oriented destination. To the
> best of my knowledge the slf4j backends all deal with Strings, i.e.
> character oriented destinations and the output files are written in the
> default encoding for the platform.
>
> The question now is, what is the best way to handle the OutputStream
> generated by XMLEncoder so it will survive all attempts to mess up any
> unicode characters inside due to encoding differences on the way. I
> will be using a custom layout anyway so much can be done :) A humanly
> readable transport format will be preferred.
>
> My current thoughts is to use a ByteArrayOutputStream and generate a
> String using the UTF-8 decoding. The resulting string contains a <?xml
> ... encoding="UTF-8"?> which is stripped resulting in an XML String
> containing Unicode chars (instead of encoded bytes). This can then be
> flattened to an ASCII version, by converting all characters outside
> 32..127 to their numeric entity (Ӓ), and THAT can be safely
> logged. I guess :)
>
> I'd appreciate comments on my thoughts, as this is a rather important
> intermediate step in us using log files to store information which can
> be used to simulate an external system when replaying an interesting
> sesion.
>
>

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad.lajoie@..., http://www.switch.ch

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

From forum: Slf4J - user

Best practice for logging XML and other byte oriented formats with slf4j?

2009-11-19T10:06:17Z

Hi.

We have reached a situation where I basically want to log a data
structure in order to be able to process it later.

After a bit of pondering, I have concluded that the best approach for us
to do this would be to use the XMLEncoder/XMLDecoder in Java 1.4+ and
log the generated XML snippets.

The issue I want to solve is that the XMLEncoder writes an UTF-8 encoded
XML file to an OutputStream, i.e. a byte oriented destination. To the
best of my knowledge the slf4j backends all deal with Strings, i.e.
character oriented destinations and the output files are written in the
default encoding for the platform.

The question now is, what is the best way to handle the OutputStream
generated by XMLEncoder so it will survive all attempts to mess up any
unicode characters inside due to encoding differences on the way. I
will be using a custom layout anyway so much can be done :) A humanly
readable transport format will be preferred.

My current thoughts is to use a ByteArrayOutputStream and generate a
String using the UTF-8 decoding. The resulting string contains a <?xml
... encoding="UTF-8"?> which is stripped resulting in an XML String
containing Unicode chars (instead of encoded bytes). This can then be
flattened to an ASCII version, by converting all characters outside
32..127 to their numeric entity (Ӓ), and THAT can be safely
logged. I guess :)

I'd appreciate comments on my thoughts, as this is a rather important
intermediate step in us using log files to store information which can
be used to simulate an external system when replaying an interesting sesion.

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

From forum: Slf4J - user

[Bug 75] Cyclic dependency in OSGi

2009-11-17T11:28:44Z

http://bugzilla.slf4j.org/show_bug.cgi?id=75

--- Comment #13 from Hugues Malphettes <hmalphettes@...> 2009-11-17 20:29:55 ---
(In reply to comment #12)
> Created an attachment (id=66)
--> (http://bugzilla.slf4j.org/attachment.cgi?id=66) [details]
> Same patch with the 1.5.5 version for the import-packaged
>

A build of the slf4j trunk with this patch combined with a 0.9.18-SNAPSHOT
build of logback (with the fix for LBCLASSIC-165) is enough to run jetty-osgi:
http://github.com/intalio/hightide-on-osgi/commit/bc02cc9167a7a192f503c1a69c418206e9228478

For those of us using the springsource packaging beware that it relies on an
old version of slf4j (1.5.6) where the log4j-over-slf4j is incomplete: it lacks
org.apache.log4j.LogManager. openjpa for example cannot work with
log4j-over-slf4j with the 1.5.6 build.

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 75] Cyclic dependency in OSGi

2009-11-17T09:31:58Z

http://bugzilla.slf4j.org/show_bug.cgi?id=75

Hugues Malphettes <hmalphettes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #63 is|0 |1
obsolete| |

--- Comment #12 from Hugues Malphettes <hmalphettes@...> 2009-11-17 18:33:07 ---
Created an attachment (id=66)
--> (http://bugzilla.slf4j.org/attachment.cgi?id=66)
Same patch with the 1.5.5 version for the import-packaged

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 31] Varargs for Logger methods

2009-11-16T10:54:52Z

http://bugzilla.slf4j.org/show_bug.cgi?id=31

--- Comment #67 from Thorbjørn Ravn Andersen <ravn@...> 2009-11-16 19:56:00 ---
(In reply to comment #64)
> > Please be aware that slf4j serves many people with many different needs, and
> > that Java is the new Cobol. Literally :)
> >
>
> Some place we using IBM machines with AIX, it's support Java 1.6.... if some
> people have win 3.1, java need to be support? no. Use older version of java.
> Same with slf4j and any other libraries. Please do not block the new features
> development! If you want to use 1.4 java, use slf4j 1.5.x, that's all.

I am not blocking new development at all. I am trying to tell you that Java
1.4 is not quite dead everywhere.

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 159] New: Default to a behavior when no adapter found in the classpath

2009-11-16T05:35:48Z

http://bugzilla.slf4j.org/show_bug.cgi?id=159

Summary: Default to a behavior when no adapter found in the
classpath
Product: SLF4J
Version: unspecified
Platform: All
URL: http://opensource.atlassian.com/projects/hibernate/brows
e/HHH-3486
OS/Version: Linux
Status: NEW
Severity: major
Priority: P1
Component: Core API
AssignedTo: dev@...
ReportedBy: acoliver@...

see: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3486

Rather than refuse to start because no appender is found, default to some
sensible default logging behavior.

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 31] Varargs for Logger methods

2009-11-16T02:10:01Z

http://bugzilla.slf4j.org/show_bug.cgi?id=31

--- Comment #66 from boci <boci.boci@...> 2009-11-16 11:11:12 ---
(In reply to comment #65)

Umm, ok i'm wrong (I try to tell you what I mean when i say "binary compatible
not required". If you change to Object[] to Object... it's transparent
modification. It's "Binary compatible" (old application which use Object[] can
work without any binary(!)/source modification) but not "Java backward
compatible" (java 1.4 application can't use the new coolest slf4j version
because it's binary incompatible(!) (1.5 required)).

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 31] Varargs for Logger methods

2009-11-16T01:58:50Z

http://bugzilla.slf4j.org/show_bug.cgi?id=31

--- Comment #65 from Ceki Gulcu <listid@...> 2009-11-16 11:00:01 ---
Janos (boci.boci@...),

Even if everyone on the planet was using JDK 1.7, SLF4J would still need to
ensure binary compatibility with previous versions.

If in project P you have dependency D1 using slf4j 1.5 and dependency D2 using
the newest coolest versions of slf4j, say 1.6, then for D1 and D2 to cohabit,
slf4j versions 1.5 and 1.6 need to be binary compatible. It has little to do
with the JDK version actually. Before writing that you disagree, read this over
until you change your mind.

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 31] Varargs for Logger methods

2009-11-16T00:37:07Z

http://bugzilla.slf4j.org/show_bug.cgi?id=31

--- Comment #64 from boci <boci.boci@...> 2009-11-16 09:38:18 ---
(In reply to comment #62)

> (In reply to comment #58)
>
> > Disagree. Runtime compatibility is not required. Java 1.4 is dead. I think only
> > bugfix release need for 1.4 compatible slf4j.
>
> Just for the record. Our primary deployment platform is AS/400 (or whatever
> IBM chose to call it this week), where Java 1.4 is the default JVM so our
> installations need to be 1.4 compliant. It is nontrivial to have another
> version installed so we have opted to keep 1.4 compatible until OS/400 V5R4 is
> EOL'led.
>
> Please be aware that slf4j serves many people with many different needs, and
> that Java is the new Cobol. Literally :)
>

Some place we using IBM machines with AIX, it's support Java 1.6.... if some
people have win 3.1, java need to be support? no. Use older version of java.
Same with slf4j and any other libraries. Please do not block the new features
development! If you want to use 1.4 java, use slf4j 1.5.x, that's all.

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev

[Bug 31] Varargs for Logger methods

2009-11-16T00:26:02Z

http://bugzilla.slf4j.org/show_bug.cgi?id=31

--- Comment #63 from Thorbjørn Ravn Andersen <ravn@...> 2009-11-16 09:26:55 ---
(In reply to comment #61)

> Bug #133 is one such issue, something that I would have needed on several
> occasions, one of which was the bridging of XSLT messages to SLF4J. Being able

I think I've missed that discussion on the mailing list? Could you summarize
there what your ideas are?

--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dev mailing list
dev@...
http://www.slf4j.org/mailman/listinfo/dev

From forum: Slf4J - dev