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
>

Reply via email to