There is a randomly failing continuations test that I've asked Sergey
to look at, but it's failing on on the branches. If he cannot find a
fix tomorrow, I'll @Ignore it for a bit.
Looking into it now... The initial observation is that it is always green if the test server (Server2) is
After messing with setting up a logger for an out-process server
(logging.properties were ignored after setting a
java.util.logging.config.file property in a server launcher properties, perhaps
there's some contention teher between the
EmbeddedBroker and Server2 for the same file handler, not
OK. I'm pretty sure Sergey and I tracked this down to some thread safety
issues in the ConduitSelector. However, it was made even worse on
2.2.x/2.1.x due to some additional thread safety issues in the JMSConduit on
those branches. (trunk has a completely updated conduit that doesn't
Thanks Dan for finding the actual issues with the ConduitSelector.
One thing this test has confirmed is that the way JMS continuations are
handled on the server side is pretty rock solid...
Cheers, Sergey
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: 03 September
I'm not sure why you would be getting that error. We don't reference
org.apache.axiom.om.OMElement
(or any other org.apache.axiom things) in our code at all. Thus, the
compiler should never need to parse it.
Very strange.
Dan
On Tue September 1 2009 4:39:34 am karypid wrote:
Ok, so
If Aegis runs into a raw Map with no XML spec of the key and value, should
it silently turn it into MapObject,Object or complain?
On Thu September 3 2009 7:43:31 pm Benson Margulies wrote:
If Aegis runs into a raw Map with no XML spec of the key and value, should
it silently turn it into MapObject,Object or complain?
I think so, yea. JAXB changes a raw List to a list of anyType so it probably
makes sense to do the
