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 <njbartl...@gmail.com> 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 <ekemo...@gmail.com> 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 <jsedd...@gmail.com> > 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 <ekemo...@gmail.com> > >> 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 > >> > >
