Announcement Announcement Module

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Spring 3.0 M3 + Spring DM = broken javaconfig? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring 3.0 M3 + Spring DM = broken javaconfig?


    We are experiencing what seems to be badly broken application context behavior in our application.

    Specifically, we are using the most recent released version (1.2.0) of Spring dm (NOT dm server!) on top of a recent version of the Equinox OSGi container. We've decided to try Spring 3.0 M3. Spring 3.0 M3 has built-in support for "javaconfig"-style configuration as an alternative to defining beans in XML, via the @Configuration, @Bean, etc annotations.

    What we are seeing is that when we us @Configuration-annotated configuration classes to define our beans, that our singleton beans are instead treated as prototype beans. This means that we get new instances of our singletons for each time they are referenced (!!!).

    I have created sample code which demonstrates this broken behavior.

    This code, when run as a regular java application, (NOT OSGi), works as expected (only one instance of Foo and Bar are created).

    BUT, when the identical code is run via Spring DM, 3 different instances of Bar are created!

    Note: I used a FileSystemXmlApplicationContext to load this when running as a normal java application, and put the config.xml file inside a /META-INF/spring folder when running in Spring dm.

    package com.example.configtest;
    public class Foo {
    	private Bar bar1;
    	private Bar bar2;
    	public Foo(Bar bar1, Bar bar2) {
    		this.bar1 = bar1;
    		this.bar2 = bar2;
    	public void init() {
    	public String toString() {
    		return "I am a Foo (" + 
    			System.identityHashCode(this) + 
    			") with bar1 = " + bar1.toString() + 
    			" and bar2 = " + bar2.toString();

    package com.example.configtest;
    public class Bar {
    	public Bar() {
    		System.out.println("(..constucting a Bar)");

    package com.example.configtest;
    import org.springframework.context.annotation.Bean;
    import org.springframework.context.annotation.Configuration;
    public class Config {
    	public Bar bar() {
    		return new Bar();
    	public Foo foo() {
    		return new Foo(bar(), bar());

    <?xml version="1.0" encoding="UTF-8"?> 
    <beans xmlns=""
    	<bean id="config" class="com.example.configtest.Config" />
    	<context:component-scan base-package="com.example.configtest" />
    Console output when run as a normal java app:

    (..constucting a Bar)
    got Bean: I am a Foo (4824957) with bar1 = [email protected] and bar2 = [email protected]
    Console output when run as a Spring DM app:

    (..constucting a Bar)
    (..constucting a Bar)
    (..constucting a Bar)
    I am a Foo (3141854) with bar1 = [email protected] and bar2 = [email protected]
    This seems like a pretty major incompatibility! Is anyone else using this combination of technologies (Spring 3 M3, Spring DM, @Configuration)? Should I assume that this combination is not recommended by SpringSource?

    -Dave Fogel

  • #2
    We're trying to make a decision on whether or not we can use this combination of Spring tools. We're still having this problem and it's blocking our development.
    • Is there something missing, we left out, doing wrong in the code sample Dave provided above?
    • Has the SpringSource folks tested Spring DM with Spring 3.0 M3?
    • Is this a known issue that's currently being work on?

    I pinged Chris Beams via Twitter, we haven't received a response there either. It would be helpful to know if we're doing something wrong here. If not, then that lead developers of both the DM and JavaConfig projects are aware of this major incompatibility.


    • #3
      Guys, a first guess would be that the classloaders in OSGi change the way the 'javaconfig'-like factory does caching/discovery which might result in multiple instances being created.

      Please raise an issue on the Spring JIRA along with your sample and some logs (if you have any). If you haven't already, turn on logging on the appropriate packages to see what's going on.

      P.S. Sorry for the late replies, but it's the holidays season and people (including myself) are (about to go) on holidays for weeks. Expect things to be a bit slow.. Thanks for understanding.


      • #4
        Hi Costin, etc-

        I've opened a jira issue for Spring DM 1.2. I hope I did it right, I'm not familiar with your issue system conventions. should I have also registered it as a bug in the main spring framework project?

        I understand that many of the spring folks may be on vacation, and that this issue may not get much attention for a while. Given that, I'm still struggling to understand what the current recommended solution is for using _current_ Spring technologies together. We want to use Spring DM. We want to use javaconfig-style configuration (this is not just an idle preference, we need to use a 3rd-party library which is very difficult to configure using XML). It was previously recommended (in the javaconfig forum) that we try to use the Spring 3.0 M3 builds with the built-in javaconfig features, since that is "the future", but we ran into this issue.

        My concern is that there really doesn't appear to be much overlap between the Spring DM/osgi community of developers and the Spring 3.0/javaconfig community. The spring dm releases contain Spring 2.5.6, not 3.0. When I poked around on the spring site, I found that the latest Spring dm 2.0M1 builds up on amazon s3 had timestamps from April.

        Any suggestions for how to navigate this landscape?

        -Dave Fogel


        • #5
          Hi Dave, Eric -- thanks for your patience on this one. I've assigned the issue you created to me and will be looking into it tomorrow.

          Stay tuned, we'll get this worked out!


          • #6

            Hi Chris-

            I just wanted to post here to follow up on this issue. For other reader's sake, the issue link is here:


            You mentioned that this is now fixed in the nightly builds. We're having trouble with verifying the new behavior, not sure if we're doing this right:

            We don't use maven, and the maven repo doesn't appear to be browsable. So we attempted to get the nightly build from last night by going to, clicking on "downloads", and then clicking on the link to the nightly download area, which opened a new window at this URL:


            These builds don't appear to have dates on them, so we took the one with the highest number, in this case we downloaded "spring-framework-3.0.0.CI-330"

            After updating my environment with the 3.0.0.CI-330 jars, our test case still doesn't work- multiple "Bar" objects are being created when it's supposed to be a singleton. We did change to using the <context:annotation-config /> as well.

            Did we get the wrong build?

            Thanks again,

            -Dave Fogel


            • #7
              Dave -

              It is a little difficult to access the snapshots if you're not using Maven. Are you using Ant? If so, have you considered Ivy as a dependency manager? That's an aside, though.

              To browse the repository, you can use s3browse:


              If you page all the way to the end of that list, you'll find the most recent snapshot builds. You want the stuff from yesterday's (0715) build, specifically, you want the changes in org.springframework.context. Here's the link to that jar:


              However, you'll want to download all the 0715 jars that you're using in your application (.beans, .core, etc...). If you keep browsing around the site above, you'll be able to find everything that you need.

              I'll see fixing that download link that you originally followed. Those builds are older and now obsolete. Thanks for bringing it to my attention.


              • #8

                On further review, the .CI-### links are actually correct. You can see that they are aligned with the build numbers coming out of Bamboo here:

                Now, with that said, I was under the impression that my fixes for this issue made it into yesterday's nightly build; they in fact did not. Build 331 is in progress as I write this (see, and once that's finished, you should see a new link on the downloads page of the .org site (CI-331).

                Give that a shot, and let me know if there are any issues.



                • #9
                  still not working

                  [Edit: Ooops! Just saw your post above. we will try the new build. sorry!]

                  Hi Chris-

                  Following your advice in your last post, we downloaded what we think are the correct nightly build files, e.g.:

                  ...(plus all the other 0715 jars)

                  but our test still fails, and 3 Bar objects are created.

                  looking in the source code in the unpacked sources.jar above in the file, I see the following method:

                  private Class<?> createClass(Enhancer enhancer) {
                  Class<?> subclass = enhancer.createClass();
                  Enhancer.registerCallbacks(subclass, this.callbackInstances.toArray(new Callback[this.callbackInstances.size()]));
                  return subclass;

                  where I notice that the call to Enhancer.registerCallbacks(...) has not been changed to Enhancer.registerStaticCallbacks(...), which is what you described changing. Do we still have the wrong nightly?


                  • #10
                    is it okay to use a build that Failed?

                    Hi Chris-

                    It looks like Build 331 has failed, according to the Bamboo page you linked to above. Should I still attempt to use it? (I'm unfamiliar with Bamboo and what it means to fail- is it just that some tests didn't pass?)



                    • #11
                      Dave, just checking that the fix works for you.
                      Let me know if that's not the case.



                      • #12
                        Following up on Dave's latest post - the change was indeed committed. You may have been looking at an older revision.

                        Take a look here: