I can sometimes get the annotation via [object].getClass().isAnnotationPresent([Annotation.class])
but sometimes not.
So I turn on the debug mode and find the difference:
In the fist picture, b.getClass() return the actual class: stan.beans.HisBean
But in the second picture, it actually return something different, looks like a modified class by Spring framework so I use the proxied word in the title:
class packagepath.Handler$$EnhancerBySpringCGLIB$$da96cafa
Thanks to #Teppic I figure out we can use AopProxyUtils.ultimateTargetClass() to get the non-proxied class
But my question now is :
When will SpringCGLB proxy the class? Is there any configuration I can change? Cause I think both my screenshots use the same configuration. They almost shadow each other.
Important Info Thanks to #M. Deinum
The second bean class(proxied one) has Spring Cache #Cacheable annotation on some methods
Related
I have a strange situation that I don't understand.
I would like to decide in a bean, should I enable or disable the SQS listener.
So I've created a config class with a definition:
#Bean
MyListener createListener(Features f){
return f.shouldListen() ? new RealListener() : new MockListener();
}
As you can see, I have such an inheritance:
interface MyListener{}
class RealListener implements MyListener{
#SqsListener(...)
list handleMessage(SqsMessage message){
...
}
}
class MockListener implements MyListener{}
Now, the funny part:
It sometimes works.
After few restarts of the application, the handleMessage() method is called but in most cases it isn't without any exception. The queue is created, all permissions are in place.
To make it working I need to return RealListener from createListener() method or move #SqsListener annotation to a method in the MyListener interface. Both are not options for me, because I don't want to call AWS, when the mock is enabled.
I've tried with conditional bean creation but as Features depends on a DB (indirect entityManager dependency, to be more precise), I can't make it working. I've tried with abstract class instead of interface, but without luck. I've tried to register the RealListener bean in the BeanFactoryPostProcessor but this also doesn't work (same entityManager dependency issue). I've tried to move the annotation to the interface and use #ConditionalOnBean with #Primary to create an empty AmazonSqsClient when the mock is enabled, but it doesn't work.
I could understand that it doesn't work, because the bean has to be created for a type with the method annotated with #SqsListener (not with it's supperclass/interface type), but I have three such beans and a lottery - sometimes all work, sometimes one or two but sometimes none of those.
Do you have any suggestions?
Well... I've found the issue but it still would be nice, to know, what has happened.
So... There is a class QueueMessageHandler using detectHandlerMethods(...) method from the superclass AbstractMethodMessageHandler. This method uses MethodIntrospector.selectMethods() to select methods to scan. This class takes into consideration methods annotated with #SqsListener when there is #EnableSqs in some configuration class.
The problem is, in my project the #EnableSqs annotation is located in some file - not the file with createListener(...) method and not the main class of the Spring Boot application. That means, the class with #EnableSqs can be loaded before or after MethodIntrospector.selectMethods().
The output is:
I have no idea, why it works fine without inheritance and doesn't work with inheritance
To fix the issue, I've moved #EnableSqs to the main class of the project
I have an annotation driven spring mvc project templated after the JBoss web mvc sample. (Spring, Hibernate, JPA 2.0)
I have a utility package where I want to put reusable classes for obviously utility functions.
Specifically I have a LogonUtilities class where I want to query a database to get information.
I autowire my DAO there but when I debug the DAO is always null and fails with that exception.
I have read and tried many things - I know I've probably come across the solution already - but missed something and moved on and tried something else. I probably am not googling the correct terms since annotations are new to me. (I've worked with spring & hibernate for years - but with xml)
I've added this to my applicationContext.xml
<context:component-scan base-package="util"/>
which I thought was all I needed to do.
This is what I currently have in my LogonUtility class - but it doesn't work, keywordDao is always null. I think I could probably get it to work if I wired the DAO to a LogonUtility bean in the applicationContext (the old way) but I would think there's a better way to do it with annotations.
#Service
public class LogonUtilities {
#Autowired private KeywordDao keywordDao;
My application isn't brand new, I probably have ten working controllers and over a dozen working DAOs at this point, including a Keyword Controller and DAO that already does CRUD operations, so I don't think my setups with that stuff is incorrect.
I just have some code I want to reuse that pulls from a database.
Thanks in advance.
*in my code it's actually called "TrainingKeyword" not "Keyword"
This is the nullPointer error because the DAO is null
10:52:07,673 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /Training/Home: java.lang.NullPointerException
at util.LogonUtilities.trainingOffices(LogonUtilities.java:59) [classes:]
at filter.LogonFilter.doFilter(LogonFilter.java:100) [classes:]
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) [spring-web-3.1.1.RELEASE.jar:3.1.1.RELEASE]
This is the code where the error happens
//Set TrainingOffices
List<TrainingKeyword> kList1 = keywordDao.getAllTrainingKeywordsByName("Level 200 Training Offices");
I solved my problem by listening to your ideas and with help from this question.
JPA is not Autowiring
Basically I had already tried everything that worked - but never all together. I was constantly making edits to my code trying to get it to work and always had either something missing or something bad. For anyone with a similar question here are the steps
In my LogonFilter I added
#Autowired private LogonUtilities lu
In my LogonUtilites class I added
#Autowired private TrainingKeywordDao keywordDao;
There was no need to add the LogonUtility bean to my applicationContext - I took it out and it still works.
Thank you to all that helped - your ideas kept making me rethink what I was doing.
You are trying to do a #Autowired private KeywordDao keywordDao; but you not getting any autowiring error. but #Autowired is by default #Autowired(required=true) meaning that these dependencies are by default mandatory, and throw an error if not met.
No autowiring error is received, so the conclusion is that it seems that this class is not being scanned for autowiring at all.
If it would then an error would be thrown. Try to see why the class is not being autowired, here are some common causes:
the package where the class is placed is not being scanned, is the name of the classes package util or a subpackage?
The scanning is being done in the wrong spring context. Most Spring applications have two contexts, one root context and one servlet dispatcher context. Try to move the component scan <context:component-scan base-package="util"/> from one context to the other, by copying this configuration line from one XML file to the other.
Make sure that base-package is the fully qualified path of the service from the root on, and make sure that KeywordDao is annotated with #Repository.
I have a web controller which I configure in the controller-config.xml using
<mvc:annotation-driven />
<context:annotation-config />
<context:component-scan base-package="com.ecommerce.web.controller" />
The controller has the #Controller annotation like below.
#Controller
public class HomeController
I have included the #Autowired annotation on the dependencies, but when I first start up the application I am unable to set any properties on the wired objects.
For example, I have a storeProfile object which when in debug mode I see has multiple properties set as it should.
But, when I try to set one of the storeProfile properties on an #Autowried bean it is still null or empty string!?
If you look at the attached images it shows that after I step past the line this.storeProfileContext.setStoreProfile(storeProf ile) the debugger still shows the storeProfile property as null
Actually, there are a couple dependencies which look like they are created (they are not null and the application functions), but I am unable to set anything on these objects.
I asked the same question on the Spring forums too - hoping to get this figured out.
Thanks so much!
That is because you are looking at the fields of the proxy, which gets created when you have <aop:scoped-proxy/>, if you invoke your getter for the set values, you should see the correct values retrieved from the proxied object.
The instances you are examining are CGLIB proxies.
CGLIB subclasses your beans, delegating all method invocations to the target beans.
So the fields of the super classes are still present but not used.
I'm studying Spring 3 and I'm using it in a simple web-application.
Now I'm implementing a Spring MVC Controller using annotations, and I'm wondering:
Is there any best practice using #RequestMapping annotation?
I mean: I've seen that usually the URL mapped in this annotation is hardcoded in the class...
Is there a way to pass the URL in a 'loosely coupled way' (to obtain a more reusable class)?
I know that there are some wild cards that can be used, but I think that isn't the solution... Am I wrong?
EDIT:
I add an example to better explain my doubt.
Suppose I want my controller to be triggered by a request to /foo/bar/baz/mypage.htm, in my controller the handler method will be annotated with #RequestMapping("/foo/bar/baz/mypage").
Now I decide to change the URL triggering my controller into /foo/bar/otherpage.htm, so i need to edit my class, put #RequestMapping("/foo/bar/otherpage") on my handler method, recompile the project and deploy it again.
It seems to me not so practical...
Currently annotated controllers aren't very configurable.
As far as I know, the only possible approach to this problem is to use alternative HandlerMappings in order to configure "base URLs" of controllers. For example, as follows:
// Note the absense of #Controller to prevent this controller
// from being discovered by DefaultAnnotationHandlerMapping
public class FooController {
#RequestMapping("/list") public String list(...) { ... }
#ReqeustMapping("/save") public String save(...) { ... }
}
.
<bean
class = "org.springframework.web.servlet.mvc.support.ControllerBeanNameHandlerMapping" />
<bean name = "/foo" class = "FooController" />
<bean name = "/bar" class = "FooController" />
In this example two instances of FooController handle /foo/list, /foo/save, /bar/list and /bar/save respectively.
The upcoming Spring 3.1 will have an improved Spring 3.1 architecture (Spring 3.1 M2: Spring MVC Enhancements) that seems to be more flexible, though I haven't checked it yet.
I think you are trying to solve the wrong problem. If you wanted to change the pages that matched a controller you'd need to change a file somewhere. Would you rather change the file with the related code underneath it, or would you rather work with some XML files that specifies the URL and the class, and then you have to worry about the file being in the right place during runtime?
As there should be almost no code in your controller anyway, you should think of your controllers as compilable configuration files. Also, if you are using a build system like Maven or Ant and not compiling individual files by hand using Javac then compilation time shouldn't be an issue. If it becomes one, it's probably time to split your project into sub-projects.
I think you should just embrace this and see that it is probably not the issue you think it is. Also, did you know that controllers can match to expressions and not just literal strings? That gives you some flexibility in your naming.
If you really want to, you could just fall back to the Spring 2.0 style XML configuration, but I don't think anyone would recommend that.
I think that is not a best practice, but have you tryed with #PathVariable annotations?
#RequestMapping(value="/path/{word}", method=RequestMethod.GET)
public ModelAndView myRestMethod(#PathVariable String word) {
...
}
I've been trying to get a sample JMX MXBean working in a Spring-configured webapp, but any basic attributes on the MXBean are coming up as UNDEFINED when I connect with jconsole.
Java interface/classes:
public interface IJmxBean { // marker interface for spring config, see below
}
public interface MgmtMXBean { // lexical convention for MXBeans - mgmt interface
public int getAttribute();
}
public class Mgmt implements IJmxBean, MgmtMXBean { // actual JMX bean
private IServiceBean serviceBean; // service bean injected by Spring
private int attribute = 0;
#Override
public int getAttribute() {
if(serviceBean != null) {
attribute = serviceBean.getRequestedAttribute();
}
return attribute;
}
public void setServiceBean(IServiceBean serviceBean) {
this.serviceBean = serviceBean;
}
}
Spring JMX config:
<beans>
<context:component-scan base-package="...">
<context:include-filter type="assignable" expression="...IJmxBean" />
</context:component-scan>
<context:mbean-export />
</beans>
Here's what I know so far:
The element is correctly instantiating a bean named "mgmt". I've got logging in a zero-argument public constructor that indicates it gets constructed.
is correctly automatically detecting and registering the MgmtMXBean interface with my Tomcat 6.0 container. I can connect to the MBeanServer in Tomcat with jconsole and drill down to the Mgmt MXBean.
When examining the MXBean, "Attribute" is always listed as UNDEFINED, but jconsole can tell the correct type of the attribute. Further, hitting "Refresh" in jconsole does not actually invoke the getter method of "Attribute"- I have logging in the getter method to indicate if it is being invoked (similar to the constructor logging that works) and I see nothing in the logs.
At this point I'm not sure what I'm doing wrong. I've tried a number of things, including constructing an explicit Spring MBeanExporter instance and registering the MXBean by hand, but it either results in the MBean/MXBean not getting registered with Tomcat's MBean server or an Attribute value of UNDEFINED.
For various reasons, I'd prefer not to have to use Spring's #ManagedResource/#ManagedAttribute annotations.
Is there something that I'm missing in the Spring docs or MBean/MXBean specs?
ISSUE RESOLVED: Thanks to prompting by Jon Stevens (above), I went back and re-examined my code and Spring configuration files:
Throwing an exception in the getAttribute() method is a sure way to get "Unavailable" to show up as the attribute's value in JConsole. In my case:
The Spring JMX config file I was using was lacking the default-autowire="" attribute on the root <beans> element;
The code presented above checks to see if serviceBean != null. Apparently I write better code on stackoverflow.com than in my test code, since my test code wasn't checking for that. Nor did I have implements InitializingBean or #PostConstruct to check for serviceBean != null like I normally do on almost all the other beans I use;
The code invoking the service bean was before the logging, so I never saw any log messages about getter methods being entered;
JConsole doesn't report when attribute methods throw exceptions;
The NPE did not show up in the Tomcat logs.
Once I resolved the issue with serviceBean == null, everything worked perfectly. Regardless, +1 to Jon for providing a working demo, since there are literally 50 different ways to configure MBeans/MXBeans within Spring.
I've recently built a sample Spring based webapp that very cleanly enables JMX for latest versions of Spring, Hibernate and Ehcache.
It has examples for both EntityManager based access and DAO access (including transactions!). It also shows how to do annotation based injection in order to negate having to use Spring's xml config for beans. There is even a SpringMVC based example servlet using annotations. Basically, this is a Spring based version of a fairly powerful application server running on top of any servlet engine.
It isn't documented yet, but I'll get to that soon. Take a look at the configuration files and source code and it should be pretty clear.
The motivation behind this is that I got tired of all of the crazy blog posts with 50 different ways to set things up and finally made a single simple source that people can work from. It is up on github so feel free to fork the project and do whatever you want with it.
https://github.com/lookfirst/fallback