You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Edmond Kemokai <ek...@gmail.com> on 2017/08/30 16:24:00 UTC
On Demand Imports
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
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
>
Re: On Demand Imports
Posted by Guillaume Nodet <gn...@apache.org>.
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>.
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
> >>
>
>
Re: On Demand Imports
Posted by Neil Bartlett <nj...@gmail.com>.
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
>>
Re: On Demand Imports
Posted by Edmond Kemokai <ek...@gmail.com>.
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
>
Re: On Demand Imports
Posted by Julian Sedding <js...@gmail.com>.
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