December 2009 - slf4j-dev - mailman3.qos.ch

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 15 Dec '09

15 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #71 from Joern Huxhorn <joern(a)huxhorn.de> 2009-12-15 22:06:23 --- In reply to comment #70: Thanks for the thumbs-up! I'd obviously vote for a) but I can explain why b) wouldn't fly, too. If SLF4J would be bumped to 2.0 without staying binary-compatible with 1.5.x and you'd have artifacts where one would depend on 1.5.x and the other on 2.0.x then everything would explode. This would mean that *every* module would have to be upgraded before anything would work again - and this is absolutely impossible. -- 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 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 15 Dec '09

15 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #70 from Rick Beton <rick.beton(a)gmail.com> 2009-12-15 19:31:17 --- As a user, what I want is a *simple* API based on Java 1.5. I'd also like my existing code not to break. The crux of this lengthy three-year discussion is that these are conflicting requirements in detail. Therefore I generally support either a. Joern Huxhorn's suggestion for a new slimmer API: throw away unwanted methods, even throw away methods with explicit Throwables on the basis of the principle of least surprise (I've seen FAR too many mistakes made with incorrect logging of Throwables). The only downside of Joern's idea is that the Eclipse organize-imports operation faces a new ambiguity because of the new packages containing Logger and LoggerFactory as well as the old packages. And there's more to document and maintain. b. Bump up to v2.0 and provide source-level backward compatibility only. By adding methods with varargs whilst keeping old methods, there might be compilation failures caused by method ambiguities. So don't do that. Instead, slim down the API to avoid ambiguities, even though this will provide only source-level backward-compatibility, rather than binary-level. That gets my vote. SLF4J gets better! Either way, drop the methods with Throwable arguments when varargs will do instead. Rick -- 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

I've just added NDC...
by Joern Huxhorn 12 Dec '09

12 Dec '09

...to my SLF4J-API redesign at http://github.com/huxi/slf4j/tree/slf4j-redesign Regards, Joern.

1 0

[Bug 75] Cyclic dependency in OSGi
by bugzilla-daemon＠pixie.qos.ch 04 Dec '09

04 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=75 --- Comment #17 from Hugues Malphettes <hmalphettes(a)intalio.com> 2009-12-04 21:14:35 --- (In reply to comment #16) > > It looks like you simple use the PackageAdmin to look for anything that exports > the "impl" package. I don't think that this "magic" is the best approach. One > reason is that it forces implementors to export internal implementation. Note, > in OSGi it's actually considered good style not to export internal > implementation. Another thing is that I think you'll need re-implement a lot of > logic around handling package wiring, etc. For example, what happens if two > different SLF4J API versions are installed? Mind you, in OSGi this is possible. Agreed: in fact it behaves in that situation just like slf4j outside of OSGi: a warning and it picks the first one. (not sure it is coded that way yet...) > > > slf4j implementations would be packaged as bundles and slf4j-api would not > > import the org.slf4j.impl package. > > If we are really going to provide an OSGi integrator bundle which depends on > OSGi API I propose to use OSGi services. API providers would simply export the > "impl" as an OSGi service. The OSGi integrator bundle would watch for those > services. OSGi takes care of proper resolution, conditions/permissions, service > ranking, etc. ... > > In contrast - if you really want the full benefits of OSGi, then the fragment > approach should be dropped. > The prototype really was just about solving this bug with thse constraints: - no impact on slf4j-api - no impact on the slf4j-impls as packaged today. The approach gives some kind of dynamic support to plug slf4j implementations but it remains brittle. The extra complexity is limited to those 4 classes and it happens to work with all bundles built by slf4j and logback. The PackageAdmin hack is an extender pattern (http://www.aqute.biz/Snippets/Extender) based on the Import-Package header. Using an actual OSGi service would be a lot cleaner and would give enough room to use all of OSGi benefits. So: - the Static*Binder classes http://github.com/hmalphettes/slf4j/tree/osgi-binder/slf4j-api-osgi/src/mai… will look similar - we will need to modify the slf4j implementations to declare that they provide the service. If someone has a good idea of what the service should look like, I am interested in giving it a shot. -- 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 75] Cyclic dependency in OSGi
by bugzilla-daemon＠pixie.qos.ch 04 Dec '09

