Announcement Announcement Module

JavaConfig forum decommissioned in favor of Core Container

As described at

key features of the Spring JavaConfig project have been migrated into the core Spring Framework as of version 3.0.

Please see the Spring 3.0 documentation on @Configuration and @Bean support:

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at
See more
See less
When will JavaConfig support Spring Dynamic Modules? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • When will JavaConfig support Spring Dynamic Modules?


    Does anyone know when/if JavaConfig will support Spring DM? In particular, when I'd be able to use javaconfig code to import and export OSGi services, not just to configure the beans.

    Is this something we can expect in Spring 3.0? Even better would be if someone has figured out a way to do this now..

    -Dave Fogel

  • #2
    So, anyone at SpringSource know the answer to this question? It seems like a pretty straightforward one :-)

    To be clear, I'm interested in, for instance, being able to add an annotation to (or replace) the @Bean annotation on methods in an @Configuration class to register OSGi services, and I'd like to use some sort of type-safe method of accessing OSGi services from other bundles in a manner consistent with Spring DM.


    Thanks very much!

    - Dave Fogel


    • #3
      I'm hoping there's some explanation for the lack of any answers to this simple question, other than no one at springsource knowing the answer, which implies a distinct lack of interest in JavaConfig, given how much effort springsource seems to be putting into spring dm server, etc. Does JavaConfig have a future in that world?

      Sorry if that came across as grumpy- I'm just very eager to understand how this all fits together so I can make the right decision now for our company's tech stack.



      • #4
        Hi Dave,

        I actually responded to your similar thread on this matter a couple weeks ago. The short answer is that JavaConfig + OSGi is an untested combination right now, and that Spring 3.0 support for JavaConfig will remove this ambiguity. Per the tracking issue at, we will make sure that @Configuration class processing works properly in an OSGi context by Spring 3.0 GA.


        - C


        • #5
          Hi Chris-

          Thanks for replying. Although related and somewhat similar, my previous question was really about simply getting JavaConfig to work at all in my (not-DM) OSGi environment, and was prompted by classloading issues I encountered while doing this.

          This question is specifically about when JavaConfig might add support for Spring DM features (which is different from straight OSGi). And I don't mean simply including a JavaConfig-style Configuration class in my Spring DM XML, I mean making use of spring DM features from within my Configuration class, using JavaConfig-style type-safe annotations and java code!

          There is a real distinction there. Spring DM is a significant layer on top of standard OSGi. But if I have to use XML config files for that, it makes using JavaConfig for parts of it much less attractive.

          I've had enough of the whole XML configuration thing. I looked at Guice (and Peaberry, a guice-osgi module), and I didn't like it very much, and don't want to use the annotated-pojo stratgey they use for DI. I personally think JavaConfig should be the future direction of the entire Spring project. But right now it's not clear what you guys think about that.

          Looking forward to hearing your thoughts,

          -Dave Fogel


          • #6

            Sorry for the confusion. Whether Spring DM or straight OSGi, compatibility is a very important requirement for @Configuration support in Spring 3.0.

            The initial cut of support that will be released in the forthcoming 3.0 M3 has not been fully tested against Spring DM or straight OSGi, but per the previously mentioned JIRA issue, this will be done.

            If you'd like to contribute to (read: potentially expedite) the process, feel free to attach a test case to the JIRA issue that demonstrates what you'd like to do with @Configuration classes, and what goes wrong.

            Thanks for your patience, and know that we are committed to this.