I have a class in spring project which contains #Autowire bean with #Lazy annotation.
At run time I am getting below errors while testing the class using junit.
org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type
Dependency annotations: {#org.springframework.beans.factory.annotation.Autowired(required=true), #org.springframework.context.annotation.Lazy(value=true)}
Related
I have a #repository class where I am using :
#Autowired
private NamedParameterJdbcTemplate template;
and defining datasource in application.properties. However, when method runs it thrown null pointer exception on line
template.update(INSERT_SQL_USER, parameters);
saying template is run. shouldn't springboot automatically bind datasource with the template? how can I resolve this issue?
p.s. I am using MySQL database
thanks in advance.
I am building a Project from github. When I build the project on eclipse.
After configuration with my database I get this error.
Error creating bean with name 'org.springframework.jdbc.core.JdbcTemplate#0' defined in ServletContext resource
[/WEB-INF/application-context.xml]: Cannot create inner bean 'com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolData
Source#82d210' of type [com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource] while setting bean property 'dataSource';
nested exception is org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [com.mysql.jdbc.
jdbc2.optional.MysqlConnectionPoolDataSource] for bean with name 'com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolData
Source#82d210' defined in ServletContext resource [/WEB-INF/application-context.xml];
nested exception is java.lang.
ClassNotFoundException: com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean
(BeanDefinitionValueResolver.java:282)
Please help me to solve this issue.
You are missing a jar. Please include this jar in your classpath: com.mysql.jdbc_5.1.5.jar
I played around with the Spring version in my application today. I started out at Spring 3.1.1 and when I moved to Spring 3.1.3 my application began throwing a NoSuchBeanDefinitionException during startup.
org.springframework.beans.factory.NoSuchBeanDefinitionException: No
matching bean of type
[nl.my.product.properties.Properties] found for
dependency: expected at least 1 bean which qualifies as autowire
candidate for this dependency. Dependency annotations: {}
I configured the Properties bean in the application context like this:
<!-- Gather properties from environment.properties in a map -->
<bean id="systemProperties" class="nl.my.product.properties.Properties">
<property name="propertyMap">
<map>
<entry key="email.from.address" value="${email.from.address}"/>
<entry key="site.host" value="${site.host}"/>
<entry key="site.protocol" value="${site.protocol}"/>
...
</map>
</property>
</bean>
And I autowired the bean into many of my controllers and services, like this:
#Autowired
public ArticleController(ArticleService articleService, PageBlockService pageBlockService, Properties systemProperties) {
this.articleService = articleService;
this.pageBlockService = pageBlockService;
this.properties = systemProperties;
}
Any clue as to why Spring is unable to find my bean since Spring 3.1.3? I tried moving the Properties bean to a package to was not also scanned for components, but that doesn't solve the problem.
When I annotate the Properties bean with #Component Spring does pick it up, but then the properties map is empty.
It started working when I removed the id="systemProperties" from the bean definition
When using a skipListener with scope="step" which implements Ordered I get the following exception:
Error creating bean with name 'scopedTarget.scopedTarget.fisalisBatchMeldungenListener': Scope 'step' 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 context holder available for step scope
If I don't let my listener implement Ordered the exception does not ocure.
Here is my Bean Definition:
<bean id="erzeuger" class="...." scope="step">
<property name="user" ref="user" />
<property name="termin" ref="termin" />
<property name="services" ref="services"
</bean>
<bean id="listener" class="Listenerclass" scope="step">
<property name="erzeuger" ref="erzeuger" />
</bean>
And here is the part where I am using it:
<step id="myStep" parent="abstractBatchStep" xmlns="http://www.springframework.org/schema/batch">
<listeners merge="true">
<listener ref="listener" />
</listeners>
</step>
Has anyone an idea where the problem is?
I have the point:
When the Listener is added to the step, the step checks, if its implements Ordered. If it does, the step adds the listener to a collection which will be immediatly sort by using a comperator. This comperator invokes getOrder(9 on the instance of the listener. But if the listener ist stepScoped, the SpringBatch Factory (s. comment below) has to return the "real" bean instance. But at this point the "real" bean instance does not exist.
For sope="step" read this:
Scoped bean works in different manner. When context is created this bean is wrapped into additional proxy object (by default created by CGLIB), which is passed to the bean that refers it (this proxy is by default singleton, e.g. shared). So each time the method is invoked on the proxy in runtime Spring intersects the call, requests the factory to return the instance of the bean and invokes the method on that bean. The factory in its turn may lookup for "real" bean instance e.g. in HTTP request ("request" scope) or HTTP session ("session" scope) and/or create new instance if necessary. Late instantiation allows to initialize the scoped bean with "runtime" (scope) values, e.g. values from HTTP request/session which are obviously undefined when context was created. In particular "step"-scoped beans are bound to thread local (remember that steps are run in parallel for partitioning). So, scoped beans are dereferred when you call a method on them. Finally one can easily break this elegant Spring "ideology" by calling any method on scoped bean just after it is set to another bean (e.g. in the setter) :)
I'm deploying some REST services in an Osgi bundle using Jersey. The services are notated like
#POST
#Path("/adduser")
#Consumes(MediaType.APPLICATION_XML+","+MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_XML)
public Message addUser(User user) {
...
}
The first problem I have is that the service doesn't accept both of the MIME types I put into the #Consumes notation but just the first one.
The second and worst is that receive the following exeception when I try to call to the services. I can #Consumes text/plain and I can #Produces application/xml for example but if I try to #Consumes an application/json or application/xml the server throw the exception.
The exception is throwed when I make the call with a wellformed json or xml using a REST client or an ajax call, if the service just receive text/plain or doesnt receive anything the response to the client is made correctly in xml so the serializer is working ok when I send POJO's but not receiving them.
javax.servlet.ServletException: org.glassfish.jersey.server.ContainerException: java.lang.LinkageError: loader constraint violation: when resolving interface method "javax.xml.bind.Unmarshaller.unmarshal(Ljavax/xml/transform/Source;)Ljava/lang/Object;" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, org/glassfish/jersey/message/internal/XmlRootElementJaxbProvider, and the class loader (instance of <bootloader>) for resolved class, javax/xml/bind/Unmarshaller, have different Class objects for the type ject; used in the signature
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:353)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
at es.upm.cedint.gateway.api.corssupport.CORSFilter.doFilter(CORSFilter.java:164)
at es.upm.cedint.gateway.api.corssupport.CORSFilter.doFilter(CORSFilter.java:246)
at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
at es.upm.cedint.gateway.api.security.SecurityFilter.doFilter(SecurityFilter.java:87)
at org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: org.glassfish.jersey.server.ContainerException: java.lang.LinkageError: loader constraint violation: when resolving interface method "javax.xml.bind.Unmarshaller.unmarshal(Ljavax/xml/transform/Source;)Ljava/lang/Object;" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, org/glassfish/jersey/message/internal/XmlRootElementJaxbProvider, and the class loader (instance of <bootloader>) for resolved class, javax/xml/bind/Unmarshaller, have different Class objects for the type ject; used in the signature
at org.glassfish.jersey.servlet.internal.ResponseWriter.rethrow(ResponseWriter.java:230)
at org.glassfish.jersey.servlet.internal.ResponseWriter.failure(ResponseWriter.java:212)
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:401)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:243)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:322)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:979)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:344)
... 36 more
Caused by: java.lang.LinkageError: loader constraint violation: when resolving interface method "javax.xml.bind.Unmarshaller.unmarshal(Ljavax/xml/transform/Source;)Ljava/lang/Object;" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, org/glassfish/jersey/message/internal/XmlRootElementJaxbProvider, and the class loader (instance of <bootloader>) for resolved class, javax/xml/bind/Unmarshaller, have different Class objects for the type ject; used in the signature
at org.glassfish.jersey.message.internal.XmlRootElementJaxbProvider.readFrom(XmlRootElementJaxbProvider.java:140)
at org.glassfish.jersey.message.internal.AbstractRootElementJaxbProvider.readFrom(AbstractRootElementJaxbProvider.java:122)
at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(ReaderInterceptorExecutor.java:181)
at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:134)
at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundReadFrom(MappableExceptionWrapperInterceptor.java:72)
at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:134)
at org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(MessageBodyFactory.java:988)
at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:833)
at org.glassfish.jersey.server.ContainerRequest.readEntity(ContainerRequest.java:252)
at org.glassfish.jersey.server.internal.inject.EntityParamValueFactoryProvider$EntityValueFactory.get(EntityParamValueFactoryProvider.java:96)
at org.glassfish.jersey.server.internal.inject.AbstractHttpContextValueFactory.provide(AbstractHttpContextValueFactory.java:66)
at org.glassfish.jersey.server.spi.internal.ParameterValueHelper.getParameterValues(ParameterValueHelper.java:81)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$AbstractMethodParamInvoker.getParamValues(JavaResourceMethodDispatcherProvider.java:121)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:195)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:94)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
... 45 more
Anyone have any idea of what could be wrong?
PD:I have #XMLRootElement at the begining of the User class that I want to serialize and the server I use is Jetty.
For the first question, I do not think you should have one function with two different signatures. I mean if you want to accept json or XML those are two different functions although they look the same from the java point of view. In your case I would create these three functions:
#POST
#Path("/adduser")
#Consumes(MediaType.APPLICATION_XML)
#Produces(MediaType.APPLICATION_XML)
public Message addUserXML(User user) {
return addUserInternal(user);
}
#POST
#Path("/adduser")
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_XML)
public Message addUserJSon(User user) {
return addUserInternal(user);
}
private Message addUserInternal(User user) {
...
}
As the second question: One of the worst thing that happened with Java 6 (in my opinion) is that they moved JAXB and other technologies into the JRE classpath. I guess you have also JAXB in one of your bundles. Jersey and the bundle that contains the REST API wire to different packages. One of them wires to the bundle that contains JAXB while the other wires to the boot classpath (package coming from JDK)
You can have two solutions (at least)
First solution
You exclude the JAXB packages from the boot classpath by configuring your OSGi environment.
Second solution
The packages coming from JDK have the version 0.0.0_jdkversion. The JAXB package coming from the bundle has a nicer and higher version like 2.1.1. You can edit the MANIFEST.MF of Jersey and your bundle to point to that version of the package.