ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: compiler access in iapi
Date Thu, 06 Sep 2007 18:33:02 GMT
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 <dan@thekearns.org> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message