Inline again... On Fri, Mar 4, 2011 at 7:24 AM, Hamlet DArcy <[email protected]> wrote: > My goal is to have groovy.* packages in the Import-Package list but not the > Export-Package list. Then it will be a dependency that can vary between > bundles. And it needs to vary between bundles. We want to write and test a > customer extension today in 2011 with Groovy 1.7, deploy it, and then never > need to upgrade the Groovy version, even though next year some customers will > be on Groovy 1.8. I wrote a prototype for this in 2009 and it seemed to work.
If the customer bundles Import-Package: groovy.* then some bundle somewhere is going to have to Export-Package: groovy.*, otherwise the customer bundles will not resolve. I suggest you deploy a set of Groovy bundles that simply wrap the Groovy API and export it under the correct version. Of course you can have multiple versions of the Groovy API bundle. > The general prototype executed Groovy scripts against 3 different versions of > Groovy within the same Thread, and required 4 bundles: > > Interfaces 1.0 > - Java only bundle to define a service interface and Java based transfer > objects > - Hardly any Package-Imports, only Package-Export was defined interfaces and > transfer objects > Provider 1.6 > - Service that implements Interfaces 1.0, Import Groovy 1.6, Export only > existing shared interfaces > Provider 1.7 > - Service that implements Interfaces 1.0, Import Groovy 1.7, Export only > existing shared interfaces > Evaluator 1.0 > - Starts and runs application > - Imports Interfaces 1.0 and both Provider 1.6 and Provider 1.7 This part will be a problem... a single bundle cannot import multiple versions of the same interface. See my suggested alternative below. > - Dispatches requests to the correct Provider > > It is my belief, that Groovy can be a private dependency as long as all the > transfer objects and interfaces are defined and shared in a separate bundle, > and Groovy classes do not leak out into any shared API. Is it REALLY necessary for your Evaluator to know that the customer bundles are implemented with Groovy? If not I suggest the following alternative design: * "Interfaces" bundle exports the Provider interface * "Evaluator" bundle imports the Provider interface and tracks instances of the Provider interface. * Customer bundles publish instances of Provider as services. How they implement the Provider interface is entirely up to them... they can do it in Groovy by importing any version they like... or they can choose to implement in Java, Scala, JRuby, whatever. You can even implement your Evaluator in Groovy if you like! The service interface provides an isolation barrier between the Evaluator and the customer bundles, so they can have separate class-spaces containing separate versions of Groovy. The only classes that need to be shared are the Provider interface and any types exposed in that interface. Regards, Neil. > > > That's not really a question... just hoping someone can tell me if I'm being > naive. > > -- > Hamlet > > > > ----- Original Message ----- >> Hi Hamlet, >> >> My responses inline below. >> >> On Fri, Mar 4, 2011 at 6:50 AM, Hamlet DArcy <[email protected]> >> wrote: >> > Hi all, >> > >> > I am hoping for some architectural/design guidance. >> > >> > I have an existing application that loads & executes Groovy scripts >> > from disk in order to provide custom logic to different customers. >> > For instance, Customer X is mapped to a certain directory and the >> > custom validation rules sit in "validation.groovy" in that >> > customer's directory. We have almost 5000 scripts that get >> > executed this way. I want to use OSGi to execute the scripts >> > because then each customer can specify which version of Groovy to >> > use (modularity) but the calls are still in process and fast. >> > >> > My idea is to define an OSGi service interface and have 3 >> > implementations (Groovy 1.6, Groovy 1.7, and Groovy 1.8). The >> > script controller will know what version to execute against and >> > dispatch processing to the correct OSGi bundle that has that >> > version of Groovy as a private dependency. >> > >> > My questions: >> > 1) Do you see any obvious problems with this approach? >> >> I'm not sure if you will be able to do it using a service oriented >> approach. The reason is that I believe that your customer's Groovy >> scripts will have dependencies on the Groovy standard library. I >> don't >> know much about Groovy but I expect that it has some kind of standard >> library, equivalent to java.lang, java.util etc in the Java >> language... am I correct? >> >> If that's the case then each customer's bundle has a *static* >> dependency on a specific version of Groovy that is best expressed >> through Import-Package. For example: >> >> Import-Package: groovy.lang;version="[1.6,2.0)" >> >> This allows your customer's bundle to express that it depends on at >> least Groovy 1.6, but it will also run on 1.7, 1.8, 1.256 etc. >> >> > 2) How easy & performant is it to embed an OSGi container into my >> > existing application? >> >> Very easy if you use the OSGi R4.2 framework launching API. Just the >> following few lines of code will start an OSGi framework: >> >> FrameworkFactory factory = >> ServiceLoader.load(FrameworkFactory.class); >> Map<String,String> props = new HashMap<String,String>(); >> // set some properties >> Framework framework = factory.newFramework(props); >> framework.start(); >> >> Now install and start a bundle: >> >> Bundle b = >> >> framework.getBundleContext().installBundle("file:/path/to/my/bundle.jar"); >> b.start(); >> >> Finally wait for the OSGi framework to shutdown: >> >> framework.waitForStop(0); >> >> > 3) Do you have any recommendations on which container to use? >> >> Equinox, Felix and Knopflerfish are all fine containers and they all >> support the above API. If you stick to the standard API then you can >> remain independent of any specific container. I recommend you do >> this... then after building your application you can evaluate which >> container offers the best non-functional environment for your needs. >> >> > 4) Do you have an links or examples that are a good starting point >> > on how to do this? >> > >> > Thanks in advance, >> > >> > -- >> > Hamlet D'Arcy >> > [email protected] >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
