JEAF Generator Error Codes

Description

JEAF Generator expects a specific version of the so called JEAF Meta Model (JMM). The JMM version that is used by your UML model seems to be outdated. Please upgrade to latest version of JMM.

When working with OpenAPI and REST there are some restrictions concerning the data types that can be used in Java. This warning tells you that in a specific REST operation a incompatible parameter or return type is used. This will lead to an invalid request / response from an OpenAPI perspective.

Depending on how you export XMI files from your MagicDraw UML model, it might happen that the files contain information about file systems paths. This should not be an issue on the machine where you exported the files. However, it may lead to problems on other devices or your CI/CD infrastructure where file system paths might not be the same.

When working with OpenAPI and REST there are some restrictions concerning the data types that can be used in Java. This warning tells you that in a defined «BeanParam» at least one property uses an incompatible type. This will lead to an invalid request / response from an OpenAPI perspective.

When defining the path of a REST resource then the path that is defined on the «RESTResource» (not «RESTOperation») must start with a '/'.

The resource path of an «RESTOperation» is the combination of the path of the «RESTResource» and the «RESTOperation». However at least one of them has to be defined.

The path of a «RESTOperation» must not start with '/'.

Each «RESTOperation» must define at least one HTTP method. If this message occurs then you have to fix your UML model.

The «RESTOperation» uses a HTTP status code that is not compatible with JAX-RS standard.

The supported consumed media types can either be defined on the «RESTResource» or on the «RESTOperation» but at least on one of them the information has to be defined.

The produced media types can either be defined on the «RESTResource» or on the «RESTOperation» but at least on one of them the information has to be defined.

All input parameters of a «RESTOperation» must have a name. Please fix the issue in your UML model.

All input parameters that are not explicitly marked as «HeaderParam», «PathParam», «BeanParam» etc. are treated as body. However REST only supports one body per request. So please ensure that there is not more than 1 body per request.

A «RESTOperation» defines a body parameter, however it's HTTP method does not allow to use a body.

It's not allowed to have more than 1 global error response for an OpenAPI specification in an UML model.

«OpenAPIResponse» types need to define exactly one response type

«OpenAPIDataType» must have 1 property as long as they are not modeled as composite data types.

«OpenAPIDataType» must only have primitive types of properties, as long as they are not modeled as composite data types.

«OpenAPIDataType» must not have multi valued properties, as long as they are not modeled as composite data types.

«OpenAPIDataType» must not have parent classes.

When defining a «PathParam» for a «RESTOperation» it is required that path parameters are required.

«PathParam» must not be defined as multi valued in the UML model.

It is strongly recommended that the elements of the UML model have a meaningful documentation ;-)

When working with so called composite data types then inheritance is not supported for them.

When modeling attributes in UML it is important that they also have a type. If a type is not defined then code generation is not possible.

When modeling attributes and associations then it is required that they also have a type. If it is not defined then code generation is not possible.

When modeling operations of services it is required that they also have a return type. Also case "void" has to be defined in UML model. In addition multi valued primitive types are not supported as return types.

When modeling parameters of operations it is required that they also have a name. If there are input parameters without a name then code generation is not possible.

When modeling methods also a return type is required not only for methods that really return something but also in case of "void". If a method does not define a return type then code generation is not possible.

When modeling method then they also have to have a name. Otherwise code generation is not possible.

All parameters within the UML model need to have a type. Otherwise code generation is not possible.

When modeling activities you have to ensure that each «JEAFActivity» does not have more than one return parameter.

When modeling «JEAFComponents» you have to ensure that each component has defined a layer.

Class that are modeled as «PersistentObject» must have a so called "class id" with a value greater zero.

When modeling persistent classes and their associations it is required that either both ends of an association have applied stereotype «Role» or none of them.

When modeling associations between classes then it is required that navigable associations ends have set a role name. Otherwise code generation is not possible.

«ObjectMapping» is invalid according to the error message

