August 2010 - slf4j-dev - mailman3.qos.ch

Fwd: slf4j on the google android platform
by Darrin Edelman 24 Aug '10

24 Aug '10

Darn... I forgot that 'system' scope assumes the jar will be provided on the target platform which in the case of slf4j of course it is note. So I've added a maven snippet that will auto-install the jar included in source code control so you can use maven without manual steps for the build in this case... -Darrin > > On Aug 24, 2010, at 10:16 AM, Darrin Edelman wrote: > >> Thank you - >> >> Comments below for those who follow... >> >> Anyway - I'm back up and going on the official version - thanks much for your help!! >> >> -Darrin >> >> On Aug 24, 2010, at 8:43 AM, Thorsten Möller wrote: >> >>> On Tuesday, August 24, 2010 3:05 PM [GMT+1=CET], >>> Darrin Edelman <darrin501(a)gmail.com> wrote (with possible deletions): >>> >>>> What of the other two points below : >>>> 2. Where is this sourcecode? Am I missing this in Git somehow? >>> [1], folder slf4j-android >>> >> Yes - I was able to git this with: >> >> Also - I had to make a change to the pom.xml because for whatever reason my android sdk had a different structure: >> >> --- a/slf4j-android/pom.xml >> +++ b/slf4j-android/pom.xml >> @@ -83,7 +83,7 @@ >> <artifactId>android</artifactId> >> <version>1.5</version> >> <scope>system</scope> >> - <systemPath>${env.ANDROID_HOME}/platforms/android-1.5/android.jar</systemPath> >> + <systemPath>${env.ANDROID_HOME}/platforms/android-3/android.jar</systemPath> >> </dependency> >> </dependencies> >> >> FYI - I believe you can now use a publicly available android jar instead of including the jar within git using something like this: >> <dependency> >> <groupId>com.google.android</groupId> >> <artifactId>android</artifactId> >> <version>1.5_r4</version> >> <scope>system</scope> >> </dependency> >> >> Note that this would require a change to the imports from 'android.utils.log' to 'com.google.android.utils.log' which is how it should be... >> >>> >>>> 3. Are there plans to get slf4j-android into a maven repo? >>> Not of high priority. However, since the project is already managed >>> using Maven, it shouldn't be that complicated to check out the code and >>> build and install it in your local repo. Note that I also refuse to >>> upload it unless #173 is fixed. Together with this we intend to upgrade >>> the code basis to SLF4J 1.6.1 as well. >>> >> True - but the main issue here is that I don't want members of my team to have to go through this process (understand and download slf4j-android, build, install) in order to build our application - also it makes it a bit more painful for continuous integration. Making it available to the community means that it'll be that much easier to use slf4j as the logger of choice for an android app (for those who are using maven with android anyway). >> >> That said - what I'm doing as a workaround to make builds work for my team and our CI server until this happens is what you did above for the android.jar (which also wasn't originally available). I'm putting it the jar into source code control under my project's lib directory and added it as a 'system' maven dependency: >> >> <dependency> >> <groupId>org.slf4j</groupId> >> <artifactId>slf4j-android</artifactId> >> <version>1.5.8</version> >> <scope>system</scope> >> <systemPath>${basedir}/lib/slf4j-android-1.5.8.jar</systemPath> >> </dependency> >> > > Yeah - this won't work here... two modifications needed: > > 1. remove the 'system' scope and 'systemPath' from the dependency above - that dependency should now look like this: > > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-android</artifactId> > <version>1.5.8</version> > </dependency> > > 2. add the maven-install-plugin to the 'plugins' section: > > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-install-plugin</artifactId> > <executions> > <execution> > <id>install-slf4j-android-jar</id> > <phase>validate</phase> > <configuration> > <file>${basedir}/lib/slf4j-android-1.5.8.jar</file> > <repositoryLayout>default</repositoryLayout> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-android</artifactId> > <version>1.5.8</version> > <packaging>jar</packaging> > <generatePom>true</generatePom> > </configuration> > <goals> > <goal>install-file</goal> > </goals> > </execution> > </executions> > </plugin> > > I needed to run 'mvn clean package' and reload eclipse before it was happy (needs to do the initial install). > >> When you have it publicly available I can remove this from my repo and reference the officially available jar. >> >> >>> @Ceki: What would be required in order to publish the artifacts to Maven >>> central - I never did this. >>> >>> Cheers, >>> Thorsten >>> >>> [1] http://github.com/twwwt/slf4j >>> >>> >>> >>>> Thanks, >>>> -Darrin >>>> >>>> I didn't see this in the android code base - have I missed something? >>>> What On Aug 24, 2010, at 4:52 AM, Thorsten Möller wrote: >>>> >>>>> On Monday, August 23, 2010 10:51 PM [GMT+1=CET], >>>>> Darrin Edelman <darrin501(a)gmail.com> wrote (with possible deletions): >>>>> >>>>>> I did get slf4j-android working after going through the list here by >>>>>> grabbing the source code and patching it myself but I'm wondering if >>>>>> progress has been made on the issues below so that I can adopt a >>>>>> more official release? >>>>> The repository [1] contains a fix which simply truncates names longer >>>>> than 23 characters at the right-hand side. This fix is considered a >>>>> temporary solution and it is intended to eventually come up either >>>>> with the solution proposed in comment #10 [2], or with the following >>>>> solution (inspired by Eclipse IDE which has a similar function): >>>>> >>>>> tag = a.package.name.longer.than.twentythree.characters.MyClass >>>>> >>>>> would be shortened to >>>>> >>>>> tag = a.p*.n*.l*.t*.t*.c*.MyClass >>>>> >>>>> If tag would still be longer than 23 characters (e.g. long class >>>>> name, deep hierarchy, or no dots at all), then one could further >>>>> shorten it to >>>>> >>>>> tag = *TrailOfLongClassName >>>>> >>>>> >>>>> Feedback welcome as well as patches. I suggest to continue the >>>>> discussion via Bugzilla directly on the issue. >>>>> >>>>> >>>>> Cheers, >>>>> Thorsten >>>>> >>>>> >>>>> [1] http://github.com/twwwt/slf4j >>>>> [2] http://bugzilla.slf4j.org/show_bug.cgi?id=173#c10 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks in advance, >>>>>> -Darrin >>>>>> >>>>>>>> >>>>>>>> I've run into a couple frustrating issues with slf4j-android >>>>>>>> that you're no doubt aware of as it seems that some work has >>>>>>>> occurred >>>>>>>> here: >>>>>>>> >>>>>>>> 1) http://bugzilla.slf4j.org/show_bug.cgi?id=173 >>>>>>>> >>>>>>>> Given that I'm dealing with a cross-platform library with lots of >>>>>>>> existing code the '23 character' android limit is a showstopper >>>>>>>> for me. I cannot change all the library code to use 'simplename' >>>>>>>> for example. Granted I see this as really an issue with Android >>>>>>>> - but still we should be able to handle this in the android port. >>>>>>>> This means that I cannot just handle it in the android specific >>>>>>>> portions of the code - the already written libraries have to >>>>>>>> properly deal with this issue by cropping the name of the logger >>>>>>>> - so that the library functions don't throw exceptions. This to >>>>>>>> me means that I need to change the StaticLoggerBinder to >>>>>>>> instantiate a version of code that knows how to deal with this >>>>>>>> issue properly even when the client code isn't aware of it. >>>>>>>> Wendel's solution in the above thread >>>>>>>> seems a reasonable solution. >>>>>>>> >>>>>>>> 2) Availability of android source-code from repo. >>>>>>>> >>>>>>>> Given that this is an for me issue I'd like to put the fix in that >>>>>>>> wendell suggest... use as much of the useful name as possible and >>>>>>>> hopefully >>>>>>>> Android comes around and fixes this limitation someday. I >>>>>>>> grabbed the codebase from git and I couldn't find references to >>>>>>>> the android branch. Specifically it seems like wendell's fix is >>>>>>>> a decent work-around for the android limitation. Unfortunately I >>>>>>>> cannot easily do this and contribute any branches back to the >>>>>>>> open source community because I cannot seem to find android code >>>>>>>> in this branch. Now >>>>>>>> this said - I did find the slf4j-android code base on the website >>>>>>>> so I can move forward... but why isn't this in Git?? >>>>>>>> >>>>>>>> 3) Really just a picky thing... slf4j-android does not appear to >>>>>>>> be available from any publicly accessible maven repository. >>>>>>>> >>>>>>>> I've resolved this by adding the jar to my project and >>>>>>>> automatically deploying it to the local repo - but this really >>>>>>>> isn't a very elegant solution. Any chance the android version is >>>>>>>> going to be made available anytime soon? I'd rather not package >>>>>>>> the jar as a build >>>>>>>> artifact. >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> slf4j-dev mailing list >>>>>> slf4j-dev(a)qos.ch >>>>>> http://qos.ch/mailman/listinfo/slf4j-dev >>>>> >>>>> _______________________________________________ >>>>> slf4j-dev mailing list >>>>> slf4j-dev(a)qos.ch >>>>> http://qos.ch/mailman/listinfo/slf4j-dev >>>> >>>> _______________________________________________ >>>> slf4j-dev mailing list >>>> slf4j-dev(a)qos.ch >>>> http://qos.ch/mailman/listinfo/slf4j-dev >>> >>> _______________________________________________ >>> slf4j-dev mailing list >>> slf4j-dev(a)qos.ch >>> http://qos.ch/mailman/listinfo/slf4j-dev >> >

1 0

[Bug 110] Create a bridge between System.out/System.err and SLF4J
by bugzilla-daemon＠pixie.qos.ch 16 Aug '10

16 Aug '10

http://bugzilla.slf4j.org/show_bug.cgi?id=110 --- Comment #11 from Ceki Gulcu <listid(a)qos.ch> 2010-08-16 10:09:05 --- Hi Robert, My apologies for not pursuing this item. Given my other engagements, it fell off my radar. Publishing it independently of SLF4J seems like the best option. However, I'll make sure that the slf4j web-site links to the location where you decide to publish this extension. Again, I am sorry about not giving the system.out bridge the attention it merits. -- 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 110] Create a bridge between System.out/System.err and SLF4J
by bugzilla-daemon＠pixie.qos.ch 16 Aug '10

16 Aug '10

http://bugzilla.slf4j.org/show_bug.cgi?id=110 --- Comment #10 from Robert Elliot <robert(a)teviotia.co.uk> 2010-08-16 10:02:24 --- Hi Ceki - have you had a chance to take a look at this? Could you let me know if you don't feel it's something you want released as part of SLF4J, as if so I'll look at releasing it other ways. -- 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 196] New: incompatible with ReportNG
by bugzilla-daemon＠pixie.qos.ch 13 Aug '10

13 Aug '10

http://bugzilla.slf4j.org/show_bug.cgi?id=196 Summary: incompatible with ReportNG Product: SLF4J Version: 1.6.x Platform: All URL: http://reportng.uncommons.org/ OS/Version: All Status: NEW Severity: normal Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: ryo.away(a)gmail.com When attempting to use log4j-over-slf4j to supply the log4j dependency to Apache ReportNG, failure occurs because org.apache.log4j.Category does not implement setAdditivity(). -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[Bug 195] New: TimInstrumentStatus should be public
by bugzilla-daemon＠pixie.qos.ch 12 Aug '10

12 Aug '10

http://bugzilla.slf4j.org/show_bug.cgi?id=195 Summary: TimInstrumentStatus should be public Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: robert.huffman(a)gmail.com TimeInstrumentStatus is package protected. Therefore, it is impossible to implement an interface of TimeInstrument that is not in org.slf4j.profiler. -- 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 194] New: log4j-over-slf4j checks circular dependency too strict
by bugzilla-daemon＠pixie.qos.ch 10 Aug '10

10 Aug '10

http://bugzilla.slf4j.org/show_bug.cgi?id=194 Summary: log4j-over-slf4j checks circular dependency too strict Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: Tom.SH.Liu(a)morganstanley.com Hi guys, I think log4j-over-slf4j (as well as jcl bridges) checks circular dependency too strict. Even when slf4j-log4j12.jar is visible, it does not necessarily mean it will be picked up by slf4j-api as the logging backend. Here is a setup in tomcat 6 demonstrate the issue: tomcat container lib contains: jcl-over-slf4j.jar, slf4j-api.jar, slf4j-log4j12.jar, log4j.jar Webapp WEB-INF/lib contains: log4j.jar, log4j-over-slf4j.jar, slf4j-api.jar, logback-core.jar, logback-access.jar. What we want to achieve is that tomcat logging (from commons-logging) will be routed to log4j and webapp's logging (from log4j) will be routed to logback. In theory, there will be no circular dependencies in runtime as logback is picked up as the logging backend. However, webapp failed to start because the "potential" circular dependency is detected. Is it possible to change the circular dependency detection algorithm to test against the actual binding picked up? I did a hack on org.apache.log4j.Log4jLoggerFactory which works for me: class Log4jLoggerFactory { ... static { LoggerFactoryBinder binder = StaticLoggerBinder.getSingleton(); if ("org.slf4j.impl.Log4jLoggerFactory".equals(binder.getLoggerFactoryClassStr())) { String part1 = "Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path, preempting StackOverflowError. REPLACED "; String part2 = "See also " + LOG4J_DELEGATION_LOOP_URL + " for more details."; Util.reportFailure(part1); Util.reportFailure(part2); throw new IllegalStateException(part1 + part2); } } ... } Thanks, Tom -- 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 10 Aug '10

10 Aug '10

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #86 from Joern Huxhorn <joern(a)huxhorn.de> 2010-08-10 08:46:04 --- FYI, that's the way commons-lang is switching to a Java-5-only version of their library: http://java.dzone.com/articles/first-look-at-commons-lang-3 -- 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 193] New: Provide a means to redirect the OutputStream content to a logger
by bugzilla-daemon＠pixie.qos.ch 09 Aug '10

09 Aug '10

http://bugzilla.slf4j.org/show_bug.cgi?id=193 Summary: Provide a means to redirect the OutputStream content to a logger Product: SLF4J Version: unspecified Platform: All URL: http://marc.info/?l=slf4j-user&m=123791500221611&w=2 OS/Version: All Status: NEW Severity: enhancement Priority: P1 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: olivier.cailloux(a)ecp.fr Following the discussion in thread "Redirecting Outputstream to the logger" on the slf4j-user ML, and the suggestion to enter a bug report to SLF4J [ http://marc.info/?l=slf4j-user&m=123792097632700&w=2 ]. As mentioned in http://jira.qos.ch/browse/LBCLASSIC-118 : It would be nice to have some util class / convinience method to send the content of an outputstream to an logger. Somehow it should be possible - to keep the outputstream "in a whole" - to define the loglevel . I think such feature would be very useful and add value to SLF4J. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1