(oracle.jbo.ConfigException) JBO-33001 after refactoring in the Model.

Question

Guys,
Can someone please help with this annoying problem...
I have done some refactoring of application modules in my Model, and now I keep getting the following error when I start up my application, and call the static method Configuration.createRootApplicationModule (...) :-
(oracle.jbo.ConfigException) JBO-33001: Cannot find the configuration file /uk/co/xxxx/xxxxxx/common/bc4j.xcfg in the classpath
The above package name ("uk.co.xxxx.xxxxxx") is my old location of the application module. What I want to know is what is, where is JDeveloper still picking this up from?? I have checked my DataBindings.cpx in my View, and it is not getting it from there!
More info - At startup I have a AppModuleManager which loads a couple of application modules which I will use to call various service methods at startup, to cache reference data. I do this like so : -
ApplicationModule myAppModule =
Configuration.createRootApplicationModule(Common.APPLICATION_MODULES_HOME, Common.MY_LOCAL_AM);
appModules.put (Common.MY_LOCAL_AM, thurbonAppModule);
Oh, and the Javadoc on the Configuration class desperately needs updating in 10.1.3! The documentation there tells you to do the following :-
Configuration c = new Configuration( Configuration.buildConfigFileName("package10")); Hashtable env = c.getConfiguration("Oracle8iCorba"); ApplicationModuleHome home = (ApplicationModuleHome)ic.lookup( env.get(Configuration.APPMODULE_JNDI_NAME); ..... .....
One obvious snag is that there is no constructor that takes a String in the Configuration class....
F.Y.I> I am using JDeveloper 10.1.3.36.73, with the recent service release.
I have managed a couple of "work-arounds" to this problem, including deploying the bc4j.xcfg in the "old place", and also using the "loadFromReader" method, passing it a FileReader of my config file, but clearly these are not ideal... Therefore could someone please give me some ideas as to where it is picking up my old bc4j.xcfg from??
Many thanks.......Dean

Answer 1

Thankyou for your comments Steve.
To answer your points :-
Full ADF Source is available for supported customers by opening a TAR on Metalink and asking for it.I will look into this option... Thanks for the URL to the details.
2) I did use the inbuilt refactoring in JDeveloper - I would never manually refactor within a IDE because I am aware of the hidden effects this can have on various configuration files. However, as I mentioned above, there is quite a bit of "rubbish" lying around from earlier versions - In particular the 10.1.2 (refactoring here had all sorts of problems), and the 10.1.3 EA release. It was fixing problems caused by unsuccessful project migrations in these versions that also caused me to manually visit project files.
The Configuration.createRootApplicationModule() is not typically required for any of our > UI clients. Other layers of the framework acquire the AM instance for you as part of > creating the binding context. . 3) I suspected as much, but an awful lot of URL links referred me to this mechanism if you do a search on using service methods via ADF on Google, and it was easy to implement. Incidentally, as I mentioned, I only use this mechanism for loading complex reference data Collections at startup for fast validation later, and when Actions require me to kick off Stored Procedures and complex business logic, which I have implemented via service methods... I think this solution works fine for me but perhaps I need to change the way I call the service methods from the client? Incidnetally, the access required is stateless in these instances. Would you still recommend me to change this to obtain AM access via the binding context, and if so why?
I
I shall have a read of your presentation now with interest - Being relatively new to Swing development using ADF / JDeveloper 10.1.3 I have found the business benefits it provides really good, but I have been frustrated in finding good quality relevent documentation for 10.1.3.
As for my other comments about "bugs" in 10.1.3.. Of course I expect to find a few bugs and annoyances... I can see that 10.1.3 is a big jump from 10.1.2, and it is certainly much better; I am also realistic enough to appreciate the time pressures you would have been under to push to market, and obviously it is definitely the case that many of your competitors initial major software releases are full of bugs (I mention RSA 6 was, and I could have named others). I am confident that each service release of 10.1.3 will iron out the "quirks", for example :-
i) CVS integration is still not quite right - Delays in picking up new software that has been checked in, which I can pick up if I switch to Tortoise..
ii) Refactoring problems - Actually, I have not experienced any recently... (I am on SR1)
iii) Code generation quirks...eg. Why does it generate an implementation for methods in a interface?
But please keep focus on the (lack of) documentation issues, aka you recent blog posting.
Best regards......Dean