0000736: Wildcards in NED-import can leave out module interfaces

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000736

OMNeT++

simulation kernel

public

2014-02-24 14:25

2016-04-12 16:02

Reporter

woife

Assigned To

andras

Priority

normal

Severity

minor

Reproducibility

always

Status

resolved

Resolution

fixed

Platform

OS Version

Product Version

4.4

Target Version

Fixed in Version

5.0

Summary

0000736: Wildcards in NED-import can leave out module interfaces

Description

When constructing compound modules in the NED editor, sometimes an import like "import some.path.in.my.project.*" 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:
---------------------------------
Playground
   simulations
      MySimulation
         MySimulation.ned
   src
      BasicNode
         BasicNode.ned
      Part
         IPart.ned
         MyPart.ned
         MyPart.cc
         MyPart.h
      ExtendedNode.ned

---------------------------------
Module description:
---------------------------------

IPart.ned contains only a single moduleinterface definition
MyPart.ned is a dummy module that implements that interface (MyPart.cc 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.

Tags

No tags attached.

Attached Files

Playground.zip [^] (10,377 bytes) 2014-02-24 14:28

Relationships

Notes
(0000908) woife (reporter) 2014-02-24 14:28	The attached file "Playground.zip" contains the example as described in the bug description.

(0001052) 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.

(0001203) anwei (reporter) 2016-04-04 11:09	I can confirm this issue for OMNeT++ v5.0RC build 160310-9ee11db.

(0001210) 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: Playground.zip
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