+1 for using Tuscany extension model to take care of this feature. I will make necessary changes for the same.
On Mon, Jun 15, 2009 at 6:45 PM, ant elder <[email protected]> wrote: > On Mon, Jun 15, 2009 at 2:03 PM, Simon Laws<[email protected]> > wrote: > > Is this for 1.x, 2.x or both? I'm assuming 1.x as we have scope in 2.x > > to decide what the real answer should be. > > > > That sounds right, this (TUSCANY-3096) would be for 1.x and in 2.x > we'd do what ever the final spec says. > > > Would I be right in assuming that this means that by default the > > annotation processing in Spring will be off? > > I think in 1.x we should leave it on by default so as not to break > compatibility with previous Tuscany releases. This doesn't violate the > spec drafts as it doesn't say anything about the annotation support. > > > > > Whether we go for a policy or an extension point (or something else > > such as Tuscany extension element inside implementation.spring) > > depends on how we want the user to be able to control this behaviour. > > > > The policy/Impl extension approach allows the user to potentially > > control this on a component by component basis. > > > > An extension does it for the whole runtime. > > > > The second seems less confusing in the near term. Can we make the > > extension processing logic the Tuscany extension that Ant is talking > > about. In this case however the default is not do annotation > > processing > > > > +1 for a whole runtime approach, I don't think there's any need for > more fined grained control. > > > > If we are going to apply this to 2.x it may be worth taking a wider > > view if we are starting to build up a number of these extension > > controlled runtime behaviour switches. > > > > +1, it would be good in 2.x to have a better way to configure runtime > options. > > ...ant > -- Thanks & Regards, Ramkumar Ramalingam
