You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@apache.org> on 2017/09/01 06:41:59 UTC
Re: On Demand Imports
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 <ek...@gmail.com>:
> 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 <nj...@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 <ek...@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 <js...@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 <ek...@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
> > >>
> >
> >
>
--
------------------------
Guillaume Nodet
Re: On Demand Imports
Posted by Edmond Kemokai <ek...@gmail.com>.
Thanks Guillaume,
I'll look into the servicemix approach.
On Fri, Sep 1, 2017 at 2:41 AM, Guillaume Nodet <gn...@apache.org> 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 <ek...@gmail.com>:
>
> > 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 <nj...@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 <ek...@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 <js...@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 <ekemokai@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
> > > >>
> > >
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
>