October 2012 - slf4j-dev - mailman3.qos.ch

[Bug 212] New: MessageFormat. format throws Exception when attempting to parse parameters
by bugzilla-daemon＠pixie.qos.ch 13 Mar '13

13 Mar '13

http://bugzilla.slf4j.org/show_bug.cgi?id=212 Summary: MessageFormat.format throws Exception when attempting to parse parameters Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Mac OS X 10.3 Status: NEW Severity: blocker Priority: P1 Component: jul-to-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: kristof.pelckmans(a)wondergraphs.com I am trying to bridge a LogRecord with a message that is the result of HashMap.toString(): {interface com.google.code.morphia.annotations.Id=(a)com.google.code.morphia.annotations.Id()} and get following exception Caused by: java.lang.IllegalArgumentException: can't parse argument number interface com.google.code.morphia.annotations.Id=(a)com.google.code.morphia.annotations.Id() at java.text.MessageFormat.makeFormat(MessageFormat.java:1339) at java.text.MessageFormat.applyPattern(MessageFormat.java:458) at java.text.MessageFormat.<init>(MessageFormat.java:350) at java.text.MessageFormat.format(MessageFormat.java:811) at org.slf4j.bridge.SLF4JBridgeHandler.getMessageI18N(SLF4JBridgeHandler.java:233) FIX: do not format since there are no parameters! if (params != null && params.length > 0) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 1

[Bug 236] New: Use standard java.util.ServiceLoader for SLF4J Binding
by bugzilla-daemon＠pixie.qos.ch 25 Feb '13

25 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=236 Summary: Use standard java.util.ServiceLoader for SLF4J Binding Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cronier.jy(a)gmail.com What about use ServiceLoader to find which binding to use? For JDK<1.6 compatibility, we can test Class.forName("java.util.ServiceLoader") and switch to an internal equivalent implementation of ServiceLoader. No need to have one (or multiple) StaticLoggerBinder. This ServiceLoader is used, for example, for JRE XSL implementation, or java.sql.Driver. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 10

discussion about LogService ranking in osgi-over-slf4j
by Christian Trutz 26 Oct '12

26 Oct '12

Hi osgi-over-slf4j developers, I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the SLF4J LogService because Equinox register also a LogService with default ranking 0. SLF4J gets also ranking 0 (default ranking) because no service ranking is explicitly set. Is it OK for you if I introduce ranking = 10 for SLF4J LogService? If want to commit following change: Properties props = new Properties(); *props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService implementation."); props.put(Constants.SERVICE_RANKING, 10);* ServiceFactory factory = new LogServiceFactory(); bundleContext.registerService(LogService.class.getName(), factory, props); to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should made log service ranking configurable ... (via system property for example). With the above change, I can also see OSGi log messages in Beagle ;-) Thats COOL ... Christian

3 5

Re: [slf4j-dev] SL4FJ light: ad-hoc bindings for friendlier OSGi/IoC integration
by Simon Chemouil 17 Oct '12

17 Oct '12

