Use of Libraries

As of version 2.5 of ApiOmat, it is possible to use libraries in native modules independently from the library version used by ApiOmat for a lot of internally used libraries. This means, on the one hand, that you now have to provide some implementation libraries, which weren't necessary before, as they were delivered by ApiOmat, for the corresponding API libraries you use. An example for that is the javax-mail-api library, which provides the necessary interfaces. Until version 2.5 you were bound to use javax.mail-api in version 1.4.5 and you didn't have to add javax.mail-mail as we provided it. After ApiOmat version 2.5, you'll have to add javax.mail-mail by yourself. On the other hand, you're not bound to the specific version anymore and there should be no problems if you use, for example, a newer version. Be aware that some libraries we use internally (such as spring or morphia and the mongodb driver) also cannot be used in native modules, as this would lead to linkage errors. In that case, you have to switch back to the old behaviour by setting the property yambas.useOldClassloader to true in your apiomat.yaml.

Anyway, there are limitations on some libraries, which cannot be replaced with another version.

Any library (and its contained classes) that we provide by default with the native module (beside our own libraries "anttask" and "nativemodule-base", it is the jersey-core library in version 1.19, jsr311-api in version 1.1.1, servlet-api in version 2.5 and swagger-annotations in version 1.5.12) can not be replaced or overriden by another library, as yambas interprets the contained classes internally. They're some kind of interface between yambas and the native-module code and therefore there can't be more than one implementation of the classes.

This means that you cannot use another version of jersey-core (or child projects that depend on jersey-core, such as jersey-client), as we're providing this library. For example, jersey-core 1.19 uses a class "javax.ws.rs.core.Response", which is provided by jsr311-api (1.1.1). The successor package "jersey-common" defines in version 2.8 a dependency on the library "javax.ws.rs-api" (version 2.0) which also provides a class "javax.ws.rs.core.Response" with a different implementation. If you use this library in your native module, this may either lead to compile errors, errors on the runtime of the module or unexpected behavior, as Yambas will always use our own version for these libraries.

List of currently known libraries, where other implementations will lead to compile or linkage errors:

• jersey-core

• mongodb and morphia

• springframework

• jackson

Thus, if you have to use one of these, you should step back to the old classloader behaviour by setting the property yambas.useOldClassloader to true in your apiomat.yaml

Working with URL-objects created by the module classloaders getResource-methods

If you're requesting a resource in your module with the getResource-method, we will create a URL object for the requested resource. The object contains it's own handler to process our own protocol, which we need, as we're not storing the modules on a local filesystem. Nevertheless you can open a stream on the object, get it's contents and so on. What you can't do, due to a bug in the jdk, is to get the plain url string and create a new URL object with this string.

Therefore it is currently not possible to pass the URL resource to the constructor of a SOAP service which had been created by the apache cxf library, as the library will internally store the plain URL string and pass it later to the used xerces library to create a new URL object.

Deleting Classes only "Code-First"

If you upload a native module at least one time (or do a "make native"), it isn't possible anymore to delete a class over the dashboard. This has a technical background: As we merge the code of your deployed artifact (where the class is still present) with the modelled classes (where you deleted the class) you create over the API/Dashboard, the class will be present again after compilation. The reason for that behavior is, that we try to ensure to keep your code compilable. If you delete a class which is still referenced somewhere, like in a hook method, we cannot change the code of this class. So we need to keep it and leave the decision of deleting a class by a developer who needs to remove it and build and deploy it locally.