open-dis / opendis7-source-generator Goto Github PK

IFFPdu needs modifications so that Layer 3 information can be added to it. Layer 3 contains Mode 5 information.

Current IFFPdu only supports information for Layer 1 and 2. Current IFFLayer2Pdu extends IFFPdu which does not support to adding layer 3 information into IFFPdu.

Solution idea:

We would like to modify IFFPdu so that a layer information can be added directly to it and the layers do not need to extend IFFPdu.

Basically we would create corresponding data classes for layers 1, 2 and 3. (IffPduLayer1Data, IffPduLayer2Data, IffPduLayer3Data) These data classes would extend AbstractIffPduLayerData. Data classes can then be added to IffPdu via addLayer method. Then later when someone wants to create layer 4 and 5 they can simply create IffPduLayerData classes and add them to IffPdu.

Files that need modifications:

• DistributedEmissionFamilyPdus.xml and JavaGenerator.java
  -- These for IffPdu, AbstractIffPduLayerData, IffPduLayer1Data, IffPduLayer2Data and IffPduLayer3Data
• PduFactory.class on openddis7-java project

Is this solution okay to implement or do you have any suggestions for us how to improve it?

target name="copy-generated-source-to-opendis7-java" copies files to dir="${opendis7-java}/src-generated" that are not generated by JavaGenerator.java and are not found on opendis7-source-generator project src-generated folder. (opendis7-source-generator projects' src-generated folder contains only files generated by JavaGenerator.java.)
-> Confusing moments for developers.

Solutions idea: a new ant target to opendis7-source-generator projects' build.xml for copying files from src-specialcase folder to folder that has the same name in opendis7-java project.

Much refactoring is nearly complete. open-dis7-source-generator products are feeding into the open-dis7-java build.

• https://github.com/open-dis/open-dis7-java

Still needed for release:

• Enumeration low-level package naming normalized and unified,
• better description string and uid value for enumerations,
• better javadoc for enumerations,
• Emitters enumeration currently truncated at 2000 entries to avoid Java "code too large" error,
• reverse lookup from string, possibly other utility methods.

This work is being tested as part of a MOVES graduate course at NPS.

• https://gitlab.nps.edu/Savage/NetworkedGraphicsMV3500

I think there might be an issue with some of the fields being read out / unmarshaled using .readShort(), as this results in high end shorts (>32k) being negative. This could cause a few issues with lookups of enumerations - if they were populated that high.

So far in various simulation tools, I've encountered issues with ElectronicEmitterPdu, EntityStatePdu and the classes used within (EntityID, etc) but I'm sure any part of the standard that references 2-bytes needs to be unsigned, so probably stored internally as an int that's masked (0xFFFF). Some are, but some aren't. Unsure on the lack of uniformity.

Raising this for further discussion on resolution or my use-case. :-)

There is a nasty issue for enumerations, where the enumeration value is initialzed by an integer with leading zeroes (this will be interpreted as an octal number by the compiler), e.g. for MunitionDescriptorFuse, where MULTIFUNCTION should have the decimal value 100, but the constructor in the source is MULTIFUNCTION(0100, "Multifunction"), which gives you a decimal value of 64. To my knowledge this is also valid for MunitionDescriptorWarhead, I have not searched for other cases, as one has to check the whole SISO-REF-010 enumerations.

The current implementation of unmarshaling PDUs performs some enumeration lookups of the extracted values. If the value isn't found, it returns a null. This causes issues later in determining the unmarshalledSize() of the PDU, resulting in a NullPointerException (NPE).

One such scenario is seen in #14. ie: When some of the values are high end shorts (read as negative values), resulting in a failed enumeration lookup (no negative mappings in the enumeration classes), which returns a null for that instance. Later the parent object requests a .getMarshalledSize(), which performs the same thing on all member objects, and as one is a null the method bombs out.

But, as a lot of the Enumerations are filled with holes / incomplete, it's very easy to pull out a value that results in the null.

Example

In BeamStatus.java:getMarshalledSize() :

marshalSize += beamState.getMarshalledSize(); // When `beamState` is not mapped from the enumeration possibilities, this is `null`, resulting in a NPE.

Sure, this particular example should be either on or off, but due to how it is unmarshalled, I've seen other values extracted from the byte. This could be related to the next issue (#7 ) though.

There are other PDUs though, such as the name of an emitter / radio / etc where it may not exist either.

Suggestion

If the mapping is insisted at PDU generation time, perhaps ensure that allgenerated Enumeration classes from the SISO standard (SISO-REF-010-v28 at time of viewing) contain an "unknown"/"invalid"/"other" mapping, and return that instead of null? Some already do, but not all.

