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
