Did you make any progress on this?
Ralph
On Oct 23, 2012, at 1:21 PM, Peter J. DePasquale wrote:
Debugging on the train it's in the name of the class More later
Ralph Goers ralph.go...@dslextreme.com wrote:
BTW - I just want to make sure that you are aware that instead of
Thanks for the update. Please let me know if I can be of assistance.
Ralph
On Oct 29, 2012, at 7:46 PM, Peter DePasquale wrote:
I have some theories. Unfortunately, I've had to travel to Rhode Island for
two talks that didn't occur because of the hurricane. Now that I'm stranded
here I'm
I'm happy to update you once I know perfectly what I think is
happening. At that point I might have something more concrete you can
use to confirm the problem. I'll I forgot to mention, that when the
configuration file is missing from the jar file and the naming
conflict occurs that's when I'm
So I was able to download this and replicate your results.
I've adjusted my logger config to account for other classes in a
different package (org.comtor rather than org.comtor.drivers) and that
works. Thus, my issue apparently is specific to this particular one
class. Debugging continues as I
That is good to know. However, your test has spawned a suspicion that the
problem may be related to one class starting with the name of the other. Try
renaming Comtor or ComtorStandAlone so they don't overlap and see if the
problem goes away. If it does then it is a bug in Log4j.
I'll try
OK - I tried my theory and didn't have any problems.
Ralph
On Oct 23, 2012, at 10:59 AM, Ralph Goers wrote:
That is good to know. However, your test has spawned a suspicion that the
problem may be related to one class starting with the name of the other. Try
renaming Comtor or
OK, I'll try as you suggested when I can... I'm leaving to head to a
talk at Google in NYC, so this may not happen for a day or two...
trying to avoid shipping you code, but if we have to I will.
Thanks for the help!
On Tue, Oct 23, 2012 at 2:36 PM, Ralph Goers ralph.go...@dslextreme.com wrote:
BTW - I just want to make sure that you are aware that instead of unzipping all
your jars and rezipping into one new jar that another alternative you have is
to just place all the jars in one directory. Then, instead of placing the
log4j jars in lib/ext or combining them with your classes you
No more unzipping/rejarring. Will try to see utility there is a difference in
behavior when they are in the same base dir.
Ralph Goers ralph.go...@dslextreme.com wrote:
BTW - I just want to make sure that you are aware that instead of
unzipping all your jars and rezipping into one new jar that
Debugging on the train it's in the name of the class More later
Ralph Goers ralph.go...@dslextreme.com wrote:
BTW - I just want to make sure that you are aware that instead of
unzipping all your jars and rezipping into one new jar that another
alternative you have is to just place
Try invoking java with -Dlog4j.debug. That should tell you something.
It sounds like it's picking up a different config file from somewhere.
On Mon, 2012-10-22 at 22:44 -0400, Peter DePasquale wrote:
Yep, both in one jar (mine), with the two log4j2 jars in the /lib/ext
area. Will have to
That setting will have no effect in Log4j 2.
Ralph
On Oct 22, 2012, at 8:51 PM, Tim Watts wrote:
Try invoking java with -Dlog4j.debug. That should tell you something.
It sounds like it's picking up a different config file from somewhere.
On Mon, 2012-10-22 at 22:44 -0400, Peter
OK - I haven't tried installing into lib/ext. I will see if I can create a
couple of classes to emulate what you are describing until you can get me a
zip. I assume one or both of these has a main? Where did you place log4j2.xml?
Ralph
On Oct 22, 2012, at 7:44 PM, Peter DePasquale wrote:
13 matches
Mail list logo
