Hey Dan, I think that BpelC being almost a singleton already, we could just change it to hold a single instance of itself and the newBpelCompiler() method would just return that instance, cleaned up (just by resetting all the SU related info). You could add a defaultBpelCompiler() method that doesn't go through that cleanup part so that you can set the listener easily.
// Initialization code BpelC.defaultBpelCompiler().setCompileListener(myListener); // Everybody's compilation code remains unchanged Bpelc.newBpelCompiler().compile(....); This will avoid the whole il->store->DU->BpelC injection problem. Would that work for you? Have time to contribute a small patch? Thanks, Matthieu On 9/6/07, Dan Kearns <[EMAIL PROTECTED]> wrote: > > Howdy, > > Just wanted to solicit some opinion on getting access to compilation > features from iapi, in particular the process store api. In my case, when > I > ask the store to deploy something for me and it may do compilation as a > result, I'd like to be able to pass in a compile listener and a custom > resource resolver. > > In my local tree I've patched in a callback which gets fed to the store > and > from there into bpelc which calls it back at the appropriate times - it > makes new compilers for each compilation, so there wasn't the option of > just > seeding the store with a preconfigured compiler. > > Anyone have thoughts on how to go about this? > > -d >
