Actifsource-ClassPathContainer Error on new Plugin-Projects
Posted: Fri Sep 21, 2012 9:02 amAfter using the PDETool to convert an actifsource JavaProject using the contextment, you will end up getting an errormaker on the project telling that the actifsource-ClassPathContainer cannot be used together with plugin-projects.
The reason for this is the way classloading works when using plugins. Having the actifsource container on a plugin-project leads to case where the same class is loaded by different classloaders. Classes loaded by different classloader are considered to be different class even if there bytecode and url is the same. Depending on which classes are used in a project and how they are related to each other, it is likely to result in some wired classloading exception like:
java.lang.LinkageError: loader constraint violation: loader (instance of java/net/URLClassLoader) previously initiated loading for a different type with name "pkgname/ClassName"
Other exceptions are ClassCastExceptions and Assertions checking for assignment compatibility. To reduce such cases, the best thing one can do is managing the classpath completely by the OSGI-Framework. As a first step to solve this issue you have to remove the classpath-container from the jdt buildpath:
If you haven’t added the required actifsource plugin dependencies before, you will get some compilation errors:
Open the manifest editor to add the dependencies:
In manifest editor you have to switch to the “Dependencies” tab on the bottom of editor. Now you have to add the required actifsource-plugins. The name of the plugin is always a prefix of the missing package:
After adding a dependency you have to save the editor in order to apply the changes. Assuming you haven’t disabled the “Project/Build Automatically” option, Eclipse will automatically update the buildpath and rebuild the project. Continue adding additional dependencies until all “ch.actifsource”-references are satisfied. Additional to the actifsource related errormarkers you may also have to add the dependencies to your metamodel-project. Note that a plugin-project cannot have a direct dependency to a non-plugin project. In such a case you always have to either convert the other project to a plugin-project as well or add it as a jar-library to the plugins classpath. Adding a jar-library is done via the Runtime-Tab in the ManifestEditor. However we strongly recommend using the first approach. If you don’t have any choice, you should at least follow the rule to do this exactly for one plugin and refer to this plugin where you need that jar. Failing to do so will risk the classloading error again, because the OSGI-Framework only solves the problem referring to same plugin in classloading hierarchy, but not the issue of duplicate jars in different plugins.
When you have finished these steps you might have a warning on the “build.properties”-File. You can easily fix this by opening the “build-properties”-Tab in the ManifestEditor and click on the lightbulb. Now you can choose a fix. Most often it is the “src-gen” folder missing from the source-property:
- Actifsource-ClassPathContainer Error
- classpath_container_can_not_be used.png (11.34 KiB) Viewed 35011 times
The reason for this is the way classloading works when using plugins. Having the actifsource container on a plugin-project leads to case where the same class is loaded by different classloaders. Classes loaded by different classloader are considered to be different class even if there bytecode and url is the same. Depending on which classes are used in a project and how they are related to each other, it is likely to result in some wired classloading exception like:
java.lang.LinkageError: loader constraint violation: loader (instance of java/net/URLClassLoader) previously initiated loading for a different type with name "pkgname/ClassName"
Other exceptions are ClassCastExceptions and Assertions checking for assignment compatibility. To reduce such cases, the best thing one can do is managing the classpath completely by the OSGI-Framework. As a first step to solve this issue you have to remove the classpath-container from the jdt buildpath:
- Remove From BuildPath
- remove_from_buildpath.png (28.24 KiB) Viewed 35011 times
If you haven’t added the required actifsource plugin dependencies before, you will get some compilation errors:
- Missing Dependencies
- missing_dependencies.png (20.91 KiB) Viewed 35011 times
Open the manifest editor to add the dependencies:
- Open ManifestEditor
- open_manifest_editor.png (25.46 KiB) Viewed 35011 times
In manifest editor you have to switch to the “Dependencies” tab on the bottom of editor. Now you have to add the required actifsource-plugins. The name of the plugin is always a prefix of the missing package:
- Add Dependencies
- add_dependencies_using_manifest_editor.png (61.35 KiB) Viewed 35011 times
After adding a dependency you have to save the editor in order to apply the changes. Assuming you haven’t disabled the “Project/Build Automatically” option, Eclipse will automatically update the buildpath and rebuild the project. Continue adding additional dependencies until all “ch.actifsource”-references are satisfied. Additional to the actifsource related errormarkers you may also have to add the dependencies to your metamodel-project. Note that a plugin-project cannot have a direct dependency to a non-plugin project. In such a case you always have to either convert the other project to a plugin-project as well or add it as a jar-library to the plugins classpath. Adding a jar-library is done via the Runtime-Tab in the ManifestEditor. However we strongly recommend using the first approach. If you don’t have any choice, you should at least follow the rule to do this exactly for one plugin and refer to this plugin where you need that jar. Failing to do so will risk the classloading error again, because the OSGI-Framework only solves the problem referring to same plugin in classloading hierarchy, but not the issue of duplicate jars in different plugins.
When you have finished these steps you might have a warning on the “build.properties”-File. You can easily fix this by opening the “build-properties”-Tab in the ManifestEditor and click on the lightbulb. Now you can choose a fix. Most often it is the “src-gen” folder missing from the source-property:
- Fix build.properties
- fix_build.properties.png (18.71 KiB) Viewed 35011 times