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
