Announcement Announcement Module
Collapse

JavaConfig forum decommissioned in favor of Core Container

As described at

http://static.springsource.org/sprin...fig/README.TXT

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:

http://static.springsource.org/sprin...tml#beans-java

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at

http://forum.springsource.org/forumdisplay.php?f=26
See more
See less
JavaConfig and OSGi - is it supposed to work? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JavaConfig and OSGi - is it supposed to work?

    Hello-

    I've been trying to get JavaConfig working in my OSGi environment. I'm using eclipse equinox, pretty basic, barebones setup. I am _not_ using Spring DM in this particular project.

    It looks like various parts of JavaConfig, in particular the cglib and asm-related code, is making various assumptions about classloaders that isn't friendly to the OSGi environment, where every bundle has its own classloader. But to be clear, I'm really not sure what the problem is.

    Since SpringSource seems to be building a lot of its tooling and projects around OSGi (Spring dm server, eclipse tools, etc) I'm surprised that there's almost nothing that shows up either in these forums or in google searches for people trying to use javaconfig in an OSGi environment.

    Has anyone here successfully used javaconfig in an OSGi bundle? If so, are there any tricks to get it working?

    Thanks,
    -Dave Fogel

  • #2
    Hi Dave,

    'official support' between the two projects is still pending. I believe some users have had success, but YMMV. As you may know, JavaConfig functionality is largely moving into Spring Core for Spring 3.0. By the time Spring 3.0 GA is released (June), we'll be sure to have polished support for using @Configuration classes in an OSGi environment.

    In the meantime, any experience/problem reports would be appreciated.

    Comment


    • #3
      I've created an issue to officially track this. http://jira.springframework.org/browse/SPR-5632. Dave, feel free to add yourself as a 'watcher' to stay notified, and please comment there as you see fit.

      Comment


      • #4
        Dave, you may have noticed that SPR-5632 is now resolved. Any feedback you may have on the latest nightly snapshots would be very much appreciated.

        Comment


        • #5
          Hi Chris-

          Thanks very much for following up on this!

          I looked at the SPR-5632 issue- there is not much information there as to what or how "compatibility" has been ensured.. :-)

          I will definitely check out the latest snapshot - I'm assuming you mean the snapshot of spring 3.0? which now includes javaconfig? or do I still need the separate JavaConfig distribution? I guess I'm still a little unsure of the relationship between the various downloads of spring 3, spring dm, and javaconfig...

          thanks again,
          -Dave Fogel

          Comment


          • #6
            It's been an internal process of testing with the Spring DM and Spring Core teams to 'ensure compatibility'.

            Regarding what to download, if you grab the latest Spring DM and latest Spring Core snapshots, you should be good to go.

            As for JavaConfig proper (the project), it does not yet work with the code that's been moved over to Spring 3. It will catch up, but it basically means that you need to either use the support in Spring 3 core, or the support from the JavaConfig project, but not both.

            For example, there is no JavaConfigApplicationContext in Spring Core. Rather, bootstrapping is done via XML, and if you register a @Configuration class (or use <context:component-scan/> to pick one up), the @Beans registered in that @Configuration class will be available from your (Xml) ApplicationContext.

            There are a number of annotations that have not made the move from JavaConfig to Core. Just take a look at the org.springframework.context.annotation package and you'll see what's available.

            Comment


            • #7
              Hi all,

              I would like to start using java config ASAP but I donīt want to compromise my current project dependency configuration. Here is a snipet from my pom:

              Code:
              ...
              		<!-- spring bundles -->
              		<dependency>
              			<groupId>org.springframework</groupId>
              			<artifactId>org.springframework.spring-library</artifactId>
              			<type>libd</type>
              			<version>2.5.6.SEC01</version>
              		</dependency>
              ...
              One possible solution is to have a jar on my servletīs lib path until I can change the version above to 3.0.0 (July/August). Would this be recommended? Should I prefer the current JavaConfig m4 version (SPR-5632 issue)?

              Thanks,

              Mauricio
              Last edited by iserv; Jun 28th, 2009, 09:59 AM. Reason: Posted accidentally

              Comment


              • #8
                Spring 3.0 M3 + Spring DM = broken javaconfig?

                Hi Chris-

                I've been trying out Spring 3's built-in support for javaconfig-style @Configuration use, as you suggested. We've run into a problem where our singleton beans are being treated like prototype beans, but only when run inside of Spring dm- otherwise they work as expected.

                I posted about this in the Spring Dynamic Modules forum, along with example code that shows this problem:

                http://forum.springsource.org/showthread.php?t=74458

                Do you have any idea what could be going wrong here? It doesn't seem like there are that many people making use of the javaconfig features in Spring 3 yet, and even fewer trying to use it from Spring DM, so we're feeling a little too bleeding edge here. Seems odd, though, since this seems to me like the direction that Spring framework as a whole is moving in...

                Any help would be appreciated!

                -Dave Fogel

                Comment

                Working...
                X