[jira] Updated: (ARIES-319) Check in a re-factored version of the samples-sandbox/demo sample

["Holly Cummins (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARIES-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Holly Cummins updated ARIES-319:
--------------------------------

    Attachment: servicecomponentenhancer.txt

I've added an extra layer which transforms services from relationships to components. 

You can see the new content by choosing one of the bundle info providers with [enhanced] after the name. At the moment, I'm not sure why you'd want to do that unless you were doing GOAT development, since the services look exactly like bundles. However, I opted to keep the patches incremental so we avoid file conflicts. I'll add shape control next, which will improve things, but I think we'll also need a much smarter layout manager for things to look properly right.

I got most of the way through implementing code which mangled the IDs of all the components which passed through the enhancer (moving them into their own 'namespace', effectively). The advantage of this is it helps ensure that the IDs of any newly generated components or relationships could never clash with existing IDs, because the IDs of everything in the model would have been generated by the enhancer. As I was wrote more and more code, however, I decided it was an accident waiting to happen. We'd have to clone each ComponentInfo we saw. So far so good, but do we do a shallow or deep copy of the properties? For the properties I concluded copying the map across would be fine, since we'd probably want property changes to be reflected in our cloned components anyway. I was less happy when I got to the map containing the children. We can't just copy the map because then our 'cloned' component would have links to 'original' children. So we can make a new map and copy each component across, cloning it en route, but then we risk having two instances of the same component, because we cloned it when it was first created, and then we cloned it again when we noticed it as a child of another component. I was having to insert the namespace mangling code pretty liberally through the enhancer, and eventually it was going to happen that an ID would get mangled which shouldn't have been, or left unmangled when it should have been mangled, and we'd have a broken component reference. I think the risk of these kinds of manipulations outweighs the benefits of the namespace uniqueness. It seemed especially ineffective to go to such lengths to turn something into two instances when both actually the identical *thing* in the model. 

I've ripped the cloning logic out and my code shrunk significantly and appears much more robust. I've chosen a naming scheme for my generated components which should avoid ID clashes with any real bundles unless a bundle info provider chooses a particularly perverse naming scheme for their components. :)

I've left the table on the left showing 'undefined' rows for the services since I think there was other work going on in that code.

I've also corrected the orientation of the triangles on the existing service visualisation so that it's correct.

I think the extra components may be making the current performance problems worse (just by adding to the number of things being managed) so we may want to try and focus a bit on the performance. I think Ozzy is right and the problem is event storms, which we can hopefully damp a bit.

For some reason the new bundle only comes up as resolved when the assembly starts, not started. I've got no idea why, but it may be as well since it's not really ready for mainline use yet.

> Check in a re-factored version of the samples-sandbox/demo sample
> -----------------------------------------------------------------
>
>                 Key: ARIES-319
>                 URL: https://issues.apache.org/jira/browse/ARIES-319
>             Project: Aries
>          Issue Type: Improvement
>          Components: Samples
>            Reporter: zoe slattery
>            Assignee: zoe slattery
>         Attachments: goat-architecture.odp, goat-services-a.txt, servicecomponentenhancer.txt
>
>
> The demo sample code currently under samples-sandbox/demo is being refactored and moved
> The first stage in the process is to move the code to samples/goat (Graphical Osgi Analysis Tool)  - this code only contains a dummy info provider so it's not quite up to the same level as the code currently under samples-sandbox/demo. When the new code has an equivalent of BundleContextInfoProvder the code under samples-sandbox will be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.