Develop Reference

Strange Tomcat 8 deployment behaviour

When I deploy my Spring 4.0.1.RELEASE web application to Tomcat 8.0.33 installed on ext3 running on Java 1.8.0_92 on Centos 6.7 I get the following error:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'qualityAuditTokenService' defined in URL [jar:file:/home/www/webapps/ROOT/WEB-INF/lib/product-service-2.0.1-SNAPSHOT.jar!/com/company/product/services/QualityAuditTokenService.class]: Unsatisfied dependency expressed through constructor argument with index 0 of type [com.company.workflow.dao.TokenDao]: : No qualifying bean of type [com.company.workflow.dao.TokenDao] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {}; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [com.company.workflow.dao.TokenDao] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {}
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:742)
at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1114)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1017)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:504)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:700)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:760)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:403)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4811)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5251)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1092)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1834)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [com.company.workflow.dao.TokenDao] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {}
at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoSuchBeanDefinitionException(DefaultListableBeanFactory.java:1100)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:960)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:855)
at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:806)
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:734)
... 28 more
However if I install exactly the same web application to Tomcat 8.0.33 installed on an NFS mount running on Java 1.8.0_92 on Centos 6.7 it works just fine. It also works just fine if I install it to Tomcat 7.0.69 on ext3 on Centos, Tomcat 8.0.33 on ext4 on Ubuntu and NTFS on Windows. So it's just throwing this error running in Tomcat 8.0.33 on ext3 on Centos. It wouldn't be so much of a problem if this weren't our live deployment environment.
So this is clearly not one of the standard "missing annotations" or "bean class missing from JAR" type problems although I am happy to hear suggestions in this vein in case I missed something.
The strange thing about this deployment is that the Spring beans are created in a different order on the different file systems. In the versions that work, the following appears in the logfile with Spring logging maxed:
DEBUG DefaultListableBeanFactory:449 - Creating instance of bean 'tokenDaoHbm'
DEBUG DefaultListableBeanFactory:249 - Returning cached instance of singleton bean 'sessionFactory'
DEBUG DefaultListableBeanFactory:249 - Returning cached instance of singleton bean 'searchSessionFactory'
DEBUG DefaultListableBeanFactory:750 - Autowiring by type from bean name 'tokenDaoHbm' via constructor to bean named 'sessionFactory'
DEBUG DefaultListableBeanFactory:523 - Eagerly caching bean 'tokenDaoHbm' to allow for resolving potential circular references
DEBUG DefaultListableBeanFactory:249 - Returning cached instance of singleton bean 'org.springframework.transaction.config.internalTransactionAdvisor'
DEBUG DefaultListableBeanFactory:249 - Returning cached instance of singleton bean 'org.springframework.cache.config.internalCacheAdvisor'
DEBUG AnnotationTransactionAttributeSource:108 - Adding transactional method 'TokenDaoHbm.update' with attribute: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; ''
DEBUG InfrastructureAdvisorAutoProxyCreator:551 - Creating implicit proxy for bean 'tokenDaoHbm' with 0 common interceptors and 1 specific interceptors
DEBUG JdkDynamicAopProxy:117 - Creating JDK dynamic proxy: target source is SingletonTargetSource for target object [com.company.product.dao.hibernate.TokenDaoHbm#4a51d9f9]
DEBUG DefaultListableBeanFactory:477 - Finished creating instance of bean 'tokenDaoHbm'
This is the bean that would satisfy the dependency had it been created - in the version that throws the exception, this bean creation is notable for it's absence.
TL;DR
So, how can the OS, file system type and/or network latency change the order which Spring creates beans (or otherwise break it's dependency analysis)? Surely this is something enshrined in the WAR file (and the version of Spring it is packaged with)?
I have tried to influence bean creation via #ComponentScan and #Qualifier to no avail - are there other approaches?
This problem bears a resemblance to the one linked below, but there is no posted solution (and they are having the problem with Tomcat 7 not 8).
Need help debugging Tomcat 7 application error
Any help with this greatly appreciated, as this one is really vexing me! :-D

I now have a solution to this (hence posting an answer) but it's butt fugly and I still have no explanation for why this is necessary (so I'll save the accepted tick for either a more elegant solution or a complete explanation).
It turns out my issue is related to issue 57129 raised on the ASF bugzilla:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
However, in the case outlined there, multiple JAR files within a WAR contain different versions of the same class file. This means changing the order will change the application behaviour - not desirable.
In my case, the class in question, TokenDaoHbm, only exists once in the WAR file. It's just that, if the Tomcat class loader hasn't loaded the product-dao-hibernate-2.0.1-SNAPSHOT JAR file by the time Spring comes to instantiate qualityAuditTokenService bean, then you get a NoSuchBeanDefinitionException. Surely Spring and/or Tomcat must know all classes must be loaded before bean instantiation can commence?
So, to fix my problem, I placed the following in my application context.xml in the WAR according to the advice from Mark Thomas in the ASF bug posting:
<Resources>
<PreResources className="org.apache.catalina.webresources.FileResourceSet"
base="${catalina.base}/webapps/ROOT/WEB-INF/lib/product-dao-hibernate-2.0.1-SNAPSHOT.jar"
webAppMount="/WEB-INF/lib/product-dao-hibernate-2.0.1-SNAPSHOT.jar" />
</Resources>
If anyone can shed further light on this I am happy to mark them as the accepted answer.

kie workbench 6.2.0.CR2 installer fails to start: Unsatisfied dependencies

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?

WELD-001408: IterableProvider<InjectionResolver<Object>>

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.

Java EE #Resource isn't mapping to web.xml

I am trying to develop a web application with a java back end but I need to track if the tasks are complete and I am using the ManagedExecutorService for this.
I am trying to use the #Resource annotation to inject a ManagedExecutorService as follows.
#Resource(name = "myExecutionService")
private ManagedExecutorService mExecutionService;
web.xml:
<resource-env-ref>
<resource-env-ref-name>myExecutionService</resource-env-ref-name>
<resource-env-ref-type>javax.enterprise.concurrent.ManagedExecutorService</resource-env-ref-type>
</resource-env-ref>
but I keep getting an error saying that I am missing the "Services with missing/unavailable dependencies"
13:52:31,207 INFO [org.jboss.as.server] (management-handler-threads - 158) JBAS015870: Deploy of deployment "tbm-core-1.0.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"tbm-core-1.0.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"tbm-core-1.0.war\".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [TestBedManager] with qualifiers [#Default] at injection point [[field] #Inject private com.shenick.teravm.core.ws.TestBedManagerWebService.testBedManager]"},"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.\"tbm-core-1.0\".\"tbm-core-1.0\".env.myExecutionServicejboss.naming.context.java.jboss.resources.myExecutionServiceMissing[jboss.naming.context.java.module.\"tbm-core-1.0\".\"tbm-core-1.0\".env.myExecutionServicejboss.naming.context.java.jboss.resources.myExecutionService]"]}

