Here I am getting below error while connect using HttpPost,
Caused by: java.lang.LinkageError: loader constraint violation: loader
(instance of org/jboss/osgi/framework/internal/HostBundleClassLoader)
previously initiated loading for a different type with name
"org/apache/http/client/methods/HttpPost"
And I am using OSGI bundle so I have added all required dependent files.
So can anyone help me to resolve it?
The Java language is based on a single namespace. That is, the language is built around the concept that a class name is used only once. Classloaders were designed to load code over the internet but accidentally allowed the same class name to be used by 2 class loaders.
In OSGi, each bundle has a class loader that directly loads the classes from its own bundle but uses the class loader of other bundles for any imported classes.
In such a mesh of class loaders, you get the situation that you can load a class C from a Bundle that references a class X and a class Y loaded from other class loaders. Since they have different names that is ok. However, X could refer to class Z and Y could refer to Z, and they could come from different loaders. The original class C from Bundle A, therefore, can see Z from two different class loaders. And is a Linkage Error.
This mesh of classloaders works very well when all bundles are correct, you should never get this kind of errors when you do not hack your bundles. These errors are inevitably caused by complex setups that do not follow the OSGi rules and maintain the Bundle's manifest by hand.
In this case, the class name that can be seen multiple times is org.apache.http.client.methods.HttpPost. So you have a setup where there are multiple bundles exporting this class, which is the first place to look. Since you could start the bundle, the metadata is wrong. OSGi has special metadata that makes this error detected before you start the bundle, the so-called uses constraints.
On Apache Felix, you get an extensive analysis of the problem. If you could run your code on Apache Felix, that would be the easiest route. Looking at your error, you seem to be running on JBoss. They always have played a bit loose with the OSGi rules to make it easier to run enterprise software. Software that rarely does the work to provide OSGi metadata and is well known for its class loader hacks. (A lot of people are only after the Java Module System starting to understand what OSGi was doing and needed.)
Related
The class file DTDScanner, DocumentScanner is loading from two jar files com.ibm.ws.webservices.thinclient_8.5.0.jar (supplied by application through WEB-INF/lib) and com.ibm.ws.xlxp.1.5.3_1.0.16.jar supplied by Liberty profile liberty. These class file have java.lang.LinkageError: loader constraint violation because it is loaded by two different class loader.
Liberty Version : 17.0.0.1 Liberty - (17.0.0.1-cl170120170227-0220)
Here is the error
java.util.concurrent.ExecutionException: java.lang.LinkageError: loader constraint violation: when resolving method "com.ibm.xml.xlxp2.scan.util.EntityManager.<init>(Lcom/ibm/xml/xlxp2/scan/util/EntityManager$EntitySupport;Lcom/ibm/xml/xlxp2/scan/DocumentScanner;Lcom/ibm/xml/xlxp2/scan/util/SymbolTable;Lcom/ibm/xml/xlxp2/scan/util/ParsedEntityFactory;)V" the class loader (instance of com/ibm/ws/classloading/internal/AppClassLoader) of the current class, com/ibm/xml/xlxp2/scan/DTDScanner, and the class loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) for the method's defining class, com/ibm/xml/xlxp2/scan/util/EntityManager, have different Class objects for the type com/ibm/xml/xlxp2/scan/DocumentScanner used in the signature
[4:54]
How to load all the jar files in a single classloader if there is an need?
The thin client jars are not designed to be packaged within a Java EE application - they're intended for (as the name implies) standalone thin clients, providing some WebSphere APIs for use in those environments. Including them is going to produce a lot of class duplication between the server and your application, and LinkageErrors are a common side effect of that kind of duplication. Removing that jar from your app (it shouldn't contain anything that's not in the server itself) should resolve the issue.
If I have a dependency of scope 'test' that is not an OSGi bundle, should I expect pax-exam to simply incorporate it in the probe bundle, or do I need to explicitly wrap it?
I have a case where neither approach is working., and I'm trying to diagnose the problem.
The probe bundle only includes the classes from the class path component containing the test class (usually just what's in src/test/java of your project).
You can customize the probe, or simply provision your test dependencies as separate bundle. The probe imports all packages dynamically.
I am interested in this question due to the problem I described here. How does Glassfish look for the required classes anyway? Suppose there are two libraries in pom.xml of the application (in dependencies), one is declared with scope provided, another is declared with standard scope.
Therefore, I have two libraries - A.jar is in Glassfish lib folder, B.jar is in WEB-INF/lib of the war module that I deploy.
What is the order of resolving the dependencies here? I assume that:
First look in the WEB-INF/lib folder if any jar matches the class.
After that look in Glassfish/lib folder if any jar matches the class.
Is that correct? Is the situation when class in A.jar refences a class in B.jar, legal for such a configuration, and vice versa?
To be more specific, I have Glassfish 2.1.
According to class loader documentation for GF2 I would say vice versa.
Note that the class loader hierarchy is not a Java inheritance hierarchy, but a delegation hierarchy. In the delegation design, a class loader delegates class loading to its parent before attempting to load a class itself. If the parent class loader cannot load a class, the class loader attempts to load the class itself. In effect, a class loader is responsible for loading only the classes not available to the parent. Classes loaded by a class loader higher in the hierarchy cannot refer to classes available lower in the hierarchy.
note: Related documentation for GF3.1 is here and here
However you may influence the behavior through glassfish specific descriptor with
<class-loader delegate="true/false"/>
You can find more about it following the first link
In the simplest of Flex Projects, create an MXML Flex Module and then load it using the ModuleManager. No problem. Create an ActionScript class that extends Module and then configure your project to compile that into a Module. Load this new module instead. The project compiles, but crashes when running with the following error:
"Error: Could not find compiled resource bundle 'containers' for locale 'en_US'."
I believe the compiler is failing to compile the required class definitions into ActionScript only module, while it succeeds for the MXML module. I can see that my skeleton MXML module is slightly larger than my ActionScript module (66KB vs. 45KB).
How can I resolve this problem (if that is indeed the issue)?
A good approach in these sort of situations is to use -keep-generated-actionscript for two projects, one with the mxml approach, and one with the actionscript approach. You can then compare the code to see what might be missing from one project, but included in another.
Have you tried adding an explicit reference to [ResourceBundle("containers")] to your ActionScript project class? The mxmlc is different to the compc compiler in behaviour for many valid reasons.
I was having this same problem when compiling a library swc. I was able to fix it by adding the following section to the projects projectName-config.xml
<include-libraries append="true">
<library>${flexlib}/locale/{locale}/framework_rb.swc</library>
</include-libraries>
This forces the compiler to include the framework resource bundle for the specified locale.
for me the issue was finding out which project - in my case a library - and which class in this library caused this behavior (I needed to realize my last changes - no info from flashbuilder). Then applying the following attribute to the class:
[ResourceBundle("containers")]
public class IpChecker {
...
That did the trick.
I am a total newbie on Prism. I have been getting to understand a lot from questions on SO and from various Blogs. I am using latest build – V2
I want some explanations on things that may be pretty easy things for you guys but it’s just not getting into my brains (small one for that).
Instead of doing it all right the first time , for which I have spent more than two weeks looking at various blogs, webcast …., I thought to start a project and learn. The amount of information on those hundreds of sites was overwhelming and difficult to digest.
Currently my project is setup like this
Shell -- Menu Module- ViewModel - - -> Menu Service -- -- > Menu Repository --- Data
All are in different assembly
MyShell --- MenuModule ---MyServices -- Myrepository
Shell is required to reference modules ( thought I am sure I can add it using string) later on .
ViewModel has a reference to View - Can live with it for now
View Model requires to use menu service and menu service uses repository
All are built with constructor injection. I have it working now by having module reference MyService and Myrepository projects and then registering types at module level.
But this does not feel good. I don’t want to hard reference any projects. If we are referencing projects why use IoC. In MenuModule.cs ( which is in the root of module) I can register views with unity container
I think I am getting a feel that the answer to this one may lie in the first question
Is Configuration file the answer/
Should I use configuration file for
true decoupling?
If (somehow) we can
register types from code, should we
register types at module level ( I
don’t want to have hard reference to projects)
I need to know the
Interfaces in advance so do you
recommend separate assembly for just
Interfaces?
Bear with me if the questions sound real stupid
You don't need a configuration file for true decoupling. All you need is to register your types in your shell's bootstrapper. I usually break up my projects and refs like this.
Contract Assembly
(Contains only a few simple types and interfaces)
Referenced by:
Shell
Modules
Shell
(Contains concrete implementations of interfaces defined in Contract assembly)
Referenced by:
No one
Modules
(Declares dependencies on interfaces defined in Contracts assembly, for instance IMenuRegistry)
Referenced by:
No one (I use a Directory Module to search for modules in a directory)
Here's a sample project I put together. In this sample I reference the module from the shell for simplicity's sake, but you can remove that reference and use a directory module catalog to load the compiled module at runtime:
http://dl.getdropbox.com/u/376992/CAGMenus.zip
Hope this helps,
Anderson
You're definitely on the right track. Use the configuration file to register your types, and put the interfaces in a separate assembly.