[
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.
