intellij and embedded Jetty - Error creating bean with name - spring

TLDR
Getting error of Error creating bean with name... when running embedded Jetty within IntelliJ, but not when running the same code outside of Intellij - in a stand-alone Jetty server.
In-Depth
We have a web application that runs in a Jetty.
Up until a week ago, I was able to start and use the app with the Intellij's embedded Jetty.
A few days ago a colleague of mine updated one of the beans constructors and added to it a new bean that he created.
So in the zoowebappcontext.xml he added a new entry to the bean constructor:
<bean id="animalsService" class="java.util.ArrayList">
<constructor-arg>
<list>
<ref bean="pets.catService" />
....
<ref bean="pets.dogService" /> <-- The new item
...
And in the applicationContext.xml file, he added a new bean definition, that looks very similar to all the other beans there:
<bean id="pets.dogService"
class="com.example.DogServiceImpl"
parent="...">
<property name="..." ref="..."/>
</bean>
The strange this is this: If I mvn clean install the project, have a new zoo.war , move it to the Jetty's webapp folder and start the app as a stand-alone Jetty, the app starts with no error.
But, when running the app within the intellij's embedded Jetty, the app tries to start and eventually fails with this error:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'animalsService' defined in class path resource [zoowebappContext.xml]: Cannot resolve reference to bean 'pets.dogService' while setting constructor argument with key [14]; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'pets.dogSerice' is defined
Moving the code to the commit before the above change, the intellij is able to start with no problems.

It seems like intelliJ had something that was stuck in its system, as just as the problem started, it simply vanished at some point.
Some things that may have helped to "reset" IntelliJ (none of them solved the problem by its own):
Restarting IntelliJ several times
Restating the computer
Switching back and forth between different GIT branches
File -> Invalidate Caches / Restart...
And again, none of the items by itself solve it.

Related

Blueprint/Spring can't find 'classpath:path/to/file.ext' resource having moved project from Talend 6.5.1 to 7.1.1

In a Talend ESB (SE) project, I have a bean instantiated in the "Spring" configuration using a route resource.
In version 6.5.1 the following (used as a parameter) works fine.
<bean class="java.lang.String">
<constructor-arg>
<bean class="org.springframework.util.FileCopyUtils" factory-method="copyToByteArray" >
<constructor-arg value="classpath:query/sqlQuery.sql" type="java.io.InputStream" />
</bean>
</constructor-arg>
</bean>
but this doesn't for in my Talend 7.1.1 project. It seems to be unable to find the resource. I've looked in the created .kar file, and the resource is in the project .jar in the query folder.
[EDIT] It appears that Talend 7.1.1 encloses the "Spring" configuration in a <blueprint> element, which perhaps has change the way in which this functions.
I presume that something has changed in the way Talend packages the route, or in the way that the Spring xml is interpreted. Camel has no problem finding resources, for example from("sql:classpath:query/sqlQuery.sql"), but the "Spring" classpath search seems not to be able to find them.
I've tried substituting classpath*: for the straight classpath in the parameter as that had been suggested in some of the answers I'd seen to "resource not found" questions, but this didn't seem to be valid and was interpreted as a straight filename.
Am I doing something wrong with the classpath declaration? Is there another way of setting a spring/blueprint bean property with the contents of a resource file?
I've also tried explicitly declaring a ClassPathResource bean and it claims the resource does not exist when using the getInputStream() method, despite the fact I can see it if I open up the contained jar file.
Has the wrapping of the created feature in Maven terms (from Talend 7) had some impact on the classpath I need to use?

Scoped proxy tag not taking effect - configuration error?

I've inherited a bit of a monster system. It is a Spring framework server meant to run on Weblogic.
The code as it stands seems to work perfectly for another developer. I can clean, compile and package the project without error. However, when I try to deploy the generate .war file to my Weblogic server, I get the following error:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'scopedTarget.com.example.portal.uil.delegate.ExceptionLogDelegate': Scope 'session' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
This error points me to the following bean, which is in an external library:
<bean id="com.externalLibrary.ExceptionLogDelegate" class="com.externalLibrary.ExceptionLogDelegate" scope="session">
<aop:scoped-proxy />
<property name="errorLogBuffer" ref="com.externalLibrary.ErrorLogDao" />
</bean>
After searching around for that error for a while, it seems that it is most often experienced when the aop:scope-proxy tag is omitted. This bean is being loaded as such:
<bean id="exceptionResolver" class="foo.mypackage.SoapFaultDetailExceptionResolver">
<property name="marshaller" ref="marshaller"/>
<property name="exceptionLogDelegate" ref="foo.mypackage.ExceptionLogDelegate"/>
</bean>
The strange thing is that with no files changed, this exact code works fine on my colleague's machine, so I assume I'm missing some magic configuration step.
Could anyone perhaps point me at thing to look for?
Kind Regards

how to handle name not found exception in application-context.xml?

