Yay... much happier now :-)
Thanks!
--jason
On Aug 16, 2007, at 8:03 PM, Jarek Gawor wrote:
The test should be fixed now (and it also works nicely on IBM JDK
now too).
The GBeanBinding.addBinding() method only binds stuff into the JNDI
context on the first call. The way the test was setup, it was called
multiple times for one binding. Therefore, the order in which
addBinding() was called really mattered. The order was affected by
different JDK implementation or the HashMap to LinkedHashMap change.
I fixed the test by ensuring the addBinding() is called once per each
GBeanBinding.
Jarek
On 8/16/07, David Jencks <[EMAIL PROTECTED]> wrote:
The reason I suspect that the test is wrong is that the LinkedHashMap
doesn't have anything to do with the xbean naming implementation that
is behind the javax.naming.Context. While it's possible that there's
a giant bug in xbean-naming I think it's more likely that the test is
not testing quite what we think it is.
thanks
david jencks
On Aug 16, 2007, at 4:56 PM, Jay D. McHugh wrote:
Hello all,
It appears that Jarek is correct (on the thread about rev 566046)
and the error is somehow related to the HashMap of GBeans in
Configuration.java being changed to a LinkedHashMap.
For some reason, with this change, the call to Context.listBindings
is returning the wrong values:
Should be (this is what is actually in the InitialContext):
ds [EMAIL PROTECTED]
ds1 [EMAIL PROTECTED]
ds2 [EMAIL PROTECTED]
Is now (this is what is returned from context.listBindings):
ds [EMAIL PROTECTED]
ds1 [EMAIL PROTECTED]
ds2 [EMAIL PROTECTED]
Because the binding for ds appears to have been magically changed,
the test fails.
(Tested on Linux with Sun Java 1.5.0_12-b04)
Isn't javax.naming.Context supplied to us?
Because it looks like it doesn't like having the bindings stored in
a LinkedHashMap.
Jay
David Jencks wrote:
On Aug 16, 2007, at 10:31 AM, Jason Dillon wrote:
And it spits this out to console before puking:
<snip>
10:30:29,171 ERROR [ConfigurationUtil] Cound not determine the
installation directory of Apache Geronimo, because the startup
jar could not be found in the current class loader.
</snip>
that's harmless AFAIK
There was a bunch of discussion on this yesterday on the Re:
[BUILD] 2.0: Failed for Revision: 566046 thread.
Currently I'm hoping someone else will fix it. I think the test
is indeterminate in some way but I haven't figured out what it's
trying to do.
thanks
david jencks
Dunno if that helps...
--jason
On Aug 16, 2007, at 10:26 AM, Jason Dillon wrote:
Anyone know what's up with this:
<snip>
-----------------------------------------------------------------
--
------------
Test set: org.apache.geronimo.gjndi.binding.GBeanBindingTest
-----------------------------------------------------------------
--
------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
0.876 sec <<< FAILURE!
testBasics(org.apache.geronimo.gjndi.binding.GBeanBindingTest)
Time elapsed: 0.846 sec <<< FAILURE!
junit.framework.AssertionFailedError: list of writable on <root>
for value for ds
expected:<[EMAIL PROTECTED]
>
but was:<[EMAIL PROTECTED]>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at
org.apache.geronimo.gjndi.AbstractContextTest.assertListResults
(AbstractContextTest.java:137)
at
org.apache.geronimo.gjndi.AbstractContextTest.assertList
(AbstractContextTest.java:109)
at org.apache.geronimo.gjndi.AbstractContextTest.assertEq
(AbstractContextTest.java:74)
at org.apache.geronimo.gjndi.AbstractContextTest.assertEq
(AbstractContextTest.java:39)
at
org.apache.geronimo.gjndi.binding.GBeanBindingTest.testBasics
(GBeanBindingTest.java:58)
at
org.apache.geronimo.gjndi.binding.GBeanBindingTest.testBasics
(GBeanBindingTest.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:
106)
at junit.framework.TestResult.runProtected
(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.junit.JUnitTestSet.execute
(JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execut
eT
estSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execut
e(
AbstractDirectoryTestSuite.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.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProces
s(
SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:818)
</snip>
--jason
