Grails
  1. Grails
  2. GRAILS-2221

To implement grails plugin system based on OSGI

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      To implement grails plugin system based on OSGI

        Issue Links

          Activity

          Daniel.Sun created issue -
          Graeme Rocher made changes -
          Field Original Value New Value
          Fix Version/s 1.0 [ 11939 ]
          Hide
          Graeme Rocher added a comment -

          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

          Show
          Graeme Rocher added a comment - 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
          Hide
          Daniel.Sun added a comment -

          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

          Show
          Daniel.Sun added a comment - 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
          Graeme Rocher made changes -
          Fix Version/s 1.2 [ 14155 ]
          Hide
          marko.m added a comment -

          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.
          Show
          marko.m added a comment - 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.
          Hide
          Peter Ledbrook added a comment -

          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.

          Show
          Peter Ledbrook added a comment - 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.
          Hide
          marko.m added a comment -

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

          Show
          marko.m added a comment - Super! Hopefully the same infrastructure will enable a simple, "Grailicious" mechanism for users to package their application components into deployment bundles.
          Graeme Rocher made changes -
          Fix Version/s 2.0 [ 15421 ]
          Fix Version/s 1.2 [ 14155 ]
          Graeme Rocher made changes -
          Link This issue is depended upon by GRAILS-5278 [ GRAILS-5278 ]
          Hide
          Brent Baxter added a comment -

          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.

          Show
          Brent Baxter added a comment - 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.
          Hide
          Wolfgang Schell added a comment -

          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.

          Show
          Wolfgang Schell added a comment - 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.
          Hide
          Wolfgang Schell added a comment - - edited

          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.

          Show
          Wolfgang Schell added a comment - - edited 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.
          Graeme Rocher made changes -
          Assignee Graeme Rocher [ graemerocher ]
          Hide
          Hans Westerbeek added a comment -

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

          Show
          Hans Westerbeek added a comment - 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'...
          Contegix Support made changes -
          Project Import Thu Mar 24 21:22:24 CDT 2011 [ 1301019744151 ]
          Burt Beckwith made changes -
          Workflow jira [ 33330 ] Grails [ 40479 ]
          Burt Beckwith made changes -
          Workflow Grails [ 40479 ] Copy of Grails [ 47910 ]
          Burt Beckwith made changes -
          Workflow Copy of Grails [ 47910 ] Grails [ 55320 ]
          Burt Beckwith made changes -
          Workflow Grails [ 55320 ] Grails2 [ 62869 ]
          Burt Beckwith made changes -
          Workflow Grails2 [ 62869 ] jira [ 78818 ]
          Burt Beckwith made changes -
          Workflow jira [ 78818 ] Grails2 [ 86856 ]
          Peter Ledbrook made changes -
          Last Reviewed 01/Jan/10
          Peter Ledbrook made changes -
          Workflow Grails2 [ 86856 ] jira [ 95205 ]
          Peter Ledbrook made changes -
          Workflow jira [ 95205 ] Grails2 [ 103331 ]
          Hide
          Henrique Lobo Weissmann (Kico) added a comment -

          Is there any plan to add OSGi support for Grails like was planned for 2.0 on this issue?
          What happened to this idea?

          Show
          Henrique Lobo Weissmann (Kico) added a comment - Is there any plan to add OSGi support for Grails like was planned for 2.0 on this issue? What happened to this idea?
          Hide
          Kim Betti added a comment -

          I hope that it has been scrapped.. I don't think it's a good idea to introduce this level of additional complexity.

          Show
          Kim Betti added a comment - I hope that it has been scrapped.. I don't think it's a good idea to introduce this level of additional complexity.
          Graeme Rocher made changes -
          Fix Version/s 3.0 [ 11042 ]
          Hide
          Graeme Rocher added a comment -

          OSGi as a technology is going nowhere and introduces huge amounts of complexity, something which we do not need.

          There is a need to modularise applications, but that should be done in a micro-services approach, which is something we would like to support.

          Given that I'm closing this issue as "Won't fix"

          Show
          Graeme Rocher added a comment - OSGi as a technology is going nowhere and introduces huge amounts of complexity, something which we do not need. There is a need to modularise applications, but that should be done in a micro-services approach, which is something we would like to support. Given that I'm closing this issue as "Won't fix"
          Graeme Rocher made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Graeme Rocher [ graemerocher ]
          Resolution Won't Fix [ 2 ]
          Hide
          Sergei Rahouski added a comment -

          Grails application is a brick once it is built. It is really hard to add anything to it at runtime.

          Lots of applications that go beyond 15 minutes blog demo need some sort of extensibility platform. Examples of such:
          a) Multi-tenant SaaS deployment - adding per tenant extensions that would require redeploy the whole application is a pain
          b) Vendor made enterprise apps - once released these applications need to be enhanced by the customer application group. Grails doesn't have a good answer for this either - other than shipping the source code.
          c) Large applications - the build time grows as application grows. Modularizing larger application would improve productivity. Binary plugins sort of answer this problem but I feel like if there was a way to build and deploy a piece of the larger app at lower cost it would be better than recreating the whole thing.

          IMO OSGi as technology is dead is a bold statement so as the statement about increased complexity. In fact you guys @Grails decided to break your code in modules and seemingly increased the complexity of the whole thing.

          Hopefully you'll reconsider one day.

          Show
          Sergei Rahouski added a comment - Grails application is a brick once it is built. It is really hard to add anything to it at runtime. Lots of applications that go beyond 15 minutes blog demo need some sort of extensibility platform. Examples of such: a) Multi-tenant SaaS deployment - adding per tenant extensions that would require redeploy the whole application is a pain b) Vendor made enterprise apps - once released these applications need to be enhanced by the customer application group. Grails doesn't have a good answer for this either - other than shipping the source code. c) Large applications - the build time grows as application grows. Modularizing larger application would improve productivity. Binary plugins sort of answer this problem but I feel like if there was a way to build and deploy a piece of the larger app at lower cost it would be better than recreating the whole thing. IMO OSGi as technology is dead is a bold statement so as the statement about increased complexity. In fact you guys @Grails decided to break your code in modules and seemingly increased the complexity of the whole thing. Hopefully you'll reconsider one day.

            People

            • Assignee:
              Graeme Rocher
              Reporter:
              Daniel.Sun
            • Votes:
              76 Vote for this issue
              Watchers:
              63 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Last Reviewed:

                Development