ServiceMix provides a modified version of the scripting api which supports discovery of service providers in an OSGi compatible way:
https://repo1.maven.org/maven2/org/apache/servicemix/specs/org.apache.servicemix.specs.scripting-api-1.0/2.9.0/ 2017-09-01 1:59 GMT+02:00 Edmond Kemokai <[email protected]>: > Hi Neil, > > Thanks for the input...I'll probably end up rolling a custom solution using > DI-P in some way as you suggested. The platform I am developing ( > codesolvent.com) uses bundles that implement JSR-223. JSR-223 itself has > its own OSGi compatibility problem having to do with the service discovery > mechanism used to locate ScriptEngineFactory interface implementations. > > > It would have been nice if OSGi provided off-ramp options such as I > described, or allowing an easy way to extend/augment the bundle class > loading. > > Ultimately it may just be easier to modify script engine bundles to include > DI-P:*, this would solve the problem though perhaps not the best approach. > > Regards > Edmond > > On Wed, Aug 30, 2017 at 9:32 PM, Neil Bartlett <[email protected]> > wrote: > > > You’re already aware of DynamicImport-Package, so in what way does that > > not work for you? A bundle that uses "DynamicImport-Package: *” can use > any > > exported package from any bundle. > > > > Of course this is pretty dangerous… I would recommend running the scripts > > in the context of a special bundle that uses DI-P and only exists to > > execute scripts, i.e. it should contain no Java code. > > > > Regards, > > Neil > > > > > > > On 30 Aug 2017, at 23:23, Edmond Kemokai <[email protected]> wrote: > > > > > > Hi Julian, > > > > > > Thanks for the Sling pointer. I have taken a look at the code and see > > that > > > using this approach basically requires hacking the ScriptEngineFactory > of > > > various script engines, something I don't have the bandwidth for. > > > > > > > > > I was hoping there was a solution that the OSGi framework itself could > > > facilitate, similar to what I described. The approach that Sling uses > > would > > > require me to figure out what each script engine's class loading > behavior > > > is and extend that mechanism, that sounds painful :) > > > > > > Regards > > > Edmond > > > > > > On Wed, Aug 30, 2017 at 1:09 PM, Julian Sedding <[email protected]> > > wrote: > > > > > >> Hi Edmond > > >> > > >> Apache Sling solves this problem by using a Dynamic Class Loader [0]. > > >> This bundle provides a DynamicClassLoaderManager service that you can > > >> depend on. It provides a class loader that can delegate to each > > >> bundle's class loader. When a bundle's state changes (e.g bundle is > > >> stopped), the service is re-registered and updated to reflect the new > > >> system state. > > >> > > >> If you use declarative services and your component has a static > > >> reference to the DCLM, your service is automatically re-started as > > >> well. > > >> > > >> Regards > > >> Julian > > >> > > >> [0] https://github.com/apache/sling/tree/trunk/bundles/ > > commons/classloader > > >> > > >> On Wed, Aug 30, 2017 at 6:24 PM, Edmond Kemokai <[email protected]> > > >> wrote: > > >>> Hi Folks, > > >>> > > >>> I am in need of an "On Demand" import functionality with the OSGi > > >> framework > > >>> but not sure if something like this already exists before doing > > >> unnecessary > > >>> work. > > >>> > > >>> > > >>> Basically an "On Demand" import would be a combination of a > > >>> DynamicImport-Package and an optional Import-Package. > > >>> > > >>> > > >>> I am developing a JSR-223 web app platform (solvent.com). I need to > > >> allow > > >>> scripts to dynamically load imported classes without having to > somehow > > >> make > > >>> the bundle that provides the scripting engine to be aware of these > > >> imports. > > >>> Basically there is an infinite number of possible packages that a > > script > > >>> could need to import so there is no way to specify that using static > > >>> manifest files. > > >>> > > >>> > > >>> What is required for allowing for this kind of import is to add a > > method > > >>> importPackage to the Bundle interface. This method would allow for > > >>> specifying an Import-Package header statement that the framework > would > > >>> attempt to resolve at the time of the invocation of this > > >>> method....similarly an "On Demand" exportPackage could be added to > the > > >>> Bundle interface. > > >>> > > >>> > > >>> Is there already functionality like this available that I am not > aware > > >> of? > > >>> > > >>> Regards > > >>> Edmond > > >> > > > > > -- ------------------------ Guillaume Nodet
