- slf4j-dev - mailman3.qos.ch

[qos-ch/slf4j] 3f776e: Velocity 1.7 support included.
by Christian Trutz 08 Nov '12

08 Nov '12

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 3f776eb758fd59429bb654f594d9c8feb2d9574c https://github.com/qos-ch/slf4j/commit/3f776eb758fd59429bb654f594d9c8feb2d9… Author: Christian Trutz <christian.trutz(a)belaso.de> Date: 2012-11-08 (Thu, 08 Nov 2012) Changed paths: M log4j-over-slf4j/src/main/java/org/apache/log4j/Category.java M log4j-over-slf4j/src/main/java/org/apache/log4j/PatternLayout.java A log4j-over-slf4j/src/main/java/org/apache/log4j/RollingFileAppender.java Log Message: ----------- Velocity 1.7 support included. See also http://bugzilla.slf4j.org/show_bug.cgi?id=280 Signed-off-by: Christian Trutz <christian.trutz(a)belaso.de>

1 0

[Bug 280] New: missing constructor in org.apache.log4j.PatternLayout
by bugzilla-daemon＠qos.ch 05 Nov '12

05 Nov '12

http://bugzilla.slf4j.org/show_bug.cgi?id=280 Summary: missing constructor in org.apache.log4j.PatternLayout Product: SLF4J Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: thomas.mortagne(a)gmail.com It's in version 1.7.2 (can't find it in the list). When using default org.apache.velocity.app.VelocityEngine (Velocity 1.7) it's trying to create a new PatternLayout in it's LOG4J logger but it's using the constructor which takes a String and this constructor is not provider by log4j-over-slf4j. It used to "work" well when there was no PatternLayout at all because Velocity catch NoClassDefFoundError but it does not expect a NoSuchMethodError. The workaround (and what should be done anyway) is to provide a SLF4J based custom logger to Velocity. But still it would be nice to mimic a bit better log4j for this use case. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[Bug 278] New: addition of new methods: Logger.debug(String format, Throwable t, Object... arguments)
by bugzilla-daemon＠qos.ch 02 Nov '12

02 Nov '12

http://bugzilla.slf4j.org/show_bug.cgi?id=278 Summary: addition of new methods: Logger.debug(String format, Throwable t, Object... arguments) Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: minor Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: kap4020(a)gmail.com I feel there is a few missing methods in Logger, that which take in a String format, Object arguments, and a Throwable. I understand that the varargs argument needs to be last, but it would be nice to have methods that take in all three: * error(String msg, Throwable t, Object... arguments) * debug(String msg, Throwable t, Object... arguments) * info(String msg, Throwable t, Object... arguments) * warn(String msg, Throwable t, Object... arguments) * trace(String msg, Throwable t, Object... arguments) And a similar set with a Marker argument. Thoughts? -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

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