Thanks Guillaume, I'll look into the servicemix approach.
On Fri, Sep 1, 2017 at 2:41 AM, Guillaume Nodet <[email protected]> wrote: > 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 >
