Grails

I've unscheduled this issue as its not a 1.0 issue and there is no decision about if or when we do go with something like OSGi

Hi Graeme,

When you think it's time to achieve it, you may leverage the power of Spring Dynamic Modules(formerly known as Spring OSGi).

Best regards,
Daniel.Sun

OSGi for plugins would be very nice to enforce dependency/versioning requirements. But i assume it would not practical in most cases to dynamically redeploy plugins into a production runtime, since the plugin lifecycle usually begins as development time (installation, upgrade, build, etc...)?

Another area that would be very beneficial is to support OSGi for decomposing the application components (domain/services/commands), into smaller subsystem bundles.

eg. each service (or set of tightly coupled services) and related domain objects could be packaged into their own bundle. Having a Grails "convention" for doing this would be wonderful.

• especially relevent for large apps.
• could specify dependency/version constraints against other subsystem bundles.
• in theory may even make the develop hot-redeploy faster if you only needed to reload the changed subsystem.

We have already broken Grails down into several distribution artifacts (grails-core, grails-web, etc.) so I think making them OSGi bundles is a natural route forward. I actually envisage this for Grails 2.0, since it will probably involve a significant restructuring of Grails.

Super! Hopefully the same infrastructure will enable a simple, "Grailicious" mechanism for users to package their application components into deployment bundles.

I support the comments by "marko.m". It would be great to use Grails on the Web tier for my applications deployed into an OSGi container, and more specifically the dmServer. I'd love to be able to add a Spring DM osgi-context to my Grails application that would allow for the use of Spring services from bundles deployed in my dmServer context.

I got Grails to run in an OSGi environment. See http://blog.jetztgrad.net/grails-on-osgi/ for my results. So far, a Grails app is running fine as a monolithic bundle (i.e. all dependencies included) after adding proper OSGi headers.

The next step will be remove all dependencies from the war file and deploy them as their own bundles. There are som eproblems with that:

1) Need OSGi bundles for each dependency (some are available in SpringSource Enterprise Bundle Repository)
2) Classloading Issues: Hibernate must be able to "see" the Domain classes
3) Singleton issues, when running more than one Grails app: Singletons like ApplicationHolder or ConfigurationHolder keep one reference to the corresponding object. We need a way to determine, which application is asked for

I think that most problems can be solved with some work. I will report my findings here and on my blog.

I created an OSGi plugin fro Grails (http://grails.org/plugin/osgi), which allows running a Grails application within an OSGi environment. For now, this means turning the WAR file into a valid OSGi bundle by providing appropriate manifest headers.

In a later version I plan to support modularization and importing/exporting service to and from the OSGi service registry. This might require some changes in Grails as well, mostly regarding singletons.

I think the added value of having this feature does not outweigh the considerable effort to implement it. The Springsource-led OSGi hype has sort of quieted down, probably because people have found out it is a Really Hard Thing to do, especially when using software like Hibernate.

Only in very specialized usecases does the idea of 'look i can replace a bundle' really have benefit.

Furthermore, Wolfgang's OSGI plugin already allows a grails app to run in an OSGi container (albeit as a monolith), for those that really have to.

I would vote for resolving this with a 'won't fix'...