Thanks for the prompt response Neil,
> 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. 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. 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 - 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. 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
