[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-04-01 Thread Vitali Lovich
I think the issue is something to do with me using incubator it instantiating the RemoteLoggingService even though I don't use it. It might be due to the way incubator initializes the logger (using java's Logger.getLogger() whereas I use log4j directly). On Fri, Mar 27, 2009 at 11:57 AM, Scott

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-26 Thread Vitali Lovich
On Thu, Mar 26, 2009 at 3:17 PM, Scott Blum sco...@google.com wrote: Vitali, are you positive all your stuff is in a legit state? I ask because it looks like you're mixing trunk and 1.6 stuff together. Can you clarify what you mean? How can I be mixing trunk 1.6 together? I'm only using

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Toby Reyelts
Overall, the change to treat server classes vs system classes separately, such that system classes are API classes and server classes are implementation classes looks good. I'm concerned that there will still be places where things will clash - such as the sharing of log4j across both server and

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Vitali Lovich
This didn't fix my log4j issue, but there's a workaround: adding -Dlog4j.ignoreTCL to the VM arguments fixes it. On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts to...@google.com wrote: Overall, the change to treat server classes vs system classes separately, such that system classes are API

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Scott Blum
Thanks for the feedback, Toby. As Toby said, this code is less than clear-cut, and I don't feel totally comfortable about it. But I think the best decision is to mirror Jetty's behavior as closely as possible, because it's likely to be the least surprising. In other words, lots of people have

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Scott Blum
Vitali, can you remind me what your issue is? On Wed, Mar 25, 2009 at 4:10 PM, Vitali Lovich vlov...@gmail.com wrote: This didn't fix my log4j issue, but there's a workaround: adding -Dlog4j.ignoreTCL to the VM arguments fixes it. On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Vitali Lovich
og4j:ERROR A org.apache.log4j.ConsoleAppender object is not assignable to a org.apache.log4j.Appender variable. log4j:ERROR The class org.apache.log4j.Appender was loaded by log4j:ERROR [sun.misc.launcher$appclassloa...@64601bb1] whereas object of type log4j:ERROR org.apache.log4j.ConsoleAppender

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Scott Blum
Hmm, but GWT doesn't use log4j internally. Is it possible you've got conflicting versions, one on the system classpath and one in your war directory? On Wed, Mar 25, 2009 at 4:40 PM, Vitali Lovich vlov...@gmail.com wrote: og4j:ERROR A org.apache.log4j.ConsoleAppender object is not assignable

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Vitali Lovich
I think I found the problem. If I don't put the log4j file into my WEB-INF/lib directory, then it's fine. If it is put there, then it gets the conflicting version (regardless of whether or not I launch HostedMode with log4j on the class path). So am I doing it wrong? Am I supposed to place it

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

2009-03-25 Thread Vitali Lovich
On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum sco...@google.com wrote: On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich vlov...@gmail.com wrote: If I don't put the log4j file into my WEB-INF/lib directory, then it's fine. If it is put there, then it gets the conflicting version (regardless of