On Wed, Oct 17, 2012 at 9:53 AM, Gunnar Wagenknecht <gunnar(a)wagenknecht.org> wrote: > After reading through the proposal I was wondering if adding a setter to > LoggerFactory (note: over-simplified!) has been considered an option? > In combination with an activator for the SLF4J API this might be a > flexible and simple way to open the gate for a broad range of other > options without causing too much disruption in the user base. Hi Gunnar, First thank you for your message and proof-of-concept. I considered this option before submitting my proposal, but I found it to be "un-OSGi", since this way static clients of the LoggerFactory can access ILoggerFactory services without binding them using their own bundle context, and thus circumvent optional security or service filters (as in OSGi subsystems). Your proposal does fix the import on org.slf4j.impl by making it optional, but because of the fact that the call to getLogger() is static, some class may get a no-op logger *before* any ILoggerFactory service is registered: so a proxy is needed not only for swapping implementations, but simply to benefit from dynamic installation order. I am also worried that this technique will make the behavior of slf4j-api differ between OSGi and non-OSGi environments (with a different binding system used implicitly) and might confuse more than it helps. I do find your solution useful for OSGi users who don't care about permisions/service hooks and need backwards compatibility with static LoggerFactory but need the dynamic OSGi binding, but I would make it something complementary to solution (3) rather than the solution on its own. I personally would rather have the API be just that: a passive API that doesn't register service listeners or tries to find an implementation. > Moving Logger and LoggerFactory out of "org.slf4j" just for the sake of > OSGi (or any other runtime environment) does not sound like the best > option to me. It causes migration grief for many, many users to satisfy > a (IMHO) much smaller group of SLF4J implementors/integrators. The proposal I am pushing for (solution 3) would not change org.slf4j and we would keep LoggerFactory there. However we would introduce a new package, org.slf4j.api, with only the interfaces. The plan is to make it entirely transparent for all existing users (both OSGi and non-OSGi). There would be 4 deprecated interfaces but: * they would remain in the official distribution for a long time * it would still be possible after their removal to provide a simple compat JAR for non-OSGi users (and OSGi users using Require-Bundle to force split package resolution) * their replacement would be their exact copy, the fix is a matter of changing an import. We can upgrade the migrator tool to also support this. I honestly do feel like there is no reason for grief, because there is no migration. The JAR you use (slf4j-api), either downloading or from Maven central, will have the same contents for years. Two new JARs will be introduced for those of us who explicitly want less. > I think Ceki can provide more details of the effects this might cause. > For example, the method (in it's current implementation) allows changing > the factory at runtime multiple times. For this to work reliable, the > Loggers really need to become proxies to the actual ("current") logger. > They are usually held in static variables. A really dynamic OSGi > implementation might actually implement it that way. However, SLF4J can > simply delegate that complexity to the runtime. As I mentioned earlier, we discussed using proxies for loggers. My understanding is that SLF4J would need to define an extension so that the delegates doing the messy work can declare themselves. I feel this increases complexity for little benefit. Cheers, -- Simon

1 0

[Bug 277] New: Jar filenames should match eclipse P2 naming conventions
by bugzilla-daemon＠qos.ch 17 Oct '12

17 Oct '12

http://bugzilla.slf4j.org/show_bug.cgi?id=277 Summary: Jar filenames should match eclipse P2 naming conventions Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: markus.stier(a)stegmannsystems.com I use slf4j within an eclipse RCP project. To populate my target platform I've created a p2 repository which contains all required 3rd party bundles. P2 resolves the bundle jar by its id and version using the following scheme: <Bundle-SymbolicName>_<Bundle-Version>.jar Currently your bundles names follow the scheme: <Bundle-Name>-<Bundle-Version>.jar Is there any chance that you provide the bundles according to p2 naming scheme? -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 276] New: Bundle-Name of slf4j-ext does not match Bundle-SymbolicName
by bugzilla-daemon＠qos.ch 17 Oct '12

17 Oct '12

http://bugzilla.slf4j.org/show_bug.cgi?id=276 Summary: Bundle-Name of slf4j-ext does not match Bundle-SymbolicName Product: SLF4J Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: blocker Priority: P1 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: markus.stier(a)stegmannsystems.com Maybe a copy and paste error? Bundle-Version: 1.7.2 Implementation-Version: 1.7.2 Premain-Class: org.slf4j.agent.AgentPremain Implementation-Title: slf4j-ext Bundle-ManifestVersion: 2 Bundle-SymbolicName: slf4j.ext Bundle-Name: slf4j-log4j12 -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

SL4FJ light: ad-hoc bindings for friendlier OSGi/IoC integration
by Simon Chemouil 17 Oct '12

17 Oct '12

Hi, I am in the process of choosing a logging framework for an OSGi-based project and obviously SLF4J is a strong contender. It is nearly ubiquitous now and has an OSGi LogService bridge, as well as a very interesting implementation (Logback). However, the design of SLF4J, as it is, is somewhat OSGi unfriendly: we have the API bundle depending on its implementation -- and the opposite. This cyclic dependency is the consequence of trying to make it extremely easy in regular Java environments to plug a SLF4J implementation to the LoggerFactory, simply by "dropping a jar" in the runtime classpath. I don't know if the following points have been already discussed, and I could not find anything in the archives. I understand this solution is inherited from Log4J, and that it was itself a solution to the classloading problems in JCL. Dynamic binding and classloader hacks are clearly problematic in some setups, and there is no "one size fits all", because Java allows many styles and SLF4J, as a universal logging facade, should definitely work best everywhere possible. I believe SLF4J could become more universal/ubiquitous if the static binding approach was ad-hoc and not part of the "API side": OSGi/Guice/Spring folks like me could then use ILoggerFactory/IMarkerFactory as service specifications and use the more natural "dynamic binding" provided in their framework. For instance, component frameworks for OSGi providing DI could easily inject a logger by component instance (in the spirit of [1]). In OSGi particularly, the best practices are that an "active" service is provided only when the bundle is active but stateful singletons like LoggerFactory don't follow these rules. The FAQ entry "Is it possible to retrieve loggers without going through the static methods in LoggerFactory?"[2] partly addresses this: yes it is already possible to ignore LoggerFactory and static binding. Unfortunately this is still not fully OSGi-friendly (and I think it applies to any module system): * the current SLF4J bundle imports the package org.slf4j.impl with a mandatory resolution. It means there *must* be an implementation providing that package, and that the package *must* be exported. Best practices recommend making implementation packages private and thus non-usable by external bundles at all, even for reflection. * if we were to specify the resolution of org.slf4j.impl as optional, then any piece of code using LoggerFactory directly will default to a no-op logger with a message on stderr. This doesn't look like a big problem, but ideally in an OSGi context I would not want to provide that class at all and someone trying to use LoggerFactory.getLogger() would simply not get their component to build. Only people using static binding should have the class in their build classpath. I think there is not much to do to address these issues: it should be enough to separate binding logic (e.g LoggerFactory / MarkerFactory and the .spi package) into another JAR. For legacy reasons, so that OSGi projects already using SLF4J's static binding are not broken, and because split packages are generally unsupported in OSGi, LoggerFactory and MarkerFactory should move to another package like org.slf4j.staticfactories (or whatever). If they move to another package, there should still be LoggerFactory and MarkerFactory classes that redirect to the "new" ones for compatibility reasons (though deprecated and scheduled for removal at the next backwards compatibility break). The new modules available would be: * slf4j-api: purely API, no wiring, no state, no singletons. Default implementations could still be packaged here. * slf4j-staticbindings: providing the LoggerFactory / MarkerFactory classes in a new package. Only this JAR should reference org.slf4j.impl. * slf4j-compat: providing bridge between org.slf4j.{Logger,Marker}Factory and org.slf4j.staticfactories.{Logger,Marker}Factory. * all the existing slf4j implementations could provide both bridging to OSGi and through static factories. To sum up: for non-OSGi users we could keep backwards compatible for code, but there would be two new JARs on the classpath. It is also possible to merge them in a all-in-one JAR as of now. OSGi users could benefit from having multiple concurrent SLF4J implementations, or even multiple SLF4J API versions. I'm not really sure how this proposal is going to be received (because this is obviously a central design choice in SLF4J). I truly think this is best for SLF4J to let users pick how they want to do their binding: it is a facade after all, it should be as abstract as possible. It will also make SLF4J more durable, because these questions will also happen when Jigsaw comes with Java 9: it is imo better to prepare early to avoid forks/fragmentation. My proposal will not break source compatibility but will make all the calls to LoggerFactory.getLogger() deprecated. The migrator tool could replace those easily, and it would still be possible to provide a compat jar. The cost of the indirection at class loading, especially compared to the classpath scanning of static binding, is negligible. The real problematic consequence would be for people not adding the new JARs to their classpath... This could be justification enough to bump the version to 2.0.0, to so that people know the scope of the JARs have been redefined (e.g, the API is backwards-compatible but the JARs are not). Please let me know if you think the proposal makes sense or not :), I would be willing to provide the necessary patches / updates to the FAQ. Cheers, Simon [1] http://www.tzavellas.com/techblog/2007/03/31/implementing-seam-style-logger… [2] http://www.slf4j.org/faq.html#noLoggerFactory

3 4

[GIT] SLF4J: Simple Logging Facade for Java annotated tag v_1.7.2 created. v_1.7.2
by git-noreply＠pixie.qos.ch 11 Oct '12

11 Oct '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "SLF4J: Simple Logging Facade for Java". The annotated tag, v_1.7.2 has been created at c962b775a645276e7701a5a137c49bf5ac9c993d (tag) tagging c06e41788dcd9ce06602d2709ce34261adff4ce9 (commit) replaces v_1.7.1 tagged by Ceki Gulcu on Thu Oct 11 20:59:50 2012 +0200 - Log ----------------------------------------------------------------- tagging 1.7.2 Ceki Gulcu (8): starting 1.7.2 cycle improved javadocs Merge pull request #23 from bircow/master added follow @qos_ch link forcedLog method should be in the Category class as in the original log4j software added warnLevelString property news update about to relese 1.7.2 Christian Trutz (3): log4j-over-slf4j works now also with IBM DB2 Content Manager 8. Merge branch 'master' of https://github.com/qos-ch/slf4j Convert line delimiters to unix style (\n) and recover the ability to Libor Jelinek (2): Updated broken links on mailinglists archives on Nabble (http://bugzilla.slf4j.org/show_bug.cgi?id=218) Merge remote-tracking branch 'upstream/master' Matt Bishop (1): Merge pull request #26 from mattbishop/master mbishop (3): Bugzilla #269. Merge remote-tracking branch 'upstream/master' Bugzilla #274. ----------------------------------------------------------------------- hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[qos-ch/slf4j]
by ceki 11 Oct '12

11 Oct '12

Branch: refs/tags/v_1.7.2 Home: https://github.com/qos-ch/slf4j

1 0

[GIT] SLF4J: Simple Logging Facade for Java branch master updated. v_1.7.1-17-gc06e417
by git-noreply＠pixie.qos.ch 11 Oct '12

11 Oct '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "SLF4J: Simple Logging Facade for Java". The branch, master has been updated via c06e41788dcd9ce06602d2709ce34261adff4ce9 (commit) via 42b0e19c309cfd0fcf2e695495134e71a289913c (commit) from e74da9a73fc96401f39e00604fb4ad83ac31ffaf (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=c06e41788dcd9ce06602d2709c… http://github.com/ceki/slf4j/commit/c06e41788dcd9ce06602d2709ce34261adff4ce9 commit c06e41788dcd9ce06602d2709ce34261adff4ce9 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Oct 11 20:59:38 2012 +0200 about to relese 1.7.2 diff --git a/integration/pom.xml b/integration/pom.xml index 6aac8b6..0cc458c 100644 --- a/integration/pom.xml +++ b/integration/pom.xml @@ -6,7 +6,7 @@ <parent> <groupId>org.slf4j</groupId> <artifactId>slf4j-parent</artifactId> - <version>1.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/jcl-over-slf4j/pom.xml b/jcl-over-slf4j/pom.xml index 9517666..94b24a7 100644 --- a/jcl-over-slf4j/pom.xml +++ b/jcl-over-slf4j/pom.xml @@ -4,7 +4,7 @@ <parent> <groupId>org.slf4j</groupId> <artifactId>slf4j-parent</artifactId> - <version>1.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/jul-to-slf4j/pom.xml b/jul-to-slf4j/pom.xml index 4567bfd..ac363ce 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/log4j-over-slf4j/pom.xml b/log4j-over-slf4j/pom.xml index 0cc67f0..7c2cd09 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/osgi-over-slf4j/pom.xml b/osgi-over-slf4j/pom.xml index 201eec4..a2dc977 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/pom.xml b/pom.xml index dae2c0a..d193a0a 100644 --- a/pom.xml +++ b/pom.xml @@ -7,7 +7,7 @@ <groupId>org.slf4j</groupId> <artifactId>slf4j-parent</artifactId> - <version>1.7.2-SNAPSHOT</version> + <version>1.7.2</version> <packaging>pom</packaging> <name>SLF4J</name> diff --git a/slf4j-api/pom.xml b/slf4j-api/pom.xml index 552ece5..3545d52 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-ext/pom.xml b/slf4j-ext/pom.xml index f3c6913..677d629 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-jcl/pom.xml b/slf4j-jcl/pom.xml index ac0ff7a..6eec886 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-jdk14/pom.xml b/slf4j-jdk14/pom.xml index 23bbeae..0e2554e 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-log4j12/pom.xml b/slf4j-log4j12/pom.xml index 80661be..b2d63a4 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-migrator/pom.xml b/slf4j-migrator/pom.xml index ebb0e08..f073e30 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-nop/pom.xml b/slf4j-nop/pom.xml index 7bbfe77..1c196a8 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-simple/pom.xml b/slf4j-simple/pom.xml index c9ef240..232bf6e 100644 --- a/slf4j-simple/pom.xml +++ b/slf4j-simple/pom.xml @@ -4,7 +4,7 @@ <parent> <groupId>org.slf4j</groupId> <artifactId>slf4j-parent</artifactId> - <version>1.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-site/pom.xml b/slf4j-site/pom.xml index 3ed9148..4db0675 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.7.2-SNAPSHOT</version> + <version>1.7.2</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/slf4j-site/src/site/pages/news.html b/slf4j-site/src/site/pages/news.html index 19047ab..1b15b96 100644 --- a/slf4j-site/src/site/pages/news.html +++ b/slf4j-site/src/site/pages/news.html @@ -29,7 +29,7 @@ <hr noshade="noshade" size="1"/> - <h3>14th of September, 2012 - Release of SLF4J 1.7.2</h3> + <h3>11th of October, 2012 - Release of SLF4J 1.7.2</h3> <p>Added osgi-over-slf4j module which serves as an OSGi LogService implementation delegating to slf4j. This module is maintained by http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=42b0e19c309cfd0fcf2e695495… http://github.com/ceki/slf4j/commit/42b0e19c309cfd0fcf2e695495134e71a289913c commit 42b0e19c309cfd0fcf2e695495134e71a289913c Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Oct 11 20:50:26 2012 +0200 news update diff --git a/slf4j-site/src/site/pages/news.html b/slf4j-site/src/site/pages/news.html index 386fdaf..19047ab 100644 --- a/slf4j-site/src/site/pages/news.html +++ b/slf4j-site/src/site/pages/news.html @@ -31,12 +31,27 @@ <h3>14th of September, 2012 - Release of SLF4J 1.7.2</h3> + <p>Added osgi-over-slf4j module which serves as an OSGi LogService + implementation delegating to slf4j. This module is maintained by + Matt Bishop and Libor Jelinek.</p> + + <p> Christian Trutz added missing PatternLayout class as well as + several methods in the <code>Logger</code> and + <code>Category</code> classes. See commit 442e90ba5785cba9 dated + September 27th 2012 for details. + </p> + + <p>Added org.slf4j.simpleLoggerwarnLevelString in slf4j-simple + module.</p> + <p>Fixed <a href="http://bugzilla.slf4j.org/show_bug.cgi?id=272">bug 272</a>. All <code>Logger</code> implementations shipping with SLF4J use <code>Object...</code> instead of <code>Object[]</code> to avoid compiler warnings.</p> + + <hr noshade="noshade" size="1"/> <h3>14th of September, 2012 - Release of SLF4J 1.7.1</h3> ----------------------------------------------------------------------- Summary of changes: integration/pom.xml | 2 +- jcl-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 +- slf4j-ext/pom.xml | 2 +- slf4j-jcl/pom.xml | 2 +- slf4j-jdk14/pom.xml | 2 +- slf4j-log4j12/pom.xml | 2 +- slf4j-migrator/pom.xml | 2 +- slf4j-nop/pom.xml | 2 +- slf4j-simple/pom.xml | 2 +- slf4j-site/pom.xml | 2 +- slf4j-site/src/site/pages/news.html | 17 ++++++++++++++++- 16 files changed, 31 insertions(+), 16 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0