Hi Chris,
Thanks for the great explanation! The whole SPI concept makes
sense to me now.
Given that, here is my new very high level take on the process
of Tuscany removal from the Change Analyzer:
Currently it seems as if everything in the change analyzer
accesses SDD data through the classes contained in one of the three org.eclipse.cosmos.me.internal.deployment.sdd.runtime.schema.*
packages. So if we just remove these packages all together, we’ll
see everything break every time it references data through a class with a Tuscany
association. Then we go through and replace each one of those references, one
by one, with a reference to the data from the SDD that goes through the DOM-backed
interface provided by the SPI, being careful to keep an eye out for cache-ing
issues (i.e. making sure the DOM structure that initially populated the SPI
object graph hasn’t been changed underneath the object graph).
Does this seem like a reasonable approach? Any thoughts you
have on this are greatly appreciated.
Thanks,
Mark
From:
eyeofthefrog@xxxxxxxxx [mailto:eyeofthefrog@xxxxxxxxx] On Behalf Of Chris
Mildebrandt
Sent: Wednesday, August 13, 2008 2:49 PM
To: Mark Mccraw; Cosmos Dev
Subject: How the SPI retrieves data from the DOM tree
Mark,
This is regarding the question you had during the Tuesday ME meeting. The SPI
saves the SDD in a DOM object and uses that as the data model. The SPI classes
are used as a convenience to developers to get data in a manner that reflects
the SDD structure. When an SDD is read into the SPI, the user gets a
DeploymentDescriptor object. From here, the user will drill down through the
getters to obtain the required object. For instance, here's the getter for
resources from DeploymentDescriptor:
public Collection<Resource> getResources() {
Collection<Resource> resources =
new ArrayList<Resource>();
if (isSetElement("Topology")) {
Element topology =
getChild("Topology");
Collection<Element> tmpList = session.getChildren(topology,
"Resource");
for (Element
element : tmpList)
{
resources.add(new ResourceImpl(element, session));
}
}
return resources;
}
A collection of Resource classes is created. Then a getChild() method is called
to obtain the DOM Element that represents topology. Next, all the first level
resource elements in topology are returned as a collection of Elements. The
session.getChildren() method does this by taking the parent element (topology)
and returning all the elements with the node name of "Resource" using
DOM calls. You can see this code in the SPISessionImpl class. For each of the
returned elements, a new Resource class instance is created. The only thing the
constructor does is to save the resource element and the session objects. The
collection of these resources is returned.
As you can see here, there is no Topology class. The only job of topology is to
hold resources. So we decided to let the user obtain the resources directly
from the depolyment descriptor. You'll see this in a few other places as well.
There isn't a way to go directly from the DeploymentDescriptor object to a
specfic piece of data. If people are familiar with xpath, they can use the
internal methods to get access to the DOM objects directly. We don't really
approve of that method, which is why it's internal. But since there is no data
stored outside of the DOM tree, there should be no problem in modifying it
directly.
One thing to note, the SPI deals with copies of objects, not references. If you
create a resource, and then save it into the tree, you can change that resource
and not affect the tree's copy. Same with retrieving data. If you get a
resource from the tree and change it, you must go back and save your changes
through the setter interface.
Let me know if you have any additional questions,
-Chris