Simon, I've been operating with basically the same set of changes locally and things do seem to work fine.
>From a design perspective, the unshared model seems like a better alternative to me. I'm sure there are performance gains from not having to do annotation processing, etc, multiple times, but these could probably be achieved with caching elsewhere. Brent On Thu, Jun 16, 2011 at 5:20 AM, Simon Laws <[email protected]> wrote: > On Thu, Jun 16, 2011 at 9:14 AM, Simon Laws <[email protected]> wrote: >> On Thu, Jun 16, 2011 at 2:31 AM, Brent Daniel <[email protected]> wrote: >>> I noticed that the appliesTo processing in PolicyAppliesToBuilderImpl >>> is not operating on components. Otherwise it seems to be working fine >>> from what I can tell. This is something to take into consideration if >>> the implementation policies are moved back to the component, though. >>> The appliesTo would happen after the policy set was moved to the >>> component, so if the builder was correctly handling components, any >>> implementation policy set that had a reasonably specific appliesTo >>> would be removed. For example, the ManagedTransactionPolicySet applies >>> to elements that start with "implementation", so it would be removed. >>> >>> Brent >> >> You're right Brent. Currently the appliesTo process assumes that the >> policies for an implementation are retained on the implementation >> model. If we do resort to holding them on the component then we will >> have to take the set on the component into account when calculating >> appliesTo. The bottom line is that we have some code that assumes >> policy sets are on the implementation and some that assumes they are >> on the component. If we use the implementation then we loose the >> shared implementation optimization. If we use the component then we >> have to fix applies to etc. At the moment it looks like most of the >> code assumes it's on the component so, as I said, I'll first take and >> approach of putting them back on the component and see if I can get >> that path working again. I I struggle I'll look at unpicking the >> shared implementation assumption. >> >> Simon >> >> -- >> Apache Tuscany committer: tuscany.apache.org >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com >> > > I started down the rout of putting back the code to support > implementation policy at the component level. It does quickly become > untidy though as we have to take account of things like appliesTo and > writing the composite back out correctly.I stopped and changed track > to put a small set of changes in to disable implementation model > sharing and to pick up policy from the implementation. The policy > providers are still stored on the component and the implementation > factory interface still takes a component. This though hould give us > enough to get tests written and see if the approach is practical. > Brent can you repeat whatever you were doing when you found the > problem and see if it now works for you. > > Change checked in against TUSCANY-3876 > > Regards > > Simon > > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