04 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=75 --- Comment #16 from Gunnar Wagenknecht <gunnar(a)wagenknecht.org> 2009-12-04 20:49:31 --- (In reply to comment #15) > Here is a fragment that supports pluggable slf4j implementations: > http://github.com/hmalphettes/slf4j/tree/osgi-binder/slf4j-api-osgi/src/mai… Thanks for the link. I had a quick look and I have some comments/questions. It looks like you simple use the PackageAdmin to look for anything that exports the "impl" package. I don't think that this "magic" is the best approach. One reason is that it forces implementors to export internal implementation. Note, in OSGi it's actually considered good style not to export internal implementation. Another thing is that I think you'll need re-implement a lot of logic around handling package wiring, etc. For example, what happens if two different SLF4J API versions are installed? Mind you, in OSGi this is possible. > slf4j implementations would be packaged as bundles and slf4j-api would not > import the org.slf4j.impl package. If we are really going to provide an OSGi integrator bundle which depends on OSGi API I propose to use OSGi services. API providers would simply export the "impl" as an OSGi service. The OSGi integrator bundle would watch for those services. OSGi takes care of proper resolution, conditions/permissions, service ranking, etc. > But managing bundles is certainly nicer than managing fragments so maybe that > is a good approach? It boils down to what's really necessary. IMHO the fragment approach works very well. Of course, it has some limitations but other than dealing with manifests it doesn't introduce any dependencies on OSGi APIs. Additionally, from an SLF4J point of you nothing changes, i.e. everything is loaded by the same ClassLoader and bound to the same lifecycle (of the SLF4J API bundle). It's just that the "impl" package shouldn't be exported by the API bundle but contained in a fragment. Additionally, fragments allow for tight coupling to a specific hosts. This may make versioning less error prone because the fragment only resolves if it can be bound to the right SLF4J API host. In contrast - if you really want the full benefits of OSGi, then the fragment approach should be dropped. -- 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 75] Cyclic dependency in OSGi
by bugzilla-daemon＠pixie.qos.ch 04 Dec '09

04 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=75 --- Comment #15 from Hugues Malphettes <hmalphettes(a)intalio.com> 2009-12-04 19:28:47 --- (In reply to comment #14) > FWIW, in the Eclipse Orbit repository we also provide an SLF4J API bundle. This > bundle follows the fragment approach which a small difference. The SLF4J API > bundle neither imports nor exports the "impl" package. The "impl" package has > to be provided by a fragment. It's also not exported because it's not API. > Others (except SLF4J) should not be able to import the "impl" package. > > BTW, fragments can happily consume services simply by using FrameworkUtil to > get access to the BundleContext of the SLF4J bundle. In Gyrex we provide a > native SLF4J implementation which delegates to the OSGi LogService. > > I also don't think that there will be a one-fits-all approach. I could imagine > that there will be native OSGi SLF4J logger which doesn't delegate to the > LogService but which extends SLF4J logger discover to use the OSGi service > registry for discovering logger implementations. This might allow for the > greatest flexibility (eg. switching logger implementations at runtime, maybe > even use different logger implementations per thread/bundle, etc). However, I'm > not sure if such flexibility is necessary for the majority of systems out there > today. > Hi Gunnar and thanks for the update. I believe Ceki's goal is to choose the solution that fits as many as possible so that eclipse and other consumers don't need to re-package slf4j. Here is a fragment that supports pluggable slf4j implementations: http://github.com/hmalphettes/slf4j/tree/osgi-binder/slf4j-api-osgi/src/mai… slf4j implementations would be packaged as bundles and slf4j-api would not import the org.slf4j.impl package. This was done as a small experiment: http://github.com/hmalphettes/slf4j/blob/osgi-binder/README.txt and we agree that pluggable implementations is really not a mainstream production scenario. But managing bundles is certainly nicer than managing fragments so maybe that is a good approach? -- 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

branch, master, updated. v1.5.9.RC1-15-g96aa187
by git-noreply＠pixie.qos.ch 04 Dec '09

04 Dec '09

