I'm configuring an ejb module on websphere 7 and I need to set my classloader to PARENT_LAST to make sure I don't get any classloader issues with wrong version of classes.
The odd thing is, my ejb #Resource annotation does not inject my resources anymore (which are defined in ejb-jar.xml) when I change my classloader to PARENT_LAST. All my fields annotated with #Resource are null.
I suspect your application contains a JAR that contains the javax.annotation.Resource class. The PARENT_LAST setting is causing the class loader to prefer your Resource class over the one in the JDK, which means the WebSphere Application Server injection engine never sees your Resource annotation. You should remove that JAR from your application.
If you want to verify, try adding the following logic to your application before the NPE occurs:
System.out.println(Resource.class.getProtectionDomain().getCodeSource().getLocation());
...or enable the -verbose:class (Verbose JVM class loading) option in your server JVM.
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.
I am doing the following:
porting several legacy applications from WebLogic to JBoss EAP 7. Some of the components being ported are EJBs. Others are servlet apps that invoke these EJBs. These EJBs are deployed in ejb-jars. I know that I could wrap this whole thing into a big EAR file but we don't want to do that. The servlets and the EJB jars need to be separately deployable components.
Then there is the logging setup. We are using log4j2 and we want to keep independent of the JBoss logging setup. I have created a JBoss module that contains all the log4j2 jars with the proper dependencies, and logging works.
The servlet runs and logs, invokes the EJBs and they work.
The only problem is how to configure the EJB's logging. In a Web App like the servlet, it's easy, just specify the log4j logging configuration file in web.xml. What's the analog for an ejb jar? I couldn't think of a way.
I tried the following: Add a logger/appender to the configuration of the servlet app for the EJB package and specify a new file. It doesn't work. The new logfile does get created but nothing gets written to the logfile. There should be output, but there isn't, so evidently when the EJB runs, its LogManager is not using the configuration specified in the servlet.
What is the right way for specifying a log4j2 configuration in an EJB deployed in an EJB jar on JBoss EAP7?
I had previously posted in this space a solution involving use of the #postConstruct and #preDestroy methods to initialize and shut down LoggerContext objects.
This plan fell apart when I tried to extend it to stateless session beans. It worked okay for Stateful Beans. Or so I thought. Eventually I found an Oracle document on EJB Restrictions which exposed the weaknesses in what I was doing. My "solution" included a non-final static LoggerContext member of the EJB class. I found a way to make it final, which did allow the stateless case to work. But I was increasingly dissatisfied with my approach. Even in the stateful case, I found issues that might bite me later in a clustered environment.
What I now come to believe is that I should not do what I was trying to do.
I can't even imagine the complexity of what a static final LoggerContext would look like if an EJB were distributed to another machine in the cluster. Objects like LoggerContext don't belong as members, static or not, of container-managed objects like EJBs.
It's not even clear that EJBs are the right implementation technology for what I am trying to build. My use cases are not really transactional so the case for EJB implementation is not strong so one possible path leads away from EJBs altogether.
The real message is that if EJBs or other container-managed components are indicated, it's probably best to use the container-provided logging system. I like log4j2, but until JBoss supports it, it's best to stick with container-provided log4j1 or some other framework.
I am using Apache Deltaspike 1.0 to inject properties into the beans within my application. I am curious whether the observation I made indicates a bug or not. I created a simple managed bean that was annotated with #ApplicationScoped and everything worked fine. Then I activated Wildfly's sub-deployment isolation mechanism (see the relevant section in the docs). Afterwards, the properties are no longer injected.
However, if I "promote" my managed bean to an EJB with #Singleton #Startup the properties are injected again. I actually don't need most of my beans to be EJBs but I did not find any other way at the moment.
Any thoughts?
Thanks in advance
Sven
The problem is not directly related to Wildfly 8.1, but to the combination with camel-cdi. I explained it in the Wildfly forums: https://community.jboss.org/thread/242945
I'm using MVC 3 and using the following code when the application starts...
UnityContainer container = new UnityContainer();
new UnityMappings(container);
DependencyResolver.SetResolver(new UnityServiceLocator(container));
Now when the app runs I'm getting the following error (but only sometimes)...
Activation error occured while trying to get instance of type
IControllerFactory, key ""
Interestingly, if I continue with the web request, the website works normally.
Any ideas? I can't see what I'm doing differently from before when this worked fine.
Cheers, Ian.
MVC3 requests a lot more than just controllers from the DependencyResolver. For most of them MVC3 falls back to the default implementation in case the DependencyResolver does not return an instance.
In your case it requests the IControllerFactory which is unknown to your IoC container and it throws an exception which is caught by the UnityServiceLocator implementation and null is returned. MVC then falls back to the default controller factory.
Unlike other IoC containers Unity does not provide an optional TryResolve and therefore does not support a proper exceptionless implementation of the DependencyResolver.
I would suggest first looking through the config and make sure everything is correct there, then I would make sure I had all the assemblies needed for Unity referenced in the project. That error message may (in my experience) point to an error in config or a missing DLL, perhaps an assembly you want to load in the container or another DLL needed by a DLL loaded by Unity?
Hope this helps.
We use logback and slf4j as logging libraries for our application and glassfish v3 as our application server. For the deployment time configuration properties we have created a "JNDI Custom Resource" in glassfish with the factory class as "org.glassfish.resources.custom.factory.JavaBeanFactory".
Specifying this factory class, glassfish creates an instance of the specified custom java bean (termed as resource type in glassfish) and set the user specified properties in this class instance.
My question is - Is there a way to use one of the properties specified for this java bean in logback? i.e. Is there a way to tell logback (in the tag) to read properties from a java bean?
I intend to add a property in the java bean as the "log location" which I can then use in my logback.xml. This property can be set by the application installer team to configure the location of the log files.
Also since we already have one Custom JNDI resource defined in glassfish we intend to use the same one for all the configuration properties for our application.
If you use the SiftAppender, you can configure a discriminator as JNDIBasedDiscriminator and use JNDI resource value to specify the source of the log file.
However it should be too time consuming.
Related info may be found in:
http://logback.qos.ch/manual/loggingSeparation.html