Announcement Announcement Module
No announcement yet.
Getting BeanNotOfRequiredType exception but displayed types match Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Getting BeanNotOfRequiredType exception but displayed types match

    Hi all,

    Been having a heck of a time figuring out how to resolve an issue I have been seeing. Can't find anything on the web similar to it.

    Using Springframework version 3.0.5.RELEASE

    The offending line of code is:

    JMXClient myJMXConnectionInfo = myApplicationContext.getBean("jmx.client", JMXClient.class);
    This is being called from a static method of the JMXClient class itself (Not sure if that matters, including this just in case)

    This results in:
    Caused by: org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bea
    n named 'jmx.client' must be of type [com.thecompany.cds.common.jmx.JMXClient], but
    was actually of type [com.thecompany.cds.common.jmx.JMXClient]
            at com.thecompany.cds.common.jmx.JMXClient.getRemoteJobRunner(
    JMXClient bean is defined as:
      <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="placeholderPrefix" value="$simple-jmx-client{" />
        <property name="locations">
      <bean id="jmx.client" class="com.thecompany.cds.common.jmx.JMXClient" >
        <property name="url" value="$simple-jmx-client{jmx.url}" />
        <property name="username" value="$simple-jmx-client{authorization.username:test}" />
        <property name="password" value="$simple-jmx-client{authorization.password:test}" />
    The code for JMXClient is just getters and setters for the properties, the class just exists to wrap JMX properties and has a static method for retreiving remote beans.

    public class JMXClient {
        protected static final Logger LOGGER = LoggerFactory.getLogger(JMXClient.class);
        private String url;
        private String username;
        private String password;
        static String XML_PATH = "classpath:common-jmx/spring/simple-jmx-client.xml";
        public static <S> S getRemoteBean(String objectName,
                Class<S> clazz) {
        ClassPathXmlApplicationContext myApplicationContext = new ClassPathXmlApplicationContext(XML_PATH);
            JMXClient myJMXConnectionInfo = myApplicationContext.getBean(JMXClient.class);
    public String getUrl() {
            return url;
        public void setUrl(String url) {
            this.url = url;
        public String getUsername() {
            return username;
        public void setUsername(String username) {
            this.username = username;
        public String getPassword() {
            return password;
        public void setPassword(String password) {
            this.password = password;
    (I realize creating a new ClassPathXMLApplicationContext each time is stupid, I will be refactoring this class after I figure out this issue.)

    If anyone has any idea what could be going on I would appreciate some help immensely. My thinking is there must be some kind of class version issue froma potential transitive dependency, but thatis really just a shot in the dark.

    This code is being called from a Maven Mojo I am working on. I have created an isolated class loader for the thread that calls this method that has the entire runtime classpath and test classes classpath as well as our conf directory.
    Last edited by developer1; Jul 25th, 2012, 10:32 AM. Reason: add spring version

  • #2
    (I realize creating a new ClassPathXMLApplicationContext each time is stupid, I will be refactoring this class after I figure out this issue.)
    I suggest doing that BEFORE because this is actually the cause of the issue! Basically, you are calling the creation of a Spring context, from the code of a bean which is defined inside that context...this is wrong and is never going to work!

    Application context should be initialized only once, in the 'entry point' of your application (a listener/servlet if webapp, your main method of your Main class otherwise) and then used to get the beans that do the work. Refactor the code this way, or you'll never solve the problem.


    • #3
      I doubt it is a problem triggered by constructing a new applicationcontext (although this indeed isn't smart unless you want a system with memory and performance issues).

      The problem is probably related to classloading, the same class probably exists in different jar files in different classloaders (and it might be that the problem is becoming visible due to the construction of a new applicationcontext).