New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LowLevelInterface.getDataObjectsByType gives too many result #772

GiacomoManzoli opened this Issue Jun 28, 2018 · 4 comments


None yet
2 participants

GiacomoManzoli commented Jun 28, 2018


the LowLevelInterface.getDataObjectsByType seems to return too many results, by adding some non existing elements.

The IFC project which gives me the error is attached to the issue.
In this case, the says that there are 2570 IfcDistributionPort in the project, which is the same amount of element i get if i CMD+F "IfcDistributionPort" in a text editor (such as VS code), but the call:

  "token": "13c82aed7fc40cd05fafbe64d1f4d07ad735f10b7ef50f905b7fb6b9bc0b8555f018f29545acfc2913ace71b8de38c30",
  "request": {
    "interface": "LowLevelInterface", 
    "method": "getDataObjectsByType", 
    "parameters": {
      "roid": 2359299,
      "packageName": "ifc2x3tc1",
      "className": "IfcDistributionPort",
      "flat": "true"

returns an array of 7710 elements, while the query:

  "type": {
    "name": "IfcDistributionPort"

executed form gives me the correct amount of elements (2570).

Furthermore, the BIMServer gives this warning while handling the LowLevelInterface request:

giu 28, 2018 11:15:33 AM org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging
AVVERTENZA: Interceptor for {org.bimserver}ServiceInterfaceService has thrown exception, unwinding now
java.lang.ClassCastException: org.apache.cxf.message.MessageImpl cannot be cast to org.apache.cxf.binding.soap.SoapMessage
	at org.apache.cxf.binding.soap.interceptor.SoapHeaderOutFilterInterceptor.handleMessage(
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
	at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(
	at org.apache.cxf.phase.PhaseInterceptorChain.wrapExceptionAsFault(
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(
	at org.apache.cxf.transport.servlet.ServletController.invoke(
	at org.apache.cxf.transport.servlet.ServletController.invoke(
	at org.bimserver.servlets.GenericWebServiceServlet.invoke(
	at org.bimserver.servlets.GenericWebServiceServlet.service(
	at org.bimserver.servlets.RootServlet.service(
	at javax.servlet.http.HttpServlet.service(
	at org.eclipse.jetty.servlet.ServletHolder.handle(
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(
	at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
	at org.eclipse.jetty.servlet.ServletHandler.doScope(
	at org.eclipse.jetty.server.session.SessionHandler.doScope(
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
	at org.eclipse.jetty.server.Server.handle(
	at org.eclipse.jetty.server.HttpChannel.handle(
	at org.eclipse.jetty.server.HttpConnection.onFillable(
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
	at org.eclipse.jetty.util.thread.QueuedThreadPool$
	at Source)

but this seems to be related to the communication part.

The following zip archive contains the IFC file used and both the results given from the BIMServer (version 1.5.96).


This comment has been minimized.


rubendel commented Oct 5, 2018

Just tried this in 1.5.100, the amount of results is correct here with "getDataObjectsByType". Maybe this has been fixed in the meantime or you have a different setup. I also tried this with multiple revisions checked in (since the amount you get is exactly triple the correct amount).

Could you let me know if you still experience this in 1.5.109 or later?

Please note that the "getDataObject*" methods are deprecated and will be removed in a future version.


This comment has been minimized.

GiacomoManzoli commented Oct 5, 2018

We are still using the v1.5.96, and we have found this bug also on other project (without revisions).
I've also tried the 1.5.109 with one of the IFC file which is bugged on the v96 and it worked well.
But, the test was with just a project, and the bug it's quite sneaky since, with the v96 and with the same project, sometimes the call gives the right result, and somtimes 3 times the results.

There will be an altervantive for the getDataObject methods? Our application is heavily based on those calls, since with a single call, we can get all the instances of a given IfcType and all the data related to it.


This comment has been minimized.


rubendel commented Oct 6, 2018

The alternative are is the new filter/query language mentioned earlier in this post. Although the query language is not at all perfect, all the "getDataObject" methods can easily be replaced by them.

Have you used the other low level calls that manipulate data on the server? I can imagine there being bugs in those.


This comment has been minimized.

GiacomoManzoli commented Oct 6, 2018

No, we didn't use the data-manipulation calls, we just read the data from the server with that calls.

About the query language, now i've tested a bit more, and porting our application shouldn't be that painfull. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment