XStream

Unable to get Path for use in converter

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.3, 1.4
  • Fix Version/s: 1.4.3
  • Component/s: IO
  • Labels:
    None

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

Ascending order - Click to sort in descending order
Hide
Permalink
Neale added a comment -

It's been a year... is this likely to be addressed??

Show
Neale added a comment - It's been a year... is this likely to be addressed??
Hide
Permalink
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.

Show
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.
Hide
Permalink
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.

Show
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.
Hide
Permalink
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?

Show
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?
Hide
Permalink
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.

Show
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.
Hide
Permalink
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.

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

People

  • Assignee:
    Jörg Schaible
    Reporter:
    Neale
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: