It is very difficult to see what your problem is without logs
a quick peek at your code shows you are using obfuscated classes, which is usually not a good approach
I would encourage you to log an SR with support or contact your ORACLE sales rep to assistance
Now from a general POV it seems you are already returning the list of XREFS, so normally if your integration is properly done, there should be no need to implement the mockup trick
On the mockup side, since you are not paying attention to synchronization between threads, you will definitively run into race conditions
Thankf for your replay.
You can check the log through the URL link.
I can understand your mention when integration method with Mockup process.
But Our best approch is this method for customer`s requirement.
So I looking for the good method from ORACLE or other partner.
Also before SR log, I want to get the more good information from here.
Please check my URL link once again and give to me help.
The approach you are using is bound to fail unless a significant amount of care is taken it also circumvents existing (working) framework
My recommendation is that you use the existing framework to properly implement XREF support
There seems to be no justification for the work you are doing, the information about xrefs is available on the client so it is also available on the server side, just send it and avoid all the extra headaches
Ricardo is right - mockup is not the recommended way to go here. If you have a proper assembly file already, I'd recommend just implementing the normal xref support in your integration.
If the problem is that you do not have an assembly file, just a collection of JT parts, I'd suggest you look at what we call the 'AutoVue Assembly File' - which is an XML file that lists individual parts and the appropriate transformations. This is documented on page 50 of the 20.2.2 Viewing/config guide: http://docs.oracle.com/cd/E49312_01/otn/pdf/E49257_01.pdf