Hmm...   that one I have NO idea and cannot reproduce.  :-(

I even upgrade my JDK from _13 to _15, re-checked out a clean 2.0.4 tree, 
etc... and cannot reproduce it.   Not sure what could be going on.   
Looking at that line in the code, it's just checking the soap action 
that was read from the wsdl.   Thus, the only thing I can think of is if 
a different /wsd/hello_world.wsdl file is being picked up, but that 
shouldn't be the case.   

Dan




On Thursday 27 March 2008, harbhanu wrote:
> Thanks for your informatin, I was able to take this forward after
> reverting to java version 1.5.0_15
>
> \apache-cxf-2.0.4-incubator-src>mvn -version
> Maven version: 2.0.8
> Java version: 1.5.0_15
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>
> \apache-cxf-2.0.4-incubator-src>java -version
> java version "1.5.0_15"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing)
>
> \apache-cxf-2.0.4-incubator-src>javac -version
> javac 1.5.0_15
>
> Now, the build is successful but one of the testcase is failing...
> Let me know incase it's a problem with the testcase or something
> else...
>
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.157
> sec <<< FAILURE!
> testFactory(org.apache.cxf.binding.soap.SoapBindingFactoryTest)  Time
> elapsed: 0.11 sec  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<[]> but was:<[ ]>
>         at org.junit.Assert.assertEquals(Assert.java:96)
>         at org.junit.Assert.assertEquals(Assert.java:116)
>         at
> org.apache.cxf.binding.soap.SoapBindingFactoryTest.testFactory(SoapBin
>dingFa ctoryTest.java:111)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>ava:39 )
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>orImpl .java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMeth
>odRunn er.java:99)
>         at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodR
>unner. java:81)
>         at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAnd
>AfterR unner.java:34)
>         at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner
>.java: 75)
>         at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:
>45) at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(Tes
>tClass MethodsRunner.java:66)
>         at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethods
>Runner .java:35)
>         at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassR
>unner. java:42)
>         at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAnd
>AfterR unner.java:34)
>         at
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52
>) at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.j
>ava:62 )
>         at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
>Set(Ab stractDirectoryTestSuite.java:138
> )
>         at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abs
>tractD irectoryTestSuite.java:125)
>         at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>ava:39 )
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>orImpl .java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Sur
>efireB ooter.java:290)
>         at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.ja
>va:818 )
>
> Running org.apache.cxf.binding.soap.RPCInInterceptorTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.172
> sec Running org.apache.cxf.binding.soap.SoapOutInterceptorTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.312
> sec Running org.apache.cxf.binding.soap.ReadHeaderInterceptorTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031
> sec
>
> Results :
>
> Failed tests:
>   testFactory(org.apache.cxf.binding.soap.SoapBindingFactoryTest)
>
> Tests run: 20, Failures: 1, Errors: 0, Skipped: 0
>
> [INFO]
> ----------------------------------------------------------------------
>-- [ERROR] BUILD FAILURE
>
> -----Original Message-----
> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 6:58 PM
> To: cxf-user@incubator.apache.org
> Cc: harbhanu; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Error during build !!
>
> On Wednesday 26 March 2008, harbhanu wrote:
> > I am trying to build CXF [2.0.4] using maven, but getting the
> > following error during build...
>
> ......
>
> > D:\JWork\CXF\apache-cxf-2.0.4-incubator-src>javac -version
> >
> > javac 1.5.0_01
> > javac: no source files
> > Usage: javac <options> <source files>
> >
> > D:\JWork\CXF\apache-cxf-2.0.4-incubator-src>java -version
> >
> > java version "1.6.0_03"
> > Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
> >
> > D:\JWork\CXF\apache-cxf-2.0.4-incubator-src>mvn -version
> > Maven version: 2.0.8
> > Java version: 1.5.0_01
> > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>
> Something very strange is going on.   From the command line, you are
> getting 1.6.0_03, but in maven, you are getting 1.5.0_01.
>
> That said, both will have issues with CXF 2.0.x.    The CXF 2.0.x
> builds are relatively untested with 1.6.x.   You can get the binary
> versions to work (possibly with endorsing some stuff) but we didn't
> work at all on getting the builds to work with 1.6.x.    CXF 2.1 will
> support 1.6.0_04 for building. (but not _03 and earlier)
>
> 1.5.0_01 has some parser issues that cause namespaces prefix problems
> (which is what you are seeing above).  I'd recommand at least _06, but
> the latest is definitely preferred.  (_13)



-- 
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to