Minimum value for for Java Bean Validation «DecimalMin» is missing.

For a specific Java Bean Validation a string-based or numeric target type is expected.

Maximum value for for Java Bean Validation «DecimalMax» is missing.

For a specific Java Bean Validation a numeric target type is expected.

When working with Java Bean Validation «Digit» then the integral and fractional digits have to be defined properly.

When working with Java Bean Validation «Digit» then the integral and fractional digits have to be defined properly.

When working with Java Bean Validation «Size» then its minimal size has to be set properly.

When working with Java Bean Validation «Size» then its maximum size has to be set properly.

When working with Java Bean Validation «Size» maximum size has to be greater or equal to minimum size.

When working with Java Bean Validation «Size» then at least minimum or maximum size has to be set.

For a specific Java Bean Validation a String, Collection and Map target type is expected.

When working with Java Bean Validation «Pattern» then a regexp pattern has to be set.

For a specific Java Bean Validation a String target type is expected.

For a specific Java Bean Validation a boolean target type is expected.

For a specific Java Bean Validation a date target type is expected.

Special stereotype «Ignore» can be used to explicitly exclude model elements from code generation. However this mechanism is intended to be a workaround / short term solution and not a permanent one ;-).

Proper solution to this is to clean up your UML model. That's why a warning is shown during code generation.

OpenAPI standard defines that for whatever reason some header fields should not be mentioned in the OpenAPI specification e.g. Authorization header.

However from an overall perspective it still might make sense to explicitly model them e.g. if these fields are still required in Java code.
Putting it all together in very most cases this warning can be ignored and is only generated to emphasis that these headers did not get "forgotten" in generation of OpenAPI specification but are not added by intention.
For further details please also refer to https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#parameterObject

JEAF Generator supports to mark various elements in the UML model as deprecated. This information is also added to the generated code and OpenAPI specification.
However, there are cases where OpenAPI does not allow to mark an element as deprecated. Namely this is the case for single valued references to other complex types like a 0..1 association to another object. In this case the generated Java code will still contain the deprecation but the OpenAPI specification will not have "deprecation: true". Instead only as comment inside the file is created.

Example:

JAX-RS specification only allows to use java.util.List, java.util.Set or java.util.SortedSet for header params but not java.util.Collection. Please fix your UML model so that either List, Set or SortedSet is used for multi valued header fields.

JAX-RS specification only allows to use java.util.List, java.util.Set or java.util.SortedSet for query params but not java.util.Collection. Please fix your UML model so that either List, Set or SortedSet is used for multi valued query params.

JEAF Generator supports to also make the public representation of a composite data type visible internally. To do so, a property has to be marked with stereotype «CompositeDataTypePublicField». In addition it is required that the property is of type String.

JEAF Generator supports so called soft links. They can be used to modularize your model without loosing information about real types. One possibility when using soft links is to use so called custom generic soft links. In this case you can define your own type that should be used to represent the soft link association. This type, however has to be configured in JEAF Generator Maven Plugin.

JEAF Generator supports so called OpenAPI Data Types. They can be used a strong type representation for basic types. For OpenAPI Data Types it is strongly recommended that they are immutable.

And model element can either be marked with stereotype «POJO» or «ServiceObject» but not both of them a the same time.

If a model element is marked as deprecated also a description, a "since" flag and the planned removal date of the deprecation should be provided so that consumers of the classes, services etc. can prepare.

If a model element is marked as composite data type then a name for the public field representation is required to be set in the model.

In case that a class has one or more bidirectional associations it is not possible to generate equals() and hashCode() as it requires some business knowledge to do so. If equals() and hashCode() are required for such a class then it has to be implemented manually.

JEAF Generator supports so called soft links. They can be used to modularize and decouple your application. Due to that it does not make sense to use them in combination with bidirectional associations.

A REST operation path defines one or more path params but not all of them are also present as parameters in the defined REST operation

A REST operation defines path parameters that are not defined on the operations paths as parameters