Me too. Thanks Jarek/David !!
Jason Dillon wrote:
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
co
Thanks!
-Donald
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
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
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
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
Oh, there was discussion on this already? My delete key must have
been hungry...
Kay, just wondering. I was going to update the build to use surefire
2.3, which has a nice capture output to files feature to prevent all
those evil exceptions and other cruft from cluttering up the build
l
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:
On Aug 16, 2007, at 10:31 AM, Jason Dillon wrote:
And it spits this out to console before puking:
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.
that's h
And it spits this out to console before puking:
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.
Dunno if that helps...
--jason
On Aug 16, 2007, at 10:26 AM,
Anyone know what's up with this:
---
Test set: org.apache.geronimo.gjndi.binding.GBeanBindingTest
---
Tests run: 1, Failures: 1, Errors: 0,
10 matches
Mail list logo
