Am 15.03.2010 16:39, schrieb Claus Ibsen:
On Mon, Mar 15, 2010 at 4:21 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
I have nothing against that, but I was making a slightly different point.
Coding a framework is different than coding an application. With the latter,
one pretty much knows what to expect. With frameworks things are a bit more
complicated. I can see how a developer in a long running, managed application,
would create/start/stop a camel context multiple times. We should not have side
effects from previous executions of the camel context, i.e. camel should
cleanup after itself. Done right, it will also have the fringe benefit of not
needing to instantiate a jvm pertest. Having 2 profiles with different testing
strategies is fine.
Camel does cleanup the JMX stuff when its shutdown. Its most likely
other "stuff" which influence this which have a unforseen and weird
side effect which causes tests to not run reliable across all OS in
any time you you run it.
Of course giving the shutdown logic a review in Camel is of course a
good thing in case anyone can spot a weak spot.
That is a good "side effect" of the fork once. You find many points
where cleanups do not completely work. But it is a real pain to find the
cause of such failures sometimes.
Greetings
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
