Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of jason.burrows@gmail.com
 designates 64.233.184.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=c922GT5F3iNCa/EaqyZ5bYhrccEO51PydA3ICXqRHKr/TSPOp2gC0ELHX6NxY2SImatlE+zCAcYxdcVG36g0u+6OC04e90mpgHox7qzl+LiFjr9mgpINqI6pRv15VRR2pgbmErxOswDZyynbMS2kIvVJ4katgxDXHnrMK7EvqB0=
Message-ID: <a60532960506211606413fefce@mail.gmail.com>
Date: Tue, 21 Jun 2005 16:06:44 -0700
From: Jason Burrows <jason.burrows@gmail.com>
Reply-To: Jason Burrows <jason.burrows@gmail.com>
To: skitching@apache.org
Subject: Re: [logging] Always get a LogConfigurationException...
Cc: commons-user@jakarta.apache.org
In-Reply-To: <a6053296050621124663779a08@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <a605329605062017547ceb608a@mail.gmail.com>
	 <1119316278.3785.36.camel@localhost.localdomain>
	 <a60532960506210925662d55dc@mail.gmail.com>
	 <a6053296050621124663779a08@mail.gmail.com>

So I can also run this test correctly (without the commons-logging
source, just using the jar file) if I run it directly from the command
line, and not from within eclipse.  Everything else works fine from
within Eclipse (using tons of things - including other parts of the
commons collection).

Can anyone think of any reason I'd be getting my problem only when
running from within Eclipse?  I can be sure that I'm using the same
jvm in either case (made sure by fully qualifying the path to java.exe
when testing from the command line).


On 6/21/05, Jason Burrows <jason.burrows@gmail.com> wrote:
> If I import the source directly into my project then I don't get this
> issue for my simple test (which makes it really hard to debug), but
> this isn't a reasonable solution for the real project I am working on.
>=20
> Does that information help at all?  I can't really think of any good
> reason why this would be the case, unless there is some problem using
> the binaries with Java 5?
>=20
> Thanks
> Jason
>=20
>=20
> On 6/21/05, Jason Burrows <jason.burrows@gmail.com> wrote:
> > > It would appear that the problem originates with ling 374 of
> > > LogFactoryImpl (release 1.0.4) which is this:
> > >     logInterface =3D this.getClass().getClassLoader().loadClass
> > >          (LOG_INTERFACE);
> > >
> > > As "this" cannot be null, and neither can this.getClass(), I would gu=
ess
> > > that getClassLoader is returning null.
> > >
> > > But that should only ever happen in JVM1.1, or in embedded systems wh=
ere
> > > everything is being loaded via the bootclassloader.
> > >
> > > You aren't developing an embedded system are you?
> > >
> >
> > No - not an embedded system.  Just running with JDK 1.5.0 with nothing
> > special or interesting being done to it.  In fact, if I add a test to
> > check that out:
> >
> > if ( this.getClass().getClassLoader() =3D=3D null){...} else {...}
> >
> > I can see that getClassLoader is not returning null (for my test class =
anyway).
> >
> > Thanks
> > Jason
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org