OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000736OMNeT++simulation kernelpublic2014-02-24 14:252016-04-12 16:02
Assigned Toandras 
PlatformOSOS Version
Product Version4.4 
Target VersionFixed in Version5.0 
Summary0000736: Wildcards in NED-import can leave out module interfaces
When constructing compound modules in the NED editor, sometimes an import like "import*" will not import a module interface defnition even if the module interface is defined in a file like "some/path/in/my/project/Interface.ned".

To reproduce the error, I have constructed a small example project called "Playground", that looks like the following:

Module hierarchy:

Module description:

IPart.ned contains only a single moduleinterface definition
MyPart.ned is a dummy module that implements that interface ( and MyPart.h are the default files for simple modules)
BasicNode is a compound module that has a submodule with interface type IPart
ExtendedNode is a compound module that extends BasicNode, without adding anything to it.

MySimulation contains exactly a single module "Foo" of type "BasicNode".
Notice that there is not a single instance of "ExtendedNode" referenced in the simulation!

BasicNode contains the line "import playground.Part.*;"

Simulation behaviour:

In the NED editor, everything looks fine, the IDE knows which interace I use as I can double click the icon and I get directly to IPard.ned.

But when I start the simulation, i get the following error:

<!> Error in module (cCompoundModule) MySimulation.Foo (id=2) during network setup: Submodule Part: cannot resolve module interface `IPart', at /main/Software/OMNeT++/omnetpp-4.4/samples/Playground/src/BasicNode/BasicNode.ned:14."

If I carry out on of the following two steps, the problem disappears:

1) Explicitly import the interface:

If I write
    import playground.Part.IPart;
    import playground.Part.*;
instead of just

    import playground.Part.*;
in the BasicNode.ned file, then the simulation can start correctly.

2) Don't extend BasicNode:

If I remove the "extends BasicNode" from the ExtendedNode definition, the simulation also works. As already mentioned, ExtendedNode.ned just exists, but it is not referenced anywhere.
TagsNo tags attached.
Attached Fileszip file icon [^] (10,377 bytes) 2014-02-24 14:28

- Relationships

-  Notes
woife (reporter)
2014-02-24 14:28

The attached file "" contains the example as described in the bug description.
sdominiak (reporter)
2015-09-11 15:58

I can report the same behavior happened to me with OMNeT++ v4.6. Workaround 0000001 described in the description fixed the problem.
anwei (reporter)
2016-04-04 11:09

I can confirm this issue for OMNeT++ v5.0RC build 160310-9ee11db.
andras (administrator)
2016-04-12 16:02

Fixed. cNEDLoader::registerNedType() didn't invalidate the nedTypeNames[] cache.

- Issue History
Date Modified Username Field Change
2014-02-24 14:25 woife New Issue
2014-02-24 14:28 woife File Added:
2014-02-24 14:28 woife Note Added: 0000908
2015-09-11 15:58 sdominiak Note Added: 0001052
2015-10-12 09:28 ammmar1988 Issue cloned: 0000841
2016-04-04 11:09 anwei Note Added: 0001203
2016-04-12 16:02 andras Note Added: 0001210
2016-04-12 16:02 andras Status new => resolved
2016-04-12 16:02 andras Fixed in Version => 5.0
2016-04-12 16:02 andras Resolution open => fixed
2016-04-12 16:02 andras Assigned To => andras

Copyright © 2000 - 2022 MantisBT Team
Powered by Mantis Bugtracker