Lance,
It occurred to me that I did not mean to put these methods on the API, they should only be on the class. I've removed them from the API. The intent is to support debugging and custom policies on invocation handling. On Mon, 2006-08-14 at 10:28 -0600, Lance Waterman wrote: > Maciej, > > see inline ... > > Lance > > On 8/14/06, Maciej Szefler <[EMAIL PROTECTED]> wrote: > Lance, > > The registration methods are for registering global listeners > for BPEL > events (basically process execution status) > > are you thinking about debug with this? > > > and message exchange > interceptors. Message exchange interceptors permit the > interruption of > message exchange processing based on policy rules. They are > basically > add-ins, so you can ignore them. > > I'm not sure what you mean by add-ins? Can you outline a couple of > use cases? Thanks. > > > Speaking of interfaces. I added a new interface called > BindingContext > that provides a much simpler mechanism for the IL and the > server to > negotiate communication channels. The methods in this > interface were > extracted / refactored from the EndpointReferenceContext > interface, > which now deals purely with endpoint reference resolution. I > am checking > this in today. > > Great, thanks for the heads up! > > > -maciej > > > On Mon, 2006-08-14 at 08:37 -0600, Lance Waterman wrote: > > Matthieu, > > > > Thanks for the explanation and my main concern would be, > > > > >> I've seen a couple of usages that could be > > >> changed to use the interface instead of the impl .. > > > > Specifically, I think it would be helpful if we could change > the following > > impl references to the interface; > > > > org.apache.ode.axis2.ODEServer ( line 82 ) > > org.apache.ode.axis2.ODEService ( line 55 ) > > org.apache.ode.jbi.OdeContext ( line 73 ) > > > > Thoughts? > > > > My goal is to make sure we aren't missing anything in the > interface ( and to > > have a nice interface example ). Cory and I are beginning > the work on a test > > framework and I would like to get the public interfaces > nailed down as much > > as possible. > > > > Also, I have note out to Maciej but if you have any input on > the following > > methods added to the BpelServer interface ... > > > > void registerBpelEventListener(BpelEventListener > bpelEventListener); > > void > registerMessageExchangeInterceptor(MessageExchangeInterceptor > > interceptor); > > > > Thanks, > > > > Lance > > > > On 8/11/06, Matthieu Riou < [EMAIL PROTECTED]> wrote: > > > > > > Hi Lance, > > > > > > The IL is instantiating the BpelServer (in the IL server > classes) so it > > > needs to import the BpelServerImpl to at least instantiate > it and set a > > > couple of needed attributes. I've seen a couple of usages > that could be > > > changed to use the interface instead of the impl, so to > clean up a bit, > > > but > > > that still won't remove the dependency. The IL is the one > starting the > > > BPEL > > > server. > > > > > > Cheers, > > > > > > Matthieu > > > > > > On 8/10/06, Lance Waterman < [EMAIL PROTECTED]> > wrote: > > > > > > > > Maciej, Matthieu; > > > > > > > > I see that the reference implementations of the IL are > using > > > > BpelServerImpl > > > > rather than the BpelServer interface and am curious as > to why? > > > > > > > > > > > > Thanks, > > > > > > > > Lance > > > > > > > > > > > > > > > >
