Issues with Query

64 views
Skip to first unread message

Geoffry Roberts

unread,
Nov 13, 2013, 11:58:52 AM11/13/13
to mong...@googlegroups.com

Brian,


I trust you are well again.


Following my victory of being able to save an emf, I am now up against not being able to query.  I get the following error:


gogo: DiagnosticWrappedException: java.io.FileNotFoundException: /Users/gcr/Documents/ehrWorkspace/iop.storet.cmd (Is a directory)


This is with the same run configuration that succeeded when saving.


Some code:


URI uri = URI.createURI("mongodb://localhost/ehr/cda/527d0b740364b139f486fad8");

ResourceSetFactory resourceSetFactory = res.getResourceSet();

ResourceSet resourceSet = resourceSetFactory.createResourceSet();

Resource resource = resourceSet.getResource(uri, true); // This line throws the error.


Bryan Hunt

unread,
Nov 13, 2013, 9:13:34 PM11/13/13
to mong...@googlegroups.com
Hi Geoffry,

I think it's time to fire up the debugger.  I would start by putting a breakpoint in ExtensibleURIConverterImpl:360 and step into the call to getURIHandler().


Have a look at the uriHandlers array and see if the handler at index 0 is MongoURIHandlerImpl


If you step through the getURIHandler() function, the MongoURIHandlerImpl should be the one returned.

Let me know how this works so I can get you pointed in the right direction.

Bryan


--
You received this message because you are subscribed to the Google Groups "MongoEMF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongoemf+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Geoffry Roberts

unread,
Nov 14, 2013, 4:03:48 PM11/14/13
to mong...@googlegroups.com
Brian,

Did as you suggested, and yes, getURIHandler(normalizedURI) is indeed returning MongoURIHandlerImpl.

Bryan Hunt

unread,
Nov 14, 2013, 4:28:31 PM11/14/13
to mong...@googlegroups.com
Hi Geoffry,

I'll try to have a look at the code later tonight and give you some new breakpoints.

Bryan

Bryan Hunt

unread,
Nov 15, 2013, 7:49:46 AM11/15/13
to mong...@googlegroups.com
Hi Geoffry,

Put a breakpoint in XMIResourceImpl:1265 and verify that the inputStream returned is an instance of MongoInputStream.

Put a breakpoint in MongoInputStream:73 and trace through that function.  You don't need to step into any of the functions at this point, just let me know if it gets through loadResource() without throwing an exception.

Bryan

Geoffry Roberts

unread,
Nov 15, 2013, 4:56:23 PM11/15/13
to mong...@googlegroups.com
Brian,

Ok first of all let's be sure.  We're talking org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl are we not?  If so, I find no line 1265. The last line is 142.  

Second, loadResource() dose appear to execute completely without error.  I actually wind up stepping through some of the EMF based OHT code, which one would expect.  


On Wednesday, 13 November 2013 11:58:52 UTC-5, Geoffry Roberts wrote:

Bryan Hunt

unread,
Nov 17, 2013, 11:35:28 PM11/17/13
to mong...@googlegroups.com
Hi Geoffry,

If MongoImputStream.loadResource() executes without error, you should be getting your object back.  Can you post the entire stack trace you are getting?

If you want to really dive in, you can step through my code when running my example and compare that to what happens when running with your code.

Bryan

Geoffry Roberts

unread,
Nov 18, 2013, 7:39:54 PM11/18/13
to mong...@googlegroups.com
Brian,

Here's the upshot: You example works even when called from my code.  I'm sure you'll agree that the mode; used in the example is on the trivial side so far a complexity in concerned.  The emf I'm using is much more extensive. I stores but does not retrieve. When I stated that loadResource() executed without error. I thought it did, but I may have gotten lost when stepping through all the emf and missed the error.  I'll take another look.

I've attached the xml for you edification. 


On Wednesday, 13 November 2013 11:58:52 UTC-5, Geoffry Roberts wrote:
SampleCCDDocument.xml

