Introduction
SAP Cloud Platform Integration would soon migrate to new runtime container ( Java 😎 . This might cause some inconsistencies of behavior for the customer/partner developed Adapters. Adapter Development Kit (ADK) allows users to create a custom adapter which can be deployed onto cloud integration tenants. There are multiple custom adapters already developed by customers and partners. These adapters are currently being deployed and processed on a container based on Java 7. However, during the movement to new runtime it was essential to check if these adapters will run without any problems. During this activity it was seen that some modifications were required to some of the adapters to run them on new runtime. So, this blog provides the information about the known issues and resolutions when moving an existing adapter to new runtime.
Why this Difference?
Each module (bundle or Subsystem) has its own class loader. Based on the wiring directive (import/export statements in MANIFEST), the platform creates a delegation network between the various modules. For example a bundle 'xyz' requires the 'org.xml.sax'. Then the boot delegation wires the java rt component with bundle xyz (so to speak). The java runtime classes loading ideally should take an exception because they are part of java runtime and pretty much all modules will need them and hence they are made available by the platform implicitly. Hence java packages are considered implied imports and are loaded even though they are not declared as "import-package" in the MANIFEST. For loading these fundamental classes the platforms use "parent delegation" instead of networking module. That is the class loader used to bootstrap the OSGi frame work itself will be used to load these java classes.
In summary, a class loaded via boot delegation of the platform does not need to be explicitly imported (via MANIFEST instruction); any other class loading has to follow Framework networking/wiring approach by declaring explicit imports in the MANIFES.
The old runtimes boot delegation is more wider than that of the new runtime. The new runtime has strict OSGi spec following and hence only java.* packages (OSGi mandates only these classes) are part of boot delegation where the old runtime has included some more like javax.*, org.xml.sax, etc.
Since SAP Cloud Platform Integration plans to move to the new runtime, this affects the content of SAP Cloud Platform Integration which are integration flows and custom adapters. This means custom adapters may have to be updated to run on the new runtime.
Known Issues
Missing Import Package: javax.net.ssl
Symptom:
Error message:
missing requirement org.apache.aries.subsystem.core.archive.ImportPackageRequirement:
namespace=osgi.wiring.package, attributes={},directives={filter=(&(osgi.wiring.package=javax.net.ssl)(version>=0.0.0)),resolution=mandatory}
The above error is found in the trace after the adapter is deployed and it can occur for any package which is not provided by the new runtime's core bundle.
Solution:
The Solution requires the import packages which are missing in the bundle's manifest file. So, to solve the above error, you need to rebuild the bundle with "javax.net.ssl" specified in the Import-Package of the manifest.
- Multiple Dependency Chains:
Symptom:
While solving the above missing packages, it is also necessary to check for any erroneous scenarios. In some cases, the adapter deployment might result in error stating a package has been exposed via two dependency chains.
Eg:- Consider a case where you have already included a library which exports a package ‘xyz’ in your subsystem. Now while moving to new runtime, if you start importing the package ‘xyz’ in your bundles, you might face this error.
Solution:
Remove the bundles which are redundant.
Note:
Another important point to note here is that the dependency issues after moving to new runtime can occur only during runtime and not during deploy time. So, it is necessary to test the runtime with all scenarios.
Identifying and Updating Custom Adapters
For identifying all deployed custom adapters on your tenant, please follow the below screenshot. All the artifacts of type "SUBSYSTEM" are the custom adapters.
In case you have done any modification to the adapter or received the latest version of the adapter, you can then deploy it through Eclipse. Please refer the below screenshot.
After deployment of the adapter, please re-deploy the corresponding integration flows.
- SAP Managed Tags:
