> Regarding MessageContext/RuntimeContext, they both should be public. MessageContext is already public, but looks like it should be as easy as just moving RuntimeContext up a level (org/apache/wink/common/runtime).
If you think it's worth not breaking anyone that was using the previous package, we could just leave an interface in internal/runtime/RuntimeContext.java and have it extend the public one. -Nick Nicholas Gallardo WebSphere - REST & WebServices Development [email protected] Phone: 512-286-6258 Building: 903 / 5G-016 Michael Elman <[email protected] > To [email protected] 08/25/2009 12:03 cc PM Subject Re: Exposing Please respond to DeploymentConfiguration and wink-...@incubato RuntimeContext r.apache.org Originally DeploymentConfiguration was designed to be public, but I became kinda huge and finally it has found itself in the internal. So currently there is no way to add user handlers without using inner apis. I think we should create a simplified API for adding handlers. Regarding MessageContext/RuntimeContext, they both should be public. On Tue, Aug 25, 2009 at 6:59 PM, Bryant Luk<[email protected]> wrote: > Hi, > > I like the way that the handler chain works today. However it can be > cumbersome for users to understand how to create their own user > handler. One of the potential advantages of Wink is to make the > handler chain easier to customize. > > Is there any issue with exposing DeploymentConfiguration and > RuntimeContext as public (JavaDoc'ed) APIs? > > DeploymentConfiguration is already talked about today inside the > developer's guide. I don't think it makes much sense unless the API > was made "public" and JavaDoced. > > MessageContext is already a public API and it inherits from > RuntimeContext which is a "private" API. I imagine any handler would > use the RuntimeContext APIs. > > Thoughts? > > -- > > - Bryant Luk >