Geoffry Roberts

unread,
Nov 21, 2013, 4:19:24 PM11/21/13
to mong...@googlegroups.com
Brian,

I did some checking that amounts to a comparison between your example and my stuff.  I set a break point in  ExtensibleURIConverterImpl.createInputStream at line 359.

 359>   URI normalizedURI = normalize(uri);


Running your example the value of normalizedURI is

  • mongodb://localhost/test/Parent/528e7145036401bdb4ddfcc6

Running my stuff normalizedURI goes through a series of values:

  1. mongodb://localhost/ehr/cda/527d0b740364b139f486fad8
  2. bundleresource://47.fwk1874224233/org/openhealthtools/mdht/uml/hl7/vocab/internal/impl/vocab.ecore
  3. bundleresource://44.fwk1874224233/org/openhealthtools/mdht/uml/cda/impl/cda.ecore
  4. file:/Users/gcr/Documents/ehrWorkspace/iop.storet

Value 1 is as expected.

Values 2 and 3 are EMF bundles that I use and so must be loaded.

Value 4 appears to be the culprit.  I points to the directory of the project from which the things were run and it corresponds to the error message.  It does not occur in the document that was saved originally nor is it in the database so far as I can tell.


In both cases, your and mine, the following returns from the database DBObject correctly. (line 133).  Trouble starts when we get to line 137.  I recall you are saving URIs to the database so you can tell which EMF document was saved.  Could the offending URI be getting saved?  I dumped the collection in question, but did not find any URIs good or bad.  Are they located elsewhere?


From:

MongoInputStream.loadResource...

133> DBObject dbObject = collection.findOne(new BasicDBObject(Keywords.ID_KEY, MongoUtils.getID(uri)));


137> EObject eObject = builder.buildEObject(collection, dbObject, resource, false);


Thanks


On Wednesday, 13 November 2013 11:58:52 UTC-5, Geoffry Roberts wrote:

Bryan Hunt

unread,
Nov 21, 2013, 6:40:51 PM11/21/13
to mong...@googlegroups.com
Hi Geoffry,

Would you be able to post the entire stack trace from the exception?

Bryan

Geoffry Roberts

unread,
Nov 22, 2013, 10:13:48 AM11/22/13
to mong...@googlegroups.com
Brian,

There isn't much to show.

gogo: DiagnosticWrappedException: java.io.FileNotFoundException: /Users/gcr/Documents/ehrWorkspace/iop.storet.cmd (Is a directory)

The above is all the error that prints.  

On Wednesday, 13 November 2013 11:58:52 UTC-5, Geoffry Roberts wrote:

Bryan Hunt

unread,
Nov 22, 2013, 10:44:18 AM11/22/13
to mong...@googlegroups.com
Hi Geoffry,

Is there an error log file?  If you are running with Equinox, it's in the configuration sub-dir.

If you can't find the stack, you will need to step through the code with the debugger or maybe try setting an exception breakpoint on FileNotFoundException.

Bryan

Geoffry Roberts

unread,
Dec 1, 2013, 7:16:00 PM12/1/13
to mong...@googlegroups.com
Brian,

I did some scrutiny.  The problem seems to begin at a point in the processing where a URI is created while trying to build a feature map.  It is the first time since processing began that buildFeatureMap is called.

