Bursting with JAVA APIs / MultiThreading / Errors Handling

Question

We are trying to use the bursting JAVA APIs 10.1.3.3.1 Standalone) to burst huge XML files and generate PDF Files from RTF templates. Here are a list of our issues with this feature:
1. We have some problems catching the errors when bursting. We have tried to use the "oracle.apps.xdo.common.log.Logger" class, but it is not always reacting like we think it should. Could you please give us an exemple of a clean bursting error catching or a brief description of how we could do it. We have a lot of difficulties to find information about using the JAVA APIs of BIP.
2. Is it a clean way of catching the bursting errors to use the "oracle.apps.xdo.common.log.Logger" class?
3. When using the 10.1.3.3.1 DocumentProcessor JAVA API, the process gets killed when the RTF template is not where the control file specified it. Even when using a finally clause containing the document processor, we can't fetch the error from the "oracle.apps.xdo.common.log.Logger" class. We did not find a way to catch this error which make our program crash.
4. How can we enable multi-threading that is included in the DocumentProcessor JAVA APIs so it can take advantage of the multi-processors environnements?

Answer 1

1. Check tim d. blog, you can use the bursting listners to get the errors. It's also in the documentation.
First, on every exception, the Bursting APIs are dumping the error in the Logger. So I can't see how we can use the listeners to catch these. We can check the hasExceptions on the Logger but still, we have some problems with this. When we deploy our application as a MDB (Message driven bean), it seems that once the hasException flag has been raised, if we call the MDB again, it is still up. Is there documentation about that Logger class? Also, I'm worried that we won't be able to call our MDB twice to run simultaneously 2 different bursting process since it seems the Logger is something static, keeping every exception in memory... That's bad.. And show me where you have found documentation about this. All I see in documentation is how to call the DocumentProcessor in a couple of lines. I don't see anything about a clean way to catch errors.
2. Yes/No/Depends. I think it's fine. If your changing the logger options in your program that could come back to haunt you.
I guess so, I'm not changing anything and its already haunting me...
3. When using the 10.1.3.3.1 DocumentProcessor JAVA API, the process gets killed when the RTF template is not where the control file specified it. Even when using a finally clause containing the document processor, we can't fetch the error from the "oracle.apps.xdo.common.log.Logger" class. We did not find a way to catch this error which make our program crash.
Even worst, when we deploy the component has an MDB, when the error happens, it kills the whole oc4j container... please correct this quick.
4. How can we enable multi-threading that is included in the DocumentProcessor JAVA APIs so it can take advantage of the multi-processors environnements?
We got an answer from the dev team which is to add two properties to the document processor, something like:
enable-multithreading: true
thread-count: >2
We did that and what we got is that the process started and it got stuck in a dead lock at the first document processing. How nice! :)
We got a milestone in March and I'm really worried about all those problems... Not enough documentation, a pretty bad error handling, errors making crash the whole oc4j container, Logger seems not to be handling simultaneous calls/ threads, not even handling two subsequent calls... etc.
If anyone has the magic answer, it would be pretty welcomed!
Thanks