It is possible to place Configurator Extension Archives, or even your CX class files themselves, in your application server's Java CLASSPATH, and then refer to them by their fully-qualified class names in your Configurator Extension rules. There are many reasons you would not want to do this, however. Among them are:
- You must always ensure that identical versions of all Archives/classes are installed on all the environments (Development, Test, Production) your Configurator Models need to be executed on.
- Modifying any CX class installed on the filesystem requires a web server bounce in order for the code changes to take effect, which necessitates downtime not just for Configurator but for your entire E-Business Suite system.
- Modifying a CX class installed on the filesystem immediately impacts all Models using that Configurator Extension, and therefore requires testing of each one prior to deployment of any one.
The Configurator Extension framework introduced in 11i10, in which Configurator Extension Archives are stored in the database, was intended to address all of these shortcomings of filesystem-based CX deployment:
- CX Archives are part of a Model Publication, so there is no need to explicitly install jar or class files on any Publication target server. The CX Archives associated with a Model get copied to the target database when the Concurrent Program to process the Publication is run.
- Modifying a CX class and republishing a Model that uses it does not require a web server bounce. At runtime, the new code automaticaly gets loaded with the new Model definition. No downtime required.
- Modifying a CX class only impacts those Models that use it that are subsequently republished. Models you do not republish continue to use the CX code as it was when they were last published.
I am completely unfamiliar with PPM, but I don't have to know anything about it to tell you that any deployment architecture that involves Configurator Extension classes on the filesystem is not taking advantage of the best practices facilitated by the standard Configurator Extension framework.
Hope this helps.
With this approach (i.e. binding CX to model and publish them to host application) we did face issues while doing a multi threading of 'Model instantiation thru CIO APIs'.
Using CIO APIs we are instantiating the model and creating configurations. But during multi threading we noticed that it was erroring out (as it was trying to instantiate multiple instances of the java classes/archieves). As a fix we moved all the Java archives (class files) to the java Classpath, instantiated them manually and that error went away.
An "attempted duplicate class definition" bug in the CX class loader was fixed in Configurator R12.1.3 build 31-8, which was released in December. (The error was occurring if two Configuration objects attempted to instantiate the same CX within about 1 millisecond of each other.) If that sounds like the problem you were experiencing, you should look into whether this build resolves it. The patch number is 17242618.