From: Alef A. <al...@jt...> - 2005-02-28 09:20:11
|
It still fails: java.lang.IllegalArgumentException: Invalid 'log4jConfigLocation' parameter: Log4J config file [/jteam/build2/checkout/spring/spring/jteam/build2/checkout/spring/sprin g/target/test-classes/org/springframework/util/testlog4j.properties] not found at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConf igurer.java:153) at org.springframework.web.util.Log4jWebConfigurerTests.doTestInitLogging(L og4jWebConfigurerTests.java:78) at org.springframework.web.util.Log4jWebConfigurerTests.testInitLoggingWith AbsoluteFilePathAndRefreshInterval(Log4jWebConfigurerTests.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) I don't have time to look at this today. My local copy is up-to-date, although it's not the dev-cvs but the public one (not sychronized yet?). Alef =20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Sunday, February 27, 2005 11:01 PM To: spr...@li... Subject: Re: [Springframework-developer] FAILED BUILD: sparc-solaris1 (last30 lines included) I've commented out that test case. It doesn't go through FileSystemResourceLoader, so that check doesn't apply. But there seems to be some difference in the URL that Class.getResource returns, so it's probably best to simply drop that test. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Darren Davison Sent: Wednesday, February 23, 2005 10:09 AM To: spr...@li... Subject: Re: [Springframework-developer] FAILED BUILD: sparc-solaris1 (last30 lines included) On Wed, 2005-02-23 at 07:52 +0000, Darren Davison wrote: > On Tue, 2005-02-22 at 16:39 -0800, Darren Davison wrote: > > [/home/users/d/da/davison/checkouts/spring/home/users/d/da/davison/check outs /spring/target/sparc-solaris1/test-classes/org/springframework/util/test log4 j.properties] > > obviously some problem with absolute/relative path names in here -=20 > this will presumably fail on all of the build machines. I haven't=20 > looked at it - is the problem specific to Unix or does it fail the=20 > same way on 'Doze? I don't see how FileSystemResourceLoader can ever return an absolute file path (at least on unix filesystems) as required by the testInitLoggingWithAbsoluteFilePathAndRefreshInterval test since it deliberately strips a leading / thereby always making the path relative. protected Resource getResourceByPath(String path) { if (path !=3D null && path.startsWith("/")) { path =3D path.substring(1); } return new FileSystemResource(path); } Am I missing something? -- Darren Davison Public Key: #DD356B0D ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |