Announcement Announcement Module
Collapse
No announcement yet.
Weird stacktrace Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Weird stacktrace

    Hi,

    I'm having a weird stacktrace while using a <service-activator> :

    Code:
    <int:chain input-channel="channel1" output-channel="channel2">
    	<int:service-activator method="generateTrni">
    		<bean parent="AbstractTrnGeneratorServices">
    			<property name="prefix" value="ABC" />
    		</bean>
    	</int:service-activator>
    </int:chain>
    The bean AbstractTrnGeneratorServices is present in another file in the classpath loaded in the same context :

    Code:
    <bean id="AbstractTrnGeneratorServices" class="com.TrnGeneratorServicesImpl" abstract="true" />
    At runtime, I get the stacktrace :

    04/08/10 15:26:14,944 - DEBUG org.springframework.beans.factory.support.DefaultL istableBeanFactory - Ignoring unresolvable metadata in bean definition 'AbstractTrnGeneratorServices$child#0'
    org.springframework.beans.factory.BeanDefinitionSt oreException: Invalid bean definition with name 'AbstractTrnGeneratorServices$child#0' defined in class path resource [project.xml]: Could not resolve parent bean definition 'AbstractTrnGeneratorServices'; nested exception is org.springframework.beans.factory.NoSuchBeanDefini tionException: No bean named 'AbstractTrnGeneratorServices' is defined
    BUT still, it works and the method gets successfully invoked.

    Note: Later in the log, I can see the following :

    DEBUG org.springframework.beans.factory.support.DefaultL istableBeanFactory - Creating instance of bean 'AbstractTrnGeneratorServices$child#0'
    This is not blocking, but still a bit confusing when reading the logs. Any idea where this comes from ?

    -- Pierre

    PS : Using Spring Integration 2.0 M6

  • #2
    How are you loading the multiple config files? Are you using imports or passing multiple config file paths? Is there a hierarchy?

    Comment


    • #3
      A bit of everything

      There is a hierarchy between some context files of a similar structure:
      • core-context.xml
        -> services-context.xml
        -> local-services-context.xml
        (--> AbstractTrnGeneratorServices is defined in this file)
        -> remote-services-context.xml
      • project.xml (--> <service-activator> is defined in this file)

      (in other words: core-context.xml imports services-context.xml, and the latter imports local- and remote-services-context.xml)

      And the context is loaded the following way:

      Code:
      new ClasspathXmlApplicationContext([project.xml, core-context.xml]);

      Comment


      • #4
        Interesting. So, if you are only using imports, then there is no actual hierarchy... everything is at the same level (no parent-child relationships).

        Do you see the same problem if you switch the order of the 2 config paths in the constructor call?

        Comment


        • #5
          No, the problem is gone when I change the order of the context files.

          The dependencies between the two files being only one way, this should do for me. Is this a bug?

          Comment


          • #6
            Yes, I would say it is a bug. The only question is whether it's a Spring Integration or a general Spring bug. We can investigate that and open it in the appropriate JIRA.

            Can you do one more favor? I would be interested if it works ok when you pass 'project.xml' to the constructor only and have it import 'core-context.xml').

            Thanks,
            Mark

            Comment


            • #7
              Yes, it works. No such exception.

              Would the whole stacktrace help you to investigate?

              Comment


              • #8
                I tried to reproduce it with no luck, so its definitely something to do wit the order of imports.
                I have no imports and simply doing this:
                Code:
                new ClassPathXmlApplicationContext(new String[]{"config.xml", "parent-config.xml"}, TestClass.class);
                and my configuration is simple:
                PARENT:
                Code:
                <bean id="another" class="forum.AnotherService" abstract="true"/>
                CHILD:
                Code:
                <int:channel id="output"/>
                	<int:chain input-channel="input" output-channel="output">
                		<int:service-activator>
                			<bean parent="another">
                				<property name="prefix" value="anx"/>
                			</bean>
                		</int:service-activator>
                	</int:chain>
                Could you please attach a small sample replicating the issue?

                Comment


                • #9
                  Here's how to reproduce it:

                  firstImport.xml
                  Code:
                  <int-stream:stdin-channel-adapter channel="channel1">
                  	<int:poller>
                  		<int:interval-trigger interval="1000" />
                  	</int:poller>
                  </int-stream:stdin-channel-adapter>
                  
                  <int:channel id="channel1" />
                  
                  <int:service-activator input-channel="channel1" output-channel="channel2">
                  	<bean parent="myService" />
                  </int:service-activator>
                  
                  <int:channel id="channel2" />
                  
                  <int-stream:stdout-channel-adapter channel="channel2" />
                  secondImport.xml
                  Code:
                  <bean id="myService" class="test.RandomService" abstract="true" />
                  TestClass.java
                  Code:
                  public static void main(String[] args) throws Exception {
                  	new ClassPathXmlApplicationContext("firstImport.xml","secondImport.xml");
                  }

                  Note 1: if you replace "channel2" with "nullChannel", the exception doesn't appear.

                  Note 2: the exception only appears with a logger configured at the DEBUG level.

                  Note 3: in spite of the exception, the application works fine.

                  Comment


                  • #10
                    Thank you

                    I was able to reproduce the problem and we actually have an open JIRA that is related to this, so I've attached this forum to it as well as explanation and the fix, so I would suggest to add yourself as a watcher so you can track its progress.
                    https://jira.springframework.org/browse/INT-562

                    Just so you understand, although I agree this error is nuisance, it is not affecting you, since everything is resolved correctly once the AC is created. However as I said, the issue is fixed and will be available with RC1 unless you want to try nightly build (after tonight)

                    Comment

                    Working...
                    X