I am creating a spring project using Oracle and jboss server.
I have one bean in my application-context.xml.
<!-- Datasource for TaskManager -->
<jee:jndi-lookup id="tmTestDataSource"
jndi-name="test_datasource" expectedtype="javax.sql.DataSource"/>
<bean id="tmTestJdbcTemplate" name="TmTestJdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
<constructor-arg ref="tmTestDataSource" />
</bean>
If the 'test_datasource' JNDI (one datasource.xml file in jboss deployment folder, which contains db credentials like url, uid, password) inside the file found deployment is successfull, but if the file is not there then the deployment is failing.
I want to handle this exception so that deployment should not fail.
how I can do this. Can anybody provide me any solution.
Thanks.
Instead of using dataSource args constructor, you can set it using setter method.
This way your bean will be created but its datasource will be null. So you will get NPE if you try to use it, but at least bean creation tree will not be stalled.

spring-test, groovy library and qualifier tag incompatibility

Im trying to add some groovy scripts to existing project and I stuck with making integration tests work.
I have few beans marked with <qualifier /> tag, that are used for autowiring both in test and in production code.
Right after I add 'org.codehaus.groovy:groovy-all:2.4.0'
(tried other versions aswell) to dependencies, without even any groovy usage, my integration tests stop working, with exception:
SEVERE: Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener#5e5f7983] to prepare test instance [com.dph.groovy.vs.springtest.IntegrationTest#299c9fe7]
java.lang.IllegalStateException: Failed to load ApplicationContext
at org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:94)
at org.springframework.test.context.DefaultTestContext.getApplicationContext(DefaultTestContext.java:72)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:117)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
at
......
Caused by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unexpected failure during bean definition parsing
Offending resource: class path resource [spring/app-config.xml]
Bean 'service'; nested exception is org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Tag 'qualifier' must have a 'type' attribute
Offending resource: class path resource [spring/app-config.xml]
Bean 'service'
at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:70)
at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:323)
Runnning project (with jetty 6 if this matters) doesnt cause any issues though, so I assume there's some trick with spring-test union with groovy.
I might just add 'type' to my qualifiers, however it doesnt solve problem, because I have external dependencies with same qualifier tags configuration, besides this attribute is optional as far as I know.
I'd love to find out at least what are roots of this problem.
I created example project to reproduce the described question and will appreciate any ideas:
https://github.com/ametiste/groovy-vs-spring-test
You have discovered a bug in Spring's testing support.
Fixed in Spring Framework 4.1.6 and 4.2 RC1
I have fixed this bug for Spring Framework 4.1.6 (scheduled for release at the end of March 2015) and 4.2 (scheduled for release in Q3 2015). For further details, please see JIRA issue SPR-12768.
If you wish to try out the fix before the aforementioned releases, consider building against one of the upcoming nightly snapshots.
Temporary Work-around
In the meantime, (for XML configuration files that you are permitted to edit) you can circumvent this bug by explicitly setting the type attribute in the <qualifier> tag to the intended default value which is "org.springframework.beans.factory.annotation.Qualifier". See the following XML config for an example.
<bean id="foo" class="java.lang.String" c:_="bar">
<qualifier value="foo" type="org.springframework.beans.factory.annotation.Qualifier" />
</bean>
Regards,
Sam
(author of the Spring TestContext Framework)

Spring OSGi classpath resource issue

I'm trying to deploy a spring based bundle in osgi (fuse esb).In spring context, I'm referring to a db4o file which is inside resources folder. As per my understanding, a maven project will make sure that any file available under resources folder will be available in project classpath. I've kept the file under resources/META-INF/spring/repo/test.db4o.
Here's the entry in spring context.
<bean id="objectContainer" class="org.springmodules.db4o.ObjectContainerFactoryBean">
<property name="databaseFile" value="classpath:META-INF/spring/repo/test.db4o" />
</bean>
Once I install and try to start the application, I'm getting the following exception.
java.io.FileNotFoundException: OSGi resource[classpath:META-INF/spring/repo/test.db4o|bnd.id=258|bnd.sym=taxonomydaoimplbundle] cannot be resolved to absolute file path because it does not reside in the file system: bundle://258.0:1/META-INF/spring/repo/test.db4o
I've tried different combinations, but OSGi doesn't seem to recognize this file. Any pointer will be appreciated.
-Thanks
I found the issue finally. ObjectContainerFactoryBean is relying on OSGiResourceBundle to load the resource as a file object. Though OSGiResourceBundle exposes a method called getFile(), it doesn't work as intended in an OSGi environment. It always expects a file protocol whereas the resource returned as an URI has a protocol "bundle".Hence, the exception is being thrown. The workaround is to use a inputstream or getUrl. Since I didn't have the source code of ObjectContainerFactoryBean, I had to extend this class to provide my own implementation which loads the file as an inputstream.

Resources