This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

JavaConfig and OSGi - is it supposed to work?

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?

'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.

Comment

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...

Comment

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.

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)?

Comment

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:

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...