i am facing a rather disturbing error when deploying application on GlassFish 4. I already have one computer (with Ubuntu 13.10) that I have used to develop the code and the app is working and deploying fine on it.
However when I tried to deploy the same app on Windows 8.1 and/or Ubuntu 12.10 machines with similar environments, I get this error (on both):
Error occurred during deployment: Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [IterableProvider<InjectionResolver<Object>>] with qualifiers [#Default] at injection point [[BackedAnnotatedParameter] Parameter 2 of [BackedAnnotatedConstructor] #Inject org.glassfish.jersey.internal.inject.JerseyClassAnalyzer(#Named ClassAnalyzer, IterableProvider<InjectionResolver<Object>>)]. Please see server.log for more details.
In the log file there is this: http://pastebin.com/DhKY6kYJ
(looks that the same stack/error is printed twice, but nothing else to mention)
Using Java 1.7, the javax.ws.rs version is 2.0 in pom.xml and references to jersey moxy are 2.5.1 (in case these matter as it mentions something abut jersey)
These Injection errors are rather annoying and so far the reason for them has usually been a wrong/missing package/version. However I can not figure out from the stack trace what may be the problem.
Related
I deployed have build the .war file on centos with eclipse and then deployed it on tomcat 8.5 on centos(Linux). It is working with that. But when I deployed the same ".war" or build a new ".war" file with eclipse on windows It is not working on Tomcat8.5 and it throws BeansInCreation Exception. Having the same Java1.7 and Tomcat8.5 version windows7.
The build was also working on windows on the previous version(before updating)
and there are nothing major changes done in the latest code.
Here are the logs from localhost :
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name '': Bean with name '' has been injected into other beans ['','',''] in its raw version as part of a circular reference, but has eventually been wrapped (for example as part of auto-proxy creation). This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:169)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:170)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:268)
... 98 more
I think the problem may be because of "large file path" as Linux support more large file path than windows. I have changed in the regedit also to support but that doesn't need to have changed.
If it works on linux but not on windows i assume that there is a class loading issue (order of classes) while your war is deployed. I would recommend to check /lib directory inside your .war file.
Maybe it contains different versions from the same jar.
Edited:
You can track the class loading of tomcat (or any java application) on linux and windows. For this you need to start it with a special vm paramter (-verbose:class). take a look here:
Java verbose class loading
15:28:38.716 [qtp1588771273-32] WARN o.e.jetty.servlet.ServletHandler - /tp/gremlin/execute
java.lang.IllegalArgumentException: Could not resolve dependency of type:javax.transaction.TransactionManager
at org.neo4j.graphdb.DependencyResolver$Adapter$1.select(DependencyResolver.java:87) ~[neo4j-kernel-2.2.9.jar:2.2.9]
at org.neo4j.kernel.extension.KernelExtensions.resolveDependency(KernelExtensions.java:112) ~[neo4j-kernel-2.2.9.jar:2.2.9]
This is from Neo4j 2.x (the Gremlin plug-in). The package, when built and deployed as instructed at https://github.com/thinkaurelius/neo4j-gremlin-plugin, does contain the jar-file which describes this class, and Maven did download it and did install it there. But, when the server attempts to load and execute the extension, nothing is resolved.
Why?
I'm using Jenkins 1.6.20 (Git Client Plugin 1.18.0, Git Plugin 2.4.0) to get the Java application code from bitbucket.org and deploy it to Apache Tomcat 8.0.23.
The error appears while deploying and looks like:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'requestMappingHandlerMapping' defined in class path resource [org/spr$
public java.util.List by.ipps.accounting.ws.PositionWS.getEmployeePost(java.lang.Long)
to {[/positionListJson/{id}],methods=[GET],params=[],headers=[],consumes=[],produces=[application/json],custom=[]}: There is already 'resourceWS' bean method
public by.ipps.accounting.model.Employee.EmployeePost by.ipps.accounting.ws.ResourceWS.getEmployeePost(java.lang.Long) mapped.
bla-bla-bla ... so many errors ...
Caused by: java.lang.IllegalStateException: Ambiguous mapping found. Cannot map 'positionWS' bean method
public java.util.List by.ipps.accounting.ws.PositionWS.getEmployeePost(java.lang.Long)
to {[/positionListJson/{id}],methods=[GET],params=[],headers=[],consumes=[],produces=[application/json],custom=[]}: There is already 'resourceWS' bean method
public by.ipps.accounting.model.Employee.EmployeePost by.ipps.accounting.ws.ResourceWS.getEmployeePost(java.lang.Long) mapped.
The problem is that the class (with annotation #Controller) PositionWS with method getEmployeePost was renamed to ResourceWS a week ago, so exists no more, so I should not get this error.
To fix this I have to create a blank PositionWS controller (with no methods in it), commit & push that to bitbucket (and delete (cus i really don't need it) later and commit & push).
It seems to be like a bug in any of the applications I use. I can't find out in which app there is a bug to report it. Tell me please, if anyone faced such problems.
The heart of the issue was in incorrect configuration of Jenkins, it was my fault.
When I was configuring Jenkins I set maven goal as "install", but it must be "clean install". According to this Jenkins never deleted old files and kept them, so got a lot of issues of different kinds and with different log messages.
Due to Jenkins working specialty it downloads project files and try to assemble it on path /var/lib/jenkins/jobs/<projectName>/workspace/target/.
So I've drop the data in this folder and afterwards set maven goal to "clean install" and that fixed the issue.
When trying to start the demo in Jbpm-distribution-6.2.0.CR2-installer.zip the service fails to start, ie the log says:
Services which failed to start:service jboss.deployment.unit."jbpm-console.war".WeldStartService
Earlier in the (very long) log I see an error trace referring to the problem:
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ProjectService with qualifiers #Default
at injection point [BackedAnnotatedField] #Inject org.kie.workbench.common.services.backend.validation.JavaFileNameValidator.projectService
I raised it as an issue on the JIRA but after a couple of weeks an no answer I'm trying here. I've tried it on several versions of 6.2.0 now: Beta2, CR1 and CR2. Since it is a complete show stopper for the demo I'm wondering if it is something peculiar to my machine.
Does anyone else have this running okay?
Are you behind a proxy or firewall? Have you tried starting the demo without the examples that are cloned from a public repo?
Using Maven to build my project under windows works fine, but when I build it under Linux I get a NoSuchMethodError regarding one of the spring libs.
I am guessing it is something to do with class loader differences cross-platform and somewhere in my dependencies and I may have the same class twice but windows is loading one while linux loads the other?
Has anyone come across this problem before, or have any advice on how I can debug this error further?
nested exception is java.lang.NoSuchMethodError:
org.springframework.aop.config.AopNamespaceUtils.registerAutoProxyCreatorIfNecessary(Lorg/springframework/beans/factory/xml/ParserContext;Lorg/w3c/dom/Element;)V:
java.lang.NoSuchMethodError:
org.springframework.aop.config.AopNamespaceUtils.registerAutoProxyCreatorIfNecessary(Lorg/springframework/beans/factory/xml/ParserContext;Lorg/w3c/dom/Element;)V
at org.springframework.transaction.config.AnnotationDrivenBeanDefinitionParser$AopAutoProxyConf
Stack Trace Pastie
POM.xml Pastie
Your spring dependencies have too many different versions:
org.springframework:spring-beans:jar:2.5.6:compile
org.springframework:spring-aop:jar:2.0.8:compile
org.springframework:spring-jms:jar:3.0.5.RELEASE:compile
Make all spring dependencies have the same version (preferably 3.0.5.RELEASE)