I have a Maven project. The build runs properly including tests. But when I run the tests only using Eclipse Luna, then the tests fail:
javax.enterprise.event.ObserverException: Caught Exception while handling event object with type : org.apache.webbeans.portable.events.discovery.AfterBeanDiscoveryImpl
...
Caused by: java.lang.AbstractMethodError: org.apache.webbeans.container.InjectableBeanManager.getInjectionTargetFactory(Ljavax/enterprise/inject/spi/AnnotatedType;)Ljavax/enterprise/inject/spi/InjectionTargetFactory;
at com.sun.faces.util.cdi11.CDIUtilImpl.createHelperBean(CDIUtilImpl.java:76)
at com.sun.faces.flow.FlowCDIExtension.afterBeanDiscovery(FlowCDIExtension.java:120)
... 60 more
INFO - Undeploying app: .../classpath.ear
org.apache.openejb.OpenEJBException: Creating application failed: /home/schnikow/projects/barbuchon2/BarbuchonKernel-2.0r0b-SNAPSHOT/classpath.ear: couldn't start owb context
(full stack trace is too long, I can provide it if needed)
I've add the needed JVM argument (-javaagent:/usr/devel/apache-tomee-webprofile-1.7.1/lib/openejb-javaagent.jar) in the launch configuration. I may miss something trivial, but I haven't any idea, what.
I use Eclipse Luna and Tomee embedded EJB container running on Java 8 virtual machine.
it seems you use mojarra, is it a CDI 1.0 compatible version or 1.1 (only TomEE 2 will be CDI 1.1/1.2 compatible)
Related
I have created a Grails 5.1.1 app from the command line with "grails create-app".
It runs fine, from the command line "grails run-app", and I can build a war file which can be run from the command line with "java -jar app-0.1.war".
I then attempted to follow the instructions for deploying in a container (Tomcat 8 and Tomcat 9 in my case) by adding the context-path and changing the build dependency. The documentation says to change "org.springframework.boot:spring-boot-starter-tomcat" to provided in build.gradle. "provided" is not a valid option as far as I can tell. I've tried both providedCompile and providedRuntime with the same result as below.
When I deploy the resulting app-0.1-plain.war I get one of two errors:
The bean 'characterEncodingFilter' could not be registered. A bean with that name has already been defined in class path resource [org/springframework/boot/autoconfigure/web/servl
et/HttpEncodingAutoConfiguration.class] and overriding is disabled.
with the suggested remedy of adding: spring.main.allow-bean-definition-overriding=true
results in a circular bean reference for hibernateDatastore.
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'hibernateDatastore': Requested bean is currently in creation: Is there an unresolvable circular reference?
I'm using openjdk version "1.8.0_292" of Java, Gradle 7.2 and I tried deploying on apache-tomcat-8.5.73 and apache-tomcat-9.0.56.
Any ideas about what might be wrong with my set up that prevents the deploy war from running?
Edit: This seems to be a manifestation:
https://github.com/grails/grails-core/issues/12288 and/or
https://github.com/grails/grails-core/issues/12278
Though the work around suggested did not work for me I do not experience the same problem with 5.0.3 as suggested in 12278.
I get this error when deploying application war to the server:
12-Sep-2018 10:21:54.726 SEVERE [localhost-startStop-1] org.apache.catalina.startup.ContextConfig.processAnnotationsJar Unable to process Jar entry [module-info.class] from Jar [file:/xxx/apache-tomcat-8.0.41_xxxx/webapps/xxx/WEB-INF/lib/jaxb-api-2.3.0.jar] for annotations
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 19
Informations:
Application is a micro-service created with Spring Boot
Java used is version 8
Tomcat version: tomcat-8.0.41
Thank you.
module-info.class is a module descriptor for Java’s module system that was introduced in Java 9. Some code in Tomcat 8.0 is unable to read the bytecode in that class file so deployment is failing.
I believe this is a limitation of Tomcat 8.0 that has been fixed in 8.5. Also note that an end-of-life announcement has been made for 8.0 so you should be planning to upgrade ASAP even without this problem.
We have a tomcat application that has a spring container running on 3.0.0. Upgraded to spring 4.1.7, and modified certain classes appropriately. One of the beans that we modified used CronTriggerBean. That was changed to use CronTriggerFactoryBean, and also upgraded to org.quartz-scheduler to 2.2.1. When deploying and starting tomcat, encountered the following exception.
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'appsecScheduler' defined in class path resource [application-
context.xml]: Initialization of bean failed; nested exception is
java.lang.IncompatibleClassChangeError: Implementing class at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean
(AbstractAutowireCapableBeanFactory.java:547)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean
Attached a debugger and found the offending class to be CronTriggerFactoryBean. But this issue happens only when deploying in a Windows environment. WHen the same war is deployed in Ubuntu, the application starts without any errors. For the record, I did a dependency:tree, dependency:build-classpath and ensured that 3.0.0 spring was not in use. The CronTriggerFactoryBean is part of spring-context-support.
Any suggestions on how to debug further or determine which jar is being used?
In NB 7.2 i have ejb module managed by maven with several dependencies. I try to run it on Glassfish 3.1.2.2 but it seems like server doesn't resolve libraries on classpath. I think arguments in deploy command ("deploy?DEFAULT=..." - i'm not sure it is command) are correct - there are all libraries in this command, but during creating ejb server throws class not found exception - although this class is in library in deploy command.
It is possible to deploy single EJB module with dependencies without enterprise application?
Thanks for advice
There are a couple of mechanisms for deploying EJBs. If the EJB has dependencies and is used in a web application, check if it can be used in the EJB lite configuration. It is easiest to deploy it in a WAR file along with a web application. There is an article Introducing the Java EE 6 Platform: Part 3 that details a number of the specifics.
Alternatively, you may deploy it as part of an EAR file which will include the dependencies.
If the EJB must be used as a standalone EJB, the dependencies must be be in the server classpath, or repackaged in the EJB jar file. NetBeans 7.2.1 can do that for you.
Just moved to Grails 1.2.1 (used 1.1.1 before). Changed application.properties, ran grails upgrade, fixed BuildConfig and Bootstrap - everything works just fine from grails console.
However, getting a problem when deploy packaged war under jetty 6.1.22:
1581 [main] ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is java.lang.NoSuchMethodError: org.codehaus.groovy.grails.commons.spring.ReloadAwareAutowireCapableBeanFactory.setParameterNameDiscoverer(Lorg/springframework/core/ParameterNameDiscoverer;)V
My project is built with maven2. I researched the war dependencies and see that both spring 2.5.6 and 3.0.0.RELEASE are used there.
I then tried to suppress use of spring 2.5.6 and got a problem with Acegi plugin (using version 0.5.1):
2010-03-10 21:06:56.440:WARN::Nested in org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is java.lang.NoSuchMethodError: org.springframework.web.context.ConfigurableWebApplicationContext.setId(Ljava/lang/String;)V
Any help would be greatly appreciated.
The problem is caused by the fact that in new version of Spring
ConfigurableWebApplicationContext is located in spring-web.jar, but the interface it inherits ConfigurableApplicationContext, which contains setId(String) method is in located in spring-context.jar.
If you have a library which has been compiled against older version of spring-context it will fail with NoMethodFound exception.
The solution is to locate and recompile that library against latest Spring version.
If you are using Spring version below 3.0 you could try to put full Spring bundle Jar instead of separate packages.