BIMserver
BIMserver copied to clipboard
Unable to checkin IFC-file :: class java.util.ArrayList cannot be cast to class java.lang.Long
Error occurs when checking in a specific file on bimserver 1.5.182.
2022-08-24 09:33:20,529 INFO [pool-1-thread-7] o.b.d.b.BerkeleyKeyValueStore [BerkeleyKeyValueStore.java:615] writes: 59000000, 688 ms sync
2022-08-24 09:33:25,654 ERROR [pool-1-thread-7] o.b.l.LongAction [LongAction.java:196] [null] [process.ifc] class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap') org.bimserver.shared.exceptions.UserException: [process.ifc] class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap')
I can share the file by request..
If you are sure that the file is valid, please write an email to [email protected]. I will provide you with a private upload link. If the file is small, you can of course just attach it to the email.
Thanks for sharing the file. I could isolate the issue, but have not yet fully solved it. The reason is an IfcIndexedPolyCurve
with a style attached via IfcStyledItem
. The representation item (curve) does not reference the style, but vice versa via the attribute IfcStyledItem.Item
. First, all entities are processed and saved to the database on the fly. Here, the curve is first saved to the database without complaint. Then, inverses are resolved and saved to the DB as well. Thus, in the second step the curve's inverse attribute IfcIndexedPolyCurve.StyledByItem
is set to the style and the curve is saved again (overwritten). That is the point where the attribute IfcIndexedPolyCurve.Segments
fails to save - although it must have been saved properly before. The methods used by DatabaseSession.save
and DatabaseSession.saveOverwrite
are largely the same - they both call VirtualObject.write
eventually. I have yet to find the difference that makes the failure. Will keep investigating.
Here are two sample files and the full stacktrace:
- bs-1268-1.ifc.txt curve without style (flawless)
- bs-1268-2.ifc.txt same curve with style (fails)
org.bimserver.shared.exceptions.UserException: [bs-1268-2.ifc] class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap')
at org.bimserver.database.actions.StreamingCheckinDatabaseAction.execute(StreamingCheckinDatabaseAction.java:412)
at org.bimserver.database.actions.StreamingCheckinDatabaseAction.execute(StreamingCheckinDatabaseAction.java:84)
at org.bimserver.database.DatabaseSession.executeAndCommitAction(DatabaseSession.java:775)
at org.bimserver.database.DatabaseSession.executeAndCommitAction(DatabaseSession.java:752)
at org.bimserver.longaction.LongStreamingCheckinAction.execute(LongStreamingCheckinAction.java:73)
at org.bimserver.longaction.LongActionManager$1.run(LongActionManager.java:55)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassCastException: class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap')
at org.bimserver.shared.HashMapVirtualObject.writePrimitiveValue(HashMapVirtualObject.java:450)
at org.bimserver.shared.HashMapVirtualObject.writeWrappedValue(HashMapVirtualObject.java:308)
at org.bimserver.shared.HashMapVirtualObject.writeList(HashMapVirtualObject.java:383)
at org.bimserver.shared.HashMapVirtualObject.write(HashMapVirtualObject.java:241)
at org.bimserver.database.DatabaseSession.saveOverwrite(DatabaseSession.java:2336)
at org.bimserver.shared.HashMapVirtualObject.saveOverwrite(HashMapVirtualObject.java:631)
at org.bimserver.database.actions.GenericCheckinDatabaseAction.fixInverses(GenericCheckinDatabaseAction.java:423)
at org.bimserver.database.actions.StreamingCheckinDatabaseAction.execute(StreamingCheckinDatabaseAction.java:217)
... 10 common frames omitted
Update: the difference is that first round of VirtualObject.save()
is called on ByteBufferVirtualObject
, second round on HashMapVirtualObject
. The latter does not respect the multiplicity of the wrapped value. This is quite an edge case. There are only three types IfcLineIndex
, IfcArcIndex
and IfcComplexNumber
with similar model constructions. And they only become problematic when used as attributes types where sibling inverse attributes are becoming effective.
Edit: There are also IfcCompoundPlaneAngleMeasure
and IfcPropertySetDefinitionSet
.
Here is a sample for IfcComplexNumber
: bs-1268-3.ifc.txt. This fails already during deserialzation. After the deserializer error is fixed, it may expose the same issues as described here.
I sendt you a new export from Archicad. This was exported without footprint geometry and it loads without problems. I can not see any obvious changes to the file, except it`s now 75 mb.
I sendt you a new export from Archicad. This was exported without footprint geometry and it loads without problems. I can not see any obvious changes to the file, except it`s now 75 mb. This is a ok workaround for our use case.
Touchpad accident there..
The issue is rooted in styled curves which are only contained in footprint geometry. In that case, we have lines with color and thickness specified. Without footprint geometry, styles are only applied to 3D representation items, which may be constructed of curves, but the styling is applied to the 3D items instead of the curves.
The increase in file size may be due to additional changes in export settings like switching from design to reference view.
Thank you very much for looking into the issue!
Hi,
It is now (1.5.184) possible to checkin files with the feature you mention above. I do however get an empty result when requesting a download, querying IfcApplication (in this case).
It is now (1.5.184) possible to checkin files with the feature you mention above.
How is that possible? I had not committed the fixes because they are still unfinished. Are you sure these very features are present in your file at hand? Or are you looking at a different issue?
I`m not sure if this is the same issue. I sendt you the file in question.
This was a mistake on my part. Sorry for the inconvenience!
I have the same issue. Is there any commit, in which is the issue fixed, please?
Unfortunately, I have half a solution, but nothing ready to commit yet.
And is there any way I could help with the solution?