That's a good point... OSGi has a way to specify dependencies, and I'm using OSGi, so using the features of OSGi is a better design than trying to handroll dependency declarations based on what directory a file sits in. I think I understand correctly.
Thanks for the help everyone. It is very cool to get such prompt responses from the OSGi bigwigs themselves :) ----- Original Message ----- > So why not JAR up all scripts in a directory as a bundle? It is then > to have a normal extender that turns each script into a service (or > a service for all scripts of a specific customer if there are too > many). The script bundle should use Require-Bundle to the correct > groovy bundle (yes I am saying this, there are use cases for R-B, > they are just not general). If a file changes in the directory, just > update the bundle. You can do the wrapping on the fly if you use a > PipedOutputStream/PipedInputStream. > > Groovy would then use the Bundle's class loader as the its script > class loader. This way you let OSGi do all the shitty class loading > work. > > Kind regards, > > Peter Kriens > > > On 4 mrt 2011, at 15:15, Hamlet DArcy wrote: > > >> So how do you know what version of Groovy these scripts are > >> written in? > > > > We don't know today, but that could be easily solved with a > > convention of some sort (directory, filename, #! line, or a > > registry of some sort). > > > > > > > > > > ----- Original Message ----- > >> So how do you know what version of Groovy these scripts are > >> written > >> in? > >> > >> Kind regards, > >> > >> Peter Kriens > >> > >> On 4 mrt 2011, at 12:59, Hamlet DArcy wrote: > >> > >>>> Are the scripts stored as text on disk or packaged as a bundle? > >>> > >>> Today, the scripts are stored on disk as files. > >>> > >>> I propose that I create a new Bundle/Service around the object > >>> that > >>> knows how to read and evaluate the script. So the scripts remain > >>> simple, unpackaged text files outside of any Jar/Bundle, but the > >>> script processor be a valid OSGi service. > >>> > >>> -- > >>> Hamlet > >>> > >>> > >>> ----- Original Message ----- > >>>> Are the scripts stored as text on disk or packaged as a bundle? > >>>> > >>>> Kind regards, > >>>> > >>>> Peter Kriens > >>>> > >>>> > >>>> On 4 mrt 2011, at 07:50, Hamlet DArcy 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? > >>>>> 2) How easy & performant is it to embed an OSGi container into > >>>>> my > >>>>> existing application? > >>>>> 3) Do you have any recommendations on which container to use? > >>>>> 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 > >> > > _______________________________________________ > > 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
