On Fri, Oct 17, 2008 at 10:16 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Tue, Oct 7, 2008 at 9:07 AM, ant elder <[EMAIL PROTECTED]> wrote: > >> >> >> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <[EMAIL PROTECTED]>wrote: >> >>> >>> >>> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <[EMAIL PROTECTED]> wrote: >>> >>>> >>>> >>>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <[EMAIL PROTECTED]>wrote: >>>> >>>>> >>>>> >>>>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <[EMAIL PROTECTED] >>>>>> > wrote: >>>>>> >>>>>> <snip> >>>>>> >>>>>> >>>>>>> I'm particularly interested in those who put the provider framwork >>>>>>> in place see the addition of binding configuration see this as an >>>>>>> extension >>>>>>> of the binding providers or see this as a new set of providers? >>>>>>> >>>>>>> >>>>>> This is looking like a new type of extension to me, people should be >>>>>> able to contribute new wireFormatters and have them made available for >>>>>> use >>>>>> within the Tuscany runtime. Its also looking like this should be >>>>>> possible to >>>>>> do at the application level. >>>>>> >>>>>> So Tuscany would come with a bunch of wireFormat extensions just like >>>>>> it already has a bunch of binding and implementation extensions. >>>>>> Something >>>>>> somewhere would define what the default wireFormat extension is to use >>>>>> with >>>>>> each binding when no <wireFormat> element is in the SCDL. So there would >>>>>> be >>>>>> a self contained JMS wireformat extension which implements the defaults >>>>>> as >>>>>> defined in section 5.2 in the JMS binding spec and you'd be able to do: >>>>>> >>>>>> <reference ...> >>>>>> <binding.jms> >>>>>> <wireFormat.jms/> >>>>>> </binding.jms> >>>>>> </reference> >>>>>> >>>>>> but that would be the default so the same as: >>>>>> >>>>>> <reference ...> >>>>>> <binding.jms /> >>>>>> </reference> >>>>>> >>>>>> Users could also do >>>>>> >>>>>> <reference ...> >>>>>> <binding.jms> >>>>>> <wireFormat.myFunkyFormatter/> >>>>>> </binding.jms> >>>>>> </reference> >>>>>> >>>>>> and have the 'myFunkyFormatter' extension as part of their application >>>>>> not some jar that needs to be added to the Tuscany runtime. >>>>>> >>>>>> We could use the definitions.xml file to define things like the >>>>>> default formatter for a binding, it also seems like that old discussion >>>>>> on >>>>>> using the definitions.xml file to declare the extensions would help with >>>>>> the >>>>>> myFunkyFormatter case as described at: >>>>>> http://apache.markmail.org/message/unubgkqdcwwch66m >>>>>> >>>>>> ...ant >>>>>> >>>>>> >>>>> So there are two points here then >>>>> >>>>> *1. wireFormat as a separate extension point.* >>>>> >>>>> Ok so that could work. We would need the usual provider structure for >>>>> wireFormat and operationSelection. Then we need some new bits to get the >>>>> associated interceptors in the right place. >>>>> >>>>> - A wire structure managed by the bindingListener/bindingInvoker >>>>> - some predefined "wire format" and "operation selection" phases on the >>>>> new wire that ensure that the interceptors get put in the correct place >>>>> - A mechanism where, as you suggest, the binding can instigate defaults >>>>> when no specifics are included in the SCDL. This could be as easy as >>>>> completing the model based on definitions.xml entries >>>>> - Code to read the model, select the appropriate factory and popoulate >>>>> the new wire with interceptors from the binding and from wireFormat and >>>>> operationSelector >>>>> >>>>> *2. extension points (wireFormat in this case) provided in SCA >>>>> contributions* >>>>> >>>>> Personally I'd like to keep this separate from 2 for the time being. >>>>> Only because it's easier in the first instance to go with adding >>>>> extensions >>>>> via the META-INF/services mechanisms while we work out what the extension >>>>> points should look like. Having looked back over the ML conversation on >>>>> definitions.xml though it does seem that there was a desire to allow some >>>>> extensions to be added to the runtime as part of a contribution. We can't >>>>> even do this with policy today so something like wireFormat would be a >>>>> isolated case to look at. I still want to get the extension point right >>>>> first though. Doesn't stop others looking at this if they want to of >>>>> course. >>>>> >>>>> >>>>> Simon >>>>> >>>> >>>> Do you mean do this with a stepping stone approach, so do (1) then do >>>> (2), or do you mean only do (1) and if someone out there in the community >>>> ever feels like contributing (2) then good for them and we'd probably take >>>> it? I'm asking because if users can't contribute a custom wireFormat then >>>> we'll need to provide a way to configure some Tuscany specific one, and if >>>> thats all we're doing how is that better than Tuscany's current approach of >>>> having some Tuscany specific attributes on the binding.jms element? >>>> >>>> ...ant >>>> >>>> >>>> >>> Yes, as a stepping stone. I was just presenting how I would approach it >>> while trying to make space for anyone who might have a real urge to get on >>> an look at the user provided extension point part. >>> >>> Simon >>> >> >> Sounds good. >> >> ...ant >> > > I'm doing some refactoring of the jms binding to make some function more > plugable for various runtime environments (eg running in Geronimo and using > Geronimo JMS provider) so while i'm doing this i thought i'd make a start at > adding support for some wireFormat based on whats been discussed in this > thread. Mainly refactoring things like the current databinding and message > processor support out into clear and separate peices so this should make it > easier to plug in/replace the function when the wireFormat support gets > added to the Tuscany core runtime. > > ...ant > > Sounds good ant. Am working on JMS tests and some initial infrastructure changes to demonstrate the wire format support at the moment but stuck with a very peculiar ant build problem atm so don't have anything to check in just yet. Simon
