Hi, > There used to be a issue in Camel with using CGLib proxied Spring > beans, but I recall that was fixed in 2.2 as well. > And that issue was only when you used Camel @annotations which causes > them to not work as expected. > Spring @Transactional is to my knowledge working. > > Maybe the Spring log can help. It logs something about bean XXX not > eligible for bean post processing, which is the process > Spring does when applying @ annotations and whatnot. >
I'm not sure what the problem is but my unit test inserts some reference data in the setUp() which is correctly rolled back at the end of the test, the camel route persists data as well and it seems to be occurring in a different transaction to that which the unit test is running in. I also have to do the whole Thread.sleep(2000) to give the processing enough time to move the file/consume and process it before testing that the data is correctly persisted. So there are obviously (at least) 2 threads. As this is a 'final' integration test before I put the code into production, I'm not too bothered that it doesn't behave as I would expect it, but it did throw up false negatives which caused me to be looking in the camel src code > >> Thanks for the help and I will not post unless I have exhausted the >> other possibilities. >> Kev >> > > Maybe I went a bit overboard. But the point is that people should > refrain from posting 2 min after they hit an issue. > And instead spend some time looking into the issue. And trying out > with latests releases is also preferred as it may very well be fixed. Don't worry - I was out of line not putting in all the info required - I was focusing on the platform and the default encodings rather than on the version of camel. I don't mind being confronted with my own stupidity, it's the only way to learn sometimes ;) My point about shelling out to iconv was more to do with how can camel interact with native code. I think a camel component that allows you to exec command line code would be useful in certain circumstances - camel-cli (based on the commons-cli code). > with latests releases is also preferred as it may very well be fixed. This is sometimes not possible with production code (although it doesn't apply to my particular case) Thanks for your help, Kev