I have figured out the problem and it's because ManagedexecutorService is java 7 only apparently and jboss 7.1.1 will not deploy apps that use threads.
to solve this I will need to upgrade to EAP 6.1 (new name for jboss).

If you want just use the default implementation, use
#Resource(mappedName="java:comp/DefaultManagedExecutorService")
In this case, you don't need to specify it in web.xml.
If you want to use your own implementation, I think you should configure your application server resources first (set it with your implementation).
EDIT:
I found this by chance:
How to Configure Scheduled Tasks in Wildfly. It could help you, I think.

Cannot inject EJB specified in applicationcontext.xml in jboss 7

I'm trying to migrate my Java EE application from jboss 5.1 to jboss 7.1 and getting a deployment error.
My EAR has 2 EJB modules and 1 WAR module. both EJB modules gets deployed without any issue. but when i'm trying to deploy with the WAR module it says
Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name "className" Injection of resource fields failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'java:global/ear/ejb/FacadeBean!com.ejb.business.SearchFacade' is defined: not found in JNDI environment
because of copyright issues i'm unable to disclose the full class names. but "classname" is defined as a bean in my spring application context file and it has a dependency injection of SearchFacade which again has some dependencies.
whats confusing is that in the jboss log it shows that SearchFacade is deployed without any issues.
i'm finding so hard to find a solution for this issue. any help will be greatly appreciated.
thanks in advance.

Looks like spring is not able to determine that the EJB component is in that EJB Jar and you need to enforce that the components in that EJB jar are initialized and started before the components in you WAR.
Did you tried to set element into your application*xml and see if that helped?
Something like this in your application.xml
<application-name>EAR</application-name>
<initialize-in-order>true</initialize-in-order>
<module><ejb>EJB.jar</ejb></module>
<module><web><web-uri>WAR.war</web-uri><context-root>....