The branch, master has been updated via 96aa1878e03f1c1600aeb67d62c2d090433f60b5 (commit) from 88c4c456766193e012eb890e2208473d99b91f83 (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=96aa1878e03f1c1600aeb67d62… http://github.com/ceki/slf4j/commit/96aa1878e03f1c1600aeb67d62c2d090433f60b5 commit 96aa1878e03f1c1600aeb67d62c2d090433f60b5 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Dec 4 17:10:57 2009 +0100 added a link to logging in spring diff --git a/slf4j-site/src/site/pages/docs.html b/slf4j-site/src/site/pages/docs.html index c9f2666..83edf49 100644 --- a/slf4j-site/src/site/pages/docs.html +++ b/slf4j-site/src/site/pages/docs.html @@ -89,6 +89,12 @@ Soapbox for SLF4J</a>, by Bruce Snyder </li> + <li> + <a + href="http://blog.springsource.com/2009/12/04/logging-dependencies-in-spring/">Logging + Dependencies in Spring </a> by Dave Syer + </li> + <li><a href="http://sharein.com/shares/111630-a-java-geek-thoughts-on-java-logging-and-s…">Logging: should I wrap?</a> by Chris Wong ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/docs.html | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[Bug 162] New: Group SLF4J maven artifacts by means of group ID
by bugzilla-daemon＠pixie.qos.ch 04 Dec '09

04 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=162 Summary: Group SLF4J maven artifacts by means of group ID Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: chad.lajoie(a)switch.ch Currently, all SLF4J maven artifacts use a single group ID. In order to prevent a user of a maven project from having to go out, download, and grab the appropriate bridge (e.g. slfj4j-log4j13) and adapter (e.g. jcl-over-slf4j) libraries the project developer may wish to include these within the project distribution. Mostly like this would be done by putting the bridge and adapter artifacts in a separate directory, such as with this assembly descriptor fragment: <dependencySet> <outputDirectory>/lib/slf4j-adpater</outputDirectory> <includes> <include>org.slf4j.adapter:*</include> </includes> </dependencySet> Without having the bridge and adapter artifacts registered under separate group IDs, however, this becomes difficult. The project assembly author must specifically include the core artifact and exclude the bridge and adapter artifacts in the main lib directory, include the bridge and exclude the core and adapter artifacts in the bridge library directory, and include the adapter and exclude the core and bridge artifacts from the adapter library directory. Additionally, if any new artifacts are added the assemblies must all be updated as well. Therefore, it would be much simpler and cleaner if the bridge and adapter artifacts were each registered under separate group IDs. Note that starting this with some given release does not break any existing maven project. It just means that when a maven project wants to pull in the new versions they need to update the version and group ID in their POM instead of just the version. -- 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

slf4j artifact groupings
by Chad La Joie 04 Dec '09

04 Dec '09

I use slf4j in a number of projects, some of which are libraries. For the libraries I like to include all the bridge (e.g. slfj4j-log4j13) and adapter (e.g. jcl-over-slf4j) jars with the library distribution so that people downloading the library don't have to then go and grab the slf4j distribution as well. However, from a maven perspective, doing this kind of a pain because there is no way to distinguish between the core slf4j artifacts, the bridge artifacts, and the adapter artifacts. So I would like to recommend change the group ID for the bridge and adapter artifacts to signify which they are. For example, using the group IDs org.slf4j.adapter and org.slf4j.bridge. With this I could create assemblies as followed: <dependencySet> <outputDirectory>/lib/slf4j-adpater</outputDirectory> <includes> <include>org.slf4j.adapter:*</include> </includes> </dependencySet> Does this seem reasonable? -- 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(a)switch.ch, http://www.switch.ch

2 2

[Bug 75] Cyclic dependency in OSGi
by bugzilla-daemon＠pixie.qos.ch 04 Dec '09

04 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=75 Gunnar Wagenknecht <gunnar(a)wagenknecht.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gunnar(a)wagenknecht.org --- Comment #14 from Gunnar Wagenknecht <gunnar(a)wagenknecht.org> 2009-12-04 10:15:26 --- FWIW, in the Eclipse Orbit repository we also provide an SLF4J API bundle. This bundle follows the fragment approach which a small difference. The SLF4J API bundle neither imports nor exports the "impl" package. The "impl" package has to be provided by a fragment. It's also not exported because it's not API. Others (except SLF4J) should not be able to import the "impl" package. BTW, fragments can happily consume services simply by using FrameworkUtil to get access to the BundleContext of the SLF4J bundle. In Gyrex we provide a native SLF4J implementation which delegates to the OSGi LogService. I also don't think that there will be a one-fits-all approach. I could imagine that there will be native OSGi SLF4J logger which doesn't delegate to the LogService but which extends SLF4J logger discover to use the OSGi service registry for discovering logger implementations. This might allow for the greatest flexibility (eg. switching logger implementations at runtime, maybe even use different logger implementations per thread/bundle, etc). However, I'm not sure if such flexibility is necessary for the majority of systems out there today. -- 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