Following issue is observable when EntityTypes with domains not equal to PlatformDomain: The unmarhalled domain will always be PlatformDomain (see c'tor of EntityType), unmarshalled with the numerical value of the other enum class.
Here the test:
ByteBuffer buffer = ByteBuffer.allocate(4096);
try {
// marshal/ unmarshal Domain: correct
Domain d = Domain.inst(MunitionDomain.ANTI_ARMOR);
d.marshal(buffer);
buffer.rewind();
d.unmarshal(buffer);
System.out.println(d.getDescription());
buffer.clear();
// marshal/ unmarshal EntityType incorrect for entity types not equal PlatformDomain
EntityType ent = new EntityType();
ent.setEntityKind(EntityKind.MUNITION).setCountry(Country.GERMANY_DEU).
setDomain(Domain.inst(MunitionDomain.ANTI_ARMOR)).setCategory(1).
setSubCategory(1).setSpecific(3);
ent.marshal(buffer);
buffer.rewind();
EntityType et = new EntityType();
et.unmarshal(buffer);
System.out.println(et.toString());
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
which gives following output:
Anti-Armor
EntityType entityKind:EntityKind 2 MUNITION domain:Air country:Country 78 GERMANY_DEU category:1 subCategory:1 specific:3 extra:0
where the MunitionDomain.ANTI_AIR is now PlatformDomain.AIR as PlatformDomain.unmarshal was called despite having EntityKind.Munition.

Hi again Don @brutzman,

I have noticed the TransmitterPdu class extracts the RadioID field (ref) once inside the header field (see RadioCommsHeader class), and again separately in the radioNumber field. this causes an unnecessary shift of unmarshalling by 2 bytes. Removing it from the RadioCommsHeader class fixes the problem, but so does commenting out the local field to the TransmitterPdu class, and redirecting all calls to get/set of the RadioID to the embedded RadioCommsHeader instance's field. I'm not sure which way you want to go.

Let me know if you're the best POC, or if there's a preferred approach to raising these issues.

Look at approach used by IFF updates, determine best pattern for hashCode() methods in key Pdu methods.

This is related to issue #8.

Hi!

I used the generated C++ bindings from open-dis-cpp to get started on a project and they work great! But I need some changes. So I was just about to fork XMLPG and start making the changes I need, but then I found this project.

1. I gather this project intends to replace XMLPG but is still in development. Is that right?
2. The README in this repository only describes generating Java code, but there exist generators for other languages. Which languages are supported?
3. What is the state of the project for generating C++? Should I just continue with the XMLPG for now, if I need C++ marshaling / un-marshaling for DIS messages?

Thanks so much, and congrats on the useful libraries!

If I understand correctly, I believe the ElectronicEmitter class is missing a 16-bit/2-byte padding field between numberOfBeams and emitterSystem that is missed during (un)marshalling (ref):

ie:

public int unmarshal(DataInputStream dis) throws Exception
{
    int uPosition = 0;
    try 
    {
        systemDataLength = (byte)dis.readUnsignedByte();
        uPosition += 1;
        numberOfBeams = (byte)dis.readUnsignedByte();
        uPosition += 1;
        dis.readUnsignedShort(); // missing this 2-byte padding buffer.
        uPosition += 2;
        uPosition += emitterSystem.unmarshal(dis);
        uPosition += location.unmarshal(dis);
        for(int idx = 0; idx < numberOfBeams; idx++)
.
.
.

... and in here:

public void marshal(java.nio.ByteBuffer byteBuffer) throws Exception
{
   byteBuffer.put( (byte)systemDataLength);
   byteBuffer.put( (byte)beams.size());
   byteBuffer.putShort((short)0); // needs to insert the (empty) padding field of the PDU.
   emitterSystem.marshal(byteBuffer);
   location.marshal(byteBuffer);
.
.
.

... and in the corresponding ByteBuffer methods for marshalling and unmarshalling too.

Testing latest release exposed some new issues, reported to [email protected] mailing list.

Overrides currently in place:

1. Asked about warnings from empty XML children.

2. <subcategory value="31" description="Hz 21\24 Fast Bridge" includes a backslash character, which is problematic and needs to be forward slash

3. <enumrow value="2147483648" description="Rectangular Volume Record 4 value reduced by 1 as 2147483647 in order to remain a valid Java int

A "hyphen-ectomy" is planned, we are preparing to rename project from

• open-dis7-source-generator
  to
• opendis7-source-generator

This simplification with lead to more consistency in deliverables without reducing capabilities. This only applies to the "7" series of codebases using the XML program generator.

• opendis7-source-generator (mature)
• opendis7-java (mature)
• opendis7-python (in preparation)

Generated equalsImpl methods do unsafe checks for OBJECT_LIST type attributes. Method will throw IndexOutOfBoundsException when other object list is shorter that this object list. Equals method should not throw exceptions, list sizes should be compared before trying to access variables in the list.