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
Okay, I think the issue might be your using trunk then. My patch jar was
for 1.6, and the commit you're commenting on here (r5077 & r5078) were to
1.6. So I would not expect that to be fixed in trunk.
On Thu, Mar 26, 2009 at 9:50 PM, Vitali Lovich wrote:
>
>
> On Thu, Mar 26, 2009 at 3:17 PM,
On Thu, Mar 26, 2009 at 3:17 PM, Scott Blum 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 trunk. At this p
On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum wrote:
> On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich 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 whether or not I launch Host
On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich 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 whether or not I launch HostedMode with log4j on the class path). So am
> I doing it w
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 e
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 wrote:
> og4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to
> a "org.apac
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.ConsoleApp
Vitali, can you remind me what your issue is?
On Wed, Mar 25, 2009 at 4:10 PM, Vitali Lovich 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 wrote:
>
>> Overall, the c
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 use
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 wrote:
> Overall, the change to treat server classes vs system classes separately,
> such that system classes are "API classes" and serv
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 a
12 matches
Mail list logo