EObjectBuilderImpl.buildFeatureMap(...

244> EStructuralFeature feature = (EStructuralFeature)

...

resource.getResourceSet().getEObject(URI.createURI((String) entry.get("key")), true);

... 


At this point, the key is as follows:  

entry.get("key") == "#///DocumentRoot/content"


When "#///DocumentRoot/content" becomes a URI, said URI is empty.

MongoResourceSetImpl.getResource(URI uri, 

// uri == ""

...

93> URI normalizedURI = uriConverter.normalize(uri);

// normalizedURI == "file:/Users/gcr/Documents/erhWorkspace/iop.storet"


FileNotFoundException occurs because normalizedURI is a directory, which is what the error message says.


Can you shed any light on this business with #///DocumentRoot/content?  It is not in the original document.  


On Wednesday, 13 November 2013 11:58:52 UTC-5, Geoffry Roberts wrote:

Bryan Hunt

unread,
Dec 1, 2013, 8:07:40 PM12/1/13
to mong...@googlegroups.com
Hi Geoffry,

That key value is probably coming from DBObjectBuilderImpl line 212: dbEntry.put("key", EcoreUtil.getURI(feature).toString()); I would trace through that code to verify this is the problem.  The next step would be to figure out why EcoreUtil.getURI() is returning a "bad" value.  I am not an expert when it comes to feature maps, so we may need to get some help from Ed on this one.

Bryan

Geoffry Roberts

unread,
Dec 3, 2013, 4:17:42 PM12/3/13
to mong...@googlegroups.com
Brian,

EcoreUtil.getURI() is indeed returning a bad value.  I've included the code below.  It is only under certain conditions that the bad value occurs.  Sometimes FeatureMaps process correctly, sometimes they don't.  I would appear that problems occur when processing a certain of my classes but I can't say why. The class in question, which is called StrucDocTextImpl, is a proper EMF class.  

If one looks at the XML that is used for input, every node in the document correlates to an EMF class except for the nodes contained in the aforementioned class. In it , are XML nodes and content that are handled by the class simply as text. (See second block of code below.) I don't fully understand this but it would appear that this text has no URI associated with it especially wrt the embedded nodes.  


From EcoreUtil:

  public static URI getURI(EObject eObject)

  {

    // If it's a proxy, use that.

    //

    URI proxyURI = ((InternalEObject)eObject).eProxyURI();

    if (proxyURI != null) // This is null

    {

      return proxyURI;

    }

    else

    {

      // If it is in a resource, form the URI relative to that resource.

      //

      Resource resource = eObject.eResource();

      if (resource != null) // This is null

      {

        URI uri = resource.getURI();

        String uriFragment = resource.getURIFragment(eObject);

        return uri == null ? URI.createURI("#" + uriFragment) : uri.appendFragment(uriFragment);

      }

      else

      {

        String id = EcoreUtil.getID(eObject);

        if (id != null) // This is null

        {

          return URI.createURI("#" + id);

        }

        else

        { // Here we build the return value from fragments the last of which is DocumentRoot.

          InternalEObject internalEObject = (InternalEObject)eObject;

          List<String> uriFragmentPath = new ArrayList<String>();

          HashSet<InternalEObject> visited = new HashSet<InternalEObject>();

          for (InternalEObject container = internalEObject.eInternalContainer(); container != null && visited.add(container); container = internalEObject.eInternalContainer())

          {

            uriFragmentPath.add(container.eURIFragmentSegment(internalEObject.eContainingFeature(), internalEObject));

            internalEObject = container;

          }

      

          StringBuffer result = new StringBuffer("#//");

      // Here we assemble the return value in reverse order.

          for (int i = uriFragmentPath.size() - 1; i >= 0; --i)

          {

            result.append('/');

            result.append(uriFragmentPath.get(i));

          }

          return URI.createURI(result.toString());

        }

      }

    }

  }


From StrucDocTextImpl:

private static String getText(FeatureMap root, String id) {

Stack<FeatureMap> stack = new Stack<FeatureMap>();

stack.push(root);

while (!stack.isEmpty()) {

FeatureMap featureMap = stack.pop();

for (FeatureMap.Entry entry : featureMap) {

if (entry.getEStructuralFeature() instanceof EReference) {

AnyType anyType = (AnyType) entry.getValue();

String attributeValue = getAttributeValue(anyType.getAnyAttribute(), "ID");

if (attributeValue != null && attributeValue.equals(id)) {

return getText(anyType.getMixed());

}

stack.push(anyType.getMixed());

}

}

}

return null;

}

On Wednesday, 13 November 2013 11:58:52 UTC-5, Geoffry Roberts wrote:

Bryan Hunt

unread,
Dec 3, 2013, 5:05:18 PM12/3/13
to mong...@googlegroups.com
Hi Geoffry,

I don't deal with XML when working with EMF models, so I think it's time to get some insight from Ed.  Please post your question to the EMF forum - http://www.eclipse.org/forums/index.php/f/108/

Bryan

Geoffry Roberts

unread,
Dec 3, 2013, 8:17:22 PM12/3/13
to mong...@googlegroups.com
Brian,

Here's where it stands: the embedded XML is handled by a related operation.  All is EMF generated code as best I can tell.  IBM did this particular bit of work.  I don't see where MongoEMF handles operations.  Maybe there's room for an enhancement.

Bryan Hunt

unread,
Dec 3, 2013, 8:22:17 PM12/3/13
to mong...@googlegroups.com
Hi Geoffry,

There's no need to handle operations since they are part of the generated EMF.  When and EMF model is read from MongoDB, the EMF framework is used to create an instance of the object which includes the operations.  My code then sets the attribute values and wires up the references.

Bryan

Geoffry Roberts

unread,
Dec 9, 2013, 9:28:28 AM12/9/13
to mong...@googlegroups.com
Brian,

I did inquire on the Ecore Tools Forum as to what to do about my problem with embedded XML and the unusable URIs that EcoreUtil.getURI(feature) is returning when said XML is encountered during processing.  Ed Merks responded and suggested a solution (see below).  I did some testing and can say that in my case, following Mr. Merks's suggestion, does yield a usable URI.  (Please see the bit I coded up further below.)  I can't say the solution will work for all comers--maybe it will maybe it won't.  

I did want to ask as to your stated plan to get these bundles into Bndtools.  Such a thing would be of great benefit to me and I would be happy to do some of the work.  

From the Ecore Tools Forum:
Geoffry,


When processing wildcards, the deserializer is using things like 
org.eclipse.emf.ecore.util.ExtendedMetaData.demandFeature(String, 
String, boolean) to create a feature and such demand created metadata 
has no enclosing resource. You might consider using 
org.eclipse.emf.ecore.util.ExtendedMetaData.getNamespace(EStructuralFeature) 
in the case that the URI you get from EcoreUtil.getURI returns the empty 
URI, but keep in mind that you "find" that feature again, you have to 
demand create it again, and for that you need to know if it's an element 
or an attribute to call demandFeature with the right arguments.

From DBObjectBuilderImpl:


   232     dbEntry.put("key", getFeatureURI(feature));

     ...

    public String getFeatureURI(EStructuralFeature feature) {

String s = EcoreUtil.getURI(feature).toString();

if (s.startsWith("#///DocumentRoot")) {

ExtendedMetaData emd = new BasicExtendedMetaData();

s = emd.getNamespace(feature);

return s;

} else {

return s;

}

}


On Wednesday, 13 November 2013 11:58:52 UTC-5, Geoffry Roberts wrote:

Bryan Hunt

unread,
Dec 9, 2013, 10:39:31 AM12/9/13
to mong...@googlegroups.com
Hi Geoffry,

I followed up on your post to Ed.

With respect to converting to Bndtools - yes, this is something that I would like to do.  The main obstacle is creating the feature.xml files for building p2 repositories.  This is something that needs to be supported in Bndtools.

Bryan

Geoffry Roberts

unread,
Dec 9, 2013, 1:14:07 PM12/9/13
to mong...@googlegroups.com
Brian,

I'll say this: for my needs, what features offer can be accomplished by something like Gradle.  If I really needed a feature, I would use Gradle to generate it.

Bryan Hunt

unread,
Dec 9, 2013, 1:18:38 PM12/9/13
to mong...@googlegroups.com
Hi Geoffry,

If you would like to create a demo of this (basically produce a categorized p2 repository from Bndtools ant build), I'm happy to consider it for a move to Bndtools.

Bryan
Reply all
Reply to author
Forward
0 new messages