Details
Improvement
Closed
Major
Description
I need to be able to know what the parent type is when doing a conversion, which is most easily established by being able to get at the PathTracker, but, there is no API that exposes it.
For now, I'm therefore adding the following to PathTrackingReader:
public PathTracker getPathTracker()
{ return pathTracker; }My first attempt was:
reader.moveUp();
String parent = reader.getNodeName();
reader.moveDown();
Which seemed to work... until I discovered that I'd inadvertently gobbled up the next sibling element!
And instead, I can now do:
PathTrackingReader ptr = (PathTrackingReader) reader;
PathTracker tracker = ptr.getPathTracker();
String path = tracker.getPath().toString();
int end = path.lastIndexOf('/');
int start = path.lastIndexOf('/', end - 1) + 1;
String parent = path.substring(start, end);
Would you please consider making the above use case supported, either by my API change, or by another means?
Activity
Basically it is not possible to add this in general, since not all MarshallingStrategies may have a PathTracker. For the 1.4.x series we've added the ReferencingMarshallingContext. If the provided context to your converter is of this type, you can cast it and call the getPath method. It's not released yet, though. Give the head revision a try.
Jörg Schaible
added a comment - Basically it is not possible to add this in general, since not all MarshallingStrategies may have a PathTracker. For the 1.4.x series we've added the ReferencingMarshallingContext. If the provided context to your converter is of this type, you can cast it and call the getPath method. It's not released yet, though. Give the head revision a try. I also require tracking of some prior state of the path.
Perhaps it would be better
to track the last parents class instead of just knowing the path? Specifically, I am trying to find out if the object I am converting from has a list as a parent. Lists seem to do things differently, and I cannot tell.
If I at least knew the class that the last converter was trying to work on, or a path of "class names" I could work this out.
Matthew Corby-Eaglen
added a comment - - edited I also require tracking of some prior state of the path.
Perhaps it would be better to track the last parents class instead of just knowing the path? Specifically, I am trying to find out if the object I am converting from has a list as a parent. Lists seem to do things differently, and I cannot tell.
If I at least knew the class that the last converter was trying to work on, or a path of "class names" I could work this out.
Sorry not to look at this when it was fresh. I somehow didn't get the JIRA notice that it'd been addressed and only noticed it recently when 1.4 was released.
If I try that cast, it fails, as my context is ReferenceByXPathUnmarshaller.
Is this implemented for unmarshalling, or just marshalling?
Neale
added a comment - Sorry not to look at this when it was fresh. I somehow didn't get the JIRA notice that it'd been addressed and only noticed it recently when 1.4 was released.
If I try that cast, it fails, as my context is ReferenceByXPathUnmarshaller.
Is this implemented for unmarshalling, or just marshalling?
You're actually right, it's only available at marshalling and that's not what you originally requested. I've reopened the issue, since there's no general solution yet.
Jörg Schaible
added a comment - You're actually right, it's only available at marshalling and that's not what you originally requested. I've reopened the issue, since there's no general solution yet. Actually this has been solved by chance with the last release. PathTracker has now peek methods to get the individual elements of the current Path, so there is no longer a reason to split the string representation of the path like it is done in the original code example.
Jörg Schaible
added a comment - Actually this has been solved by chance with the last release. PathTracker has now peek methods to get the individual elements of the current Path, so there is no longer a reason to split the string representation of the path like it is done in the original code example. 
It's been a year... is this likely to be addressed??