From: Mark R. <ma...@eb...> - 2009-07-03 11:04:40
|
A brief question regarding the JCP applet and logging. I'm starting to get the applet to work in my local IDE (Jdeveloper) but I don't see the debug messages anywhere. The applet uses the CDK LoggingTool, but my question is whether that seems wise. The LoggingTool does not immediately make sense to me - does it require log4j or can it work without it ? If log4j is required, I suppose we should not use it in the applet, because to make it work we'd have to include a log4j.jar file in the distribution. I think I'd personally opt to just use System.out.println(), going straight to the JRE console window. Probably most convenient, also for users to trace bugs. mark. |
From: Egon W. <ego...@gm...> - 2009-07-03 11:16:37
|
Hi Mark, On Thu, Jul 2, 2009 at 12:45 PM, Mark Rijnbeek<ma...@eb...> wrote: > I'm starting to get the applet to work in my local IDE (Jdeveloper) but > I don't see the debug messages anywhere. you need to set the environment variables (params to java): -Dcdk.debugging=true -Dcdk.debug.stdout=true > The applet uses the CDK LoggingTool, but my question is whether that > seems wise. The LoggingTool does not immediately make sense to me - does > it require log4j or can it work without it ? It requires log4j. This has been a choice made a very long time ago, and maybe time to fix this... > If log4j is required, I suppose we should not use it in the applet, > because to make it work we'd have to include a log4j.jar file in the > distribution. I am not sure there is a way around this... the CDK depends on this, quite heavily... But, this is a nice example where we can make the CDK better, driven by JChemPaint needs... > I think I'd personally opt to just use System.out.println(), going > straight to the JRE console window. Probably most convenient, also for > users to trace bugs. I suggest this (major) refactoring in the CDK: 1. replace all use of Logger by an interface ILogger (with the same API) 2. implement ILogger Log4jLogger and SystemOutLogger 3. set up a LoggerFactory to instantiate the Log4jLogger if the log4j library is found, and default to SystemOutLogger if that lib is not found That way, we get: 1. the same behaviour as now for the CDK library 2. allow the applet (or any other application) to not have the log4jar and use STDOUT in that situation (The SystemOut would use System.out and System.err where appropriate) I'll hack up a patch for this now, to make things a bit more concrete... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Christoph S. <ste...@eb...> - 2009-07-03 14:17:42
|
On 3 Jul 2009, at 13:16, Egon Willighagen wrote: > > >> The applet uses the CDK LoggingTool, but my question is whether that >> seems wise. The LoggingTool does not immediately make sense to me - >> does >> it require log4j or can it work without it ? > > It requires log4j. This has been a choice made a very long time ago, > and maybe time to fix this... Agreed. > I suggest this (major) refactoring in the CDK: > > 1. replace all use of Logger by an interface ILogger (with the same > API) > 2. implement ILogger Log4jLogger and SystemOutLogger > 3. set up a LoggerFactory to instantiate the Log4jLogger if the log4j > library is found, > and default to SystemOutLogger if that lib is not found > > That way, we get: > > 1. the same behaviour as now for the CDK library > 2. allow the applet (or any other application) to not have the log4jar > and use STDOUT in that situation > > (The SystemOut would use System.out and System.err where appropriate) > > I'll hack up a patch for this now, to make things a bit more > concrete... Heroic :-) C. -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Janna H. <has...@eb...> - 2009-07-03 16:36:29
|
Hello, isn't that just what Apache commons-logging does? Provide a wrapper which is able to use Log4J if it is available but fall back to simple System.out if it is not? http://commons.apache.org/logging/guide.html (Just joined the mailing list, so forgive me if this covers ground you already covered before...) Janna -----Original Message----- From: Egon Willighagen [mailto:ego...@gm...] Sent: 03 July 2009 12:17 To: cdk...@li...; cdk...@li... Subject: Re: [Cdk-devel] [Cdk-jchempaint] LoggingTool Hi Mark, On Thu, Jul 2, 2009 at 12:45 PM, Mark Rijnbeek<ma...@eb...> wrote: > I'm starting to get the applet to work in my local IDE (Jdeveloper) but > I don't see the debug messages anywhere. you need to set the environment variables (params to java): -Dcdk.debugging=true -Dcdk.debug.stdout=true > The applet uses the CDK LoggingTool, but my question is whether that > seems wise. The LoggingTool does not immediately make sense to me - does > it require log4j or can it work without it ? It requires log4j. This has been a choice made a very long time ago, and maybe time to fix this... > If log4j is required, I suppose we should not use it in the applet, > because to make it work we'd have to include a log4j.jar file in the > distribution. I am not sure there is a way around this... the CDK depends on this, quite heavily... But, this is a nice example where we can make the CDK better, driven by JChemPaint needs... > I think I'd personally opt to just use System.out.println(), going > straight to the JRE console window. Probably most convenient, also for > users to trace bugs. I suggest this (major) refactoring in the CDK: 1. replace all use of Logger by an interface ILogger (with the same API) 2. implement ILogger Log4jLogger and SystemOutLogger 3. set up a LoggerFactory to instantiate the Log4jLogger if the log4j library is found, and default to SystemOutLogger if that lib is not found That way, we get: 1. the same behaviour as now for the CDK library 2. allow the applet (or any other application) to not have the log4jar and use STDOUT in that situation (The SystemOut would use System.out and System.err where appropriate) I'll hack up a patch for this now, to make things a bit more concrete... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ ---------------------------------------------------------------------------- -- _______________________________________________ Cdk-devel mailing list Cdk...@li... https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: Egon W. <ego...@gm...> - 2009-07-03 16:50:51
|
On Fri, Jul 3, 2009 at 3:52 PM, Janna Hastings<has...@eb...> wrote: > isn't that just what Apache commons-logging does? Provide a wrapper which is > able to use Log4J if it is available but fall back to simple System.out if > it is not? The thing is, we do not want to depend on commons-logging for this. Besides we do not really want to ship the log4j library with the applet, we actually really do not want it, because we have been neglecting the fact for the past 10-ish years, that the Apache license is actually incompatible with the LGPL... it's a pretty loose dependency, which the upcoming fix will formalize in more detail... > (Just joined the mailing list, so forgive me if this covers ground you > already covered before...) No worries... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Janna H. <has...@eb...> - 2009-07-06 15:44:34
|
Ah - now I get it, pesky licenses :-) Janna -----Original Message----- From: Egon Willighagen [mailto:ego...@gm...] Sent: 03 July 2009 17:51 To: Developers forum for discussion about the Chemistry Development Kit(CDK) Cc: cdk...@li...; cdk...@li... Subject: Re: [Cdk-devel] [Cdk-jchempaint] LoggingTool On Fri, Jul 3, 2009 at 3:52 PM, Janna Hastings<has...@eb...> wrote: > isn't that just what Apache commons-logging does? Provide a wrapper which is > able to use Log4J if it is available but fall back to simple System.out if > it is not? The thing is, we do not want to depend on commons-logging for this. Besides we do not really want to ship the log4j library with the applet, we actually really do not want it, because we have been neglecting the fact for the past 10-ish years, that the Apache license is actually incompatible with the LGPL... it's a pretty loose dependency, which the upcoming fix will formalize in more detail... > (Just joined the mailing list, so forgive me if this covers ground you > already covered before...) No worries... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ ---------------------------------------------------------------------------- -- _______________________________________________ Cdk-devel mailing list Cdk...@li... https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: Egon W. <ego...@gm...> - 2009-07-04 17:41:29
|
Hi all, I have uploaded a patch at: http://sourceforge.net/tracker/?func=detail&aid=2816660&group_id=20024&atid=320024 On Fri, Jul 3, 2009 at 1:16 PM, Egon Willighagen<ego...@gm...> wrote: > I suggest this (major) refactoring in the CDK: > > 1. replace all use of Logger by an interface ILogger (with the same API) ILoggingTool > 2. implement ILogger Log4jLogger and SystemOutLogger LoggingTool and SystemOutLoggingTool respectively. > 3. set up a LoggerFactory to instantiate the Log4jLogger if the log4j > library is found, > and default to SystemOutLogger if that lib is not found Available in the LoggingToolFactory. Additionally, it allows setting a custom ILoggingTool implementation Class, to allow other logger frameworks. Please give it a go, give comments, do a formal review, etc. Looking forward to your experiences! Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Mark R. <ma...@eb...> - 2009-07-06 09:37:53
|
hi Egon thanks for coming up with a solution promptly. I tried to apply the patches with "git am" but that didn' work, so instead I applied them individually with "git apply". Perhaps there's something wrong with the tar file, it didn't want to unpack: bash-3.00$ tar -xvf iloggingpatch/iloggingtool.patch.tar tar: This does not look like a tar archive tar: Skipping to next header tar: Error exit delayed from previous errors Is "git am" not supposed to be applied to an .mbox file? I just kept getting error below. "previous rebase directory /home/markr/git/cdk/.git/rebase-apply still exists but mbox given." Anyway, the patches individually succeed. I'd like to use the new logger set up for Jchempaint. But I think for the Jchempaint applet SVN is still used rather than git.. could I apply your logging patch to jchempaint-primary and commit it? And then from there on use it in the applet.. or is there a better way of doing this? thanks, Mark > Hi all, > > I have uploaded a patch at: > > http://sourceforge.net/tracker/?func=detail&aid=2816660&group_id=20024&atid=320024 > > On Fri, Jul 3, 2009 at 1:16 PM, Egon > Willighagen<ego...@gm...> wrote: > >> I suggest this (major) refactoring in the CDK: >> >> 1. replace all use of Logger by an interface ILogger (with the same API) >> > > ILoggingTool > > >> 2. implement ILogger Log4jLogger and SystemOutLogger >> > > LoggingTool and SystemOutLoggingTool respectively. > > >> 3. set up a LoggerFactory to instantiate the Log4jLogger if the log4j >> library is found, >> and default to SystemOutLogger if that lib is not found >> > > Available in the LoggingToolFactory. > > Additionally, it allows setting a custom ILoggingTool implementation > Class, to allow other logger frameworks. > > Please give it a go, give comments, do a formal review, etc. > > Looking forward to your experiences! > > Egon > > > |
From: Egon W. <ego...@gm...> - 2009-07-06 09:47:38
|
On Mon, Jul 6, 2009 at 12:37 PM, Mark Rijnbeek<ma...@eb...> wrote: > thanks for coming up with a solution promptly. I tried to apply the > patches with "git am" but that didn' work, so instead I applied them > individually with "git apply". > Perhaps there's something wrong with the tar file, it didn't want to unpack: > > bash-3.00$ tar -xvf iloggingpatch/iloggingtool.patch.tar > tar: This does not look like a tar archive > tar: Skipping to next header > tar: Error exit delayed from previous errors Please find attached. I hope that one is OK. > Is "git am" not supposed to be applied to an .mbox file? I just kept > getting error below. > "previous rebase directory /home/markr/git/cdk/.git/rebase-apply still > exists but mbox given." > > Anyway, the patches individually succeed. How did you do that, if the tar did not untar? > I'd like to use the new logger set up for Jchempaint. But I think for > the Jchempaint applet SVN is still used rather than git.. could I apply > your logging patch to jchempaint-primary and commit it? yes, go ahead. > And then from there on use it in the applet.. or is there a better way > of doing this? Yes, if you use git-svn, then you can make a local working branch, from which you create applets, which makes it easier to rebase the jchempaint-primary branch on top of master, which I'll finish this week... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Egon W. <ego...@gm...> - 2009-07-06 09:48:18
Attachments:
iloggingtool.patch.tar.gz
|
On Mon, Jul 6, 2009 at 11:47 AM, Egon Willighagen<ego...@gm...> wrote: > On Mon, Jul 6, 2009 at 12:37 PM, Mark Rijnbeek<ma...@eb...> wrote: > Please find attached. I hope that one is OK. And here it really is. Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Mark R. <ma...@eb...> - 2009-07-06 11:22:49
|
>> Anyway, the patches individually succeed. >> > > How did you do that, if the tar did not untar? > Somehow Konqueror could access the content of the tar file. Weird Linux hickup I think. |
From: Mark R. <ma...@eb...> - 2009-07-06 13:26:53
|
>> And then from there on use it in the applet.. or is there a better way >> of doing this? >> > > Yes, if you use git-svn, then you can make a local working branch, > from which you create applets, which makes it easier to rebase the > jchempaint-primary branch on top of master, which I'll finish this > week... > > Sorry lost you there. The option git-svn is new to me.. how would you suggest we develop the applet ideally, with regards to the version control set up ? So right now for the applet we use "cdk.svn.sourceforge.net/svnroot/cdk/jchempaint/" , and the shared source is in " cdk.svn.sourceforge.net/svnroot/cdk/cdk/branches/jchempaint-primary/" right? Is SVN jchempaint-primary always up-to-date, or are you primarily working with git ( http://pele.farmbio.uu.se/nightly-jcp/ ) ? Mark |
From: Egon W. <ego...@gm...> - 2009-07-06 13:41:48
|
Hi Mark, On Mon, Jul 6, 2009 at 3:24 PM, Mark Rijnbeek<ma...@eb...> wrote: >> Yes, if you use git-svn, then you can make a local working branch, >> from which you create applets, which makes it easier to rebase the >> jchempaint-primary branch on top of master, which I'll finish this >> week... >> > Sorry lost you there. The option git-svn is new to me.. how would you > suggest we develop the applet ideally, with regards to the version > control set up ? > > So right now for the applet we use > "cdk.svn.sourceforge.net/svnroot/cdk/jchempaint/" , and the shared > source is in " > cdk.svn.sourceforge.net/svnroot/cdk/cdk/branches/jchempaint-primary/" right? > Is SVN jchempaint-primary always up-to-date, or are you primarily > working with git ( http://pele.farmbio.uu.se/nightly-jcp/ ) ? Git-svn is a Git frontend to a SVN repository, bringing some git features to the SVN world... cdk.svn.sourceforge.net/svnroot/cdk/cdk/branches/jchempaint-primary/ is my primary resource indeed. However, with git-svn I get a git checkout of the SVN version, allowing me to easily move around stuff, etc... Shortly, I will set up a git mirror of this, where I'll do the patch reordering... this one will also be branching from CDK master from the git repository on SF. But, for now, SVN is what we use on SF for the jcp-primary repository... On how to set up a git-svn for a SVN repository, see my blog: http://chem-bla-ics.blogspot.com/2008/09/cdk-development-with-branches-using-git.html The Nightly instance running on Pele is also working with the SVN repository. If you would set up this git-svn, you could easily branch jchempaint-primary and set up a jchempaint-applet-release branch, where you would apply the iloggingtool patch. You could then keep it updated with jchempaint-primary with: git svn fetch git checkout jchempaint-applet-release git rebase local-jchempaint-primary (assuming your local copy of the remote SVN jchempaint-primary branch) Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |