About boot class path framework extensions

[Lucas Galfaso <lg...@gmail.com>]

Hi,
  Would it be possible/within the spec if, when deploying a boot class
path fragment bundle, for Felix to install the bundle and keep it at
the INSTALLED state and not move it to the RESOLVED state? This is to
actually install the bundle and refuse to change it to RESOLVED,
instead of refusing to install the bundle.


  Context for this question to make sense:

  So far, I was able to work around all needs to have a bundle that
does a boot class path, but now I need to run Felix with a class path
that I cannot control and within this Felix, need to do Jaas
authentication. As you probably know LoginModule and LoginContext is
not as OSGi friendly as one may like, so at a minimum there is a need
to add a LoginModuleProxy to the boot class path (somehow just like
what Karaf does, but with small changes so blueprint is not needed).
Felix does not support boot class path fragment bundles, so to work
around this, I did a bundle that performs the following tasks:
  - Deploys a framework extension bundle that exports the package
com.sun.tools.attach (of course, without the implementation)
  - Attaches to the JVM and deploys an agent
  - The agent does Instrumentation::appendToBootstrapClassLoaderSearch
to append the .jar to the boot class path
  - Detach the agent
  - Deploy a framework extension bundle that exports the packages at
the .jar (without any implementation)

This is Sun/Oracle JVM specific way to do this, but it gets the job done.


Now, I would like to build a bundle that, when a user tries to deploy
a boot class path fragment bundle, it does all this. This is, deploy a
bundle that would add this capability to Felix in a more ad-hoc way.
Once again, this might not be ideal, but it gets the job done. The
issue is that Felix just throws when it sees a boot class path
fragment bundle and refuses to do anything with it, so there is no way
for an external bundle to deploy the fragment using the mechanism
described above.


Regards,
  Lucas

Re: About boot class path framework extensions

[Lucas Galfaso <lg...@gmail.com>]

Hi,
  My comments inline.


On Sun, Jul 15, 2012 at 5:56 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 7/15/12 16:35 , Lucas Galfaso wrote:
>>
>> Hi,
>>    Would it be possible/within the spec if, when deploying a boot class
>> path fragment bundle, for Felix to install the bundle and keep it at
>> the INSTALLED state and not move it to the RESOLVED state? This is to
>> actually install the bundle and refuse to change it to RESOLVED,
>> instead of refusing to install the bundle.
>>
>>
>>    Context for this question to make sense:
>>
>>    So far, I was able to work around all needs to have a bundle that
>> does a boot class path, but now I need to run Felix with a class path
>> that I cannot control and within this Felix, need to do Jaas
>> authentication. As you probably know LoginModule and LoginContext is
>> not as OSGi friendly as one may like, so at a minimum there is a need
>> to add a LoginModuleProxy to the boot class path (somehow just like
>> what Karaf does, but with small changes so blueprint is not needed).
>> Felix does not support boot class path fragment bundles, so to work
>> around this, I did a bundle that performs the following tasks:
>>    - Deploys a framework extension bundle that exports the package
>> com.sun.tools.attach (of course, without the implementation)
>>    - Attaches to the JVM and deploys an agent
>>    - The agent does Instrumentation::appendToBootstrapClassLoaderSearch
>> to append the .jar to the boot class path
>>    - Detach the agent
>>    - Deploy a framework extension bundle that exports the packages at
>> the .jar (without any implementation)
>>
>> This is Sun/Oracle JVM specific way to do this, but it gets the job done.
>>
>>
>> Now, I would like to build a bundle that, when a user tries to deploy
>> a boot class path fragment bundle, it does all this. This is, deploy a
>> bundle that would add this capability to Felix in a more ad-hoc way.
>> Once again, this might not be ideal, but it gets the job done. The
>> issue is that Felix just throws when it sees a boot class path
>> fragment bundle and refuses to do anything with it, so there is no way
>> for an external bundle to deploy the fragment using the mechanism
>> described above.
>
>
> Are you really trying to create a general mechanism here (i.e., a poor man's
> implementation of the spec feature)? If not, why not just have your bundle
> add the content that it needs directly and be done with it?

  Yes, I am trying to do this poor man's implementation. The work
around just to deploy the few classes needed to make Jaas work is
already there.

>
> If yes, then perhaps you could install your boot class path bundles using a
> URL handler with a different protocol so you can massage away the boot class
> path extension fragment and just convert into into a framework extension
> fragment, where you take care of the other issues on the side.

Nice alternative.

>
> The difficulty of just allowing this to pass into the installed state in the
> "normal" case as you suggest is that it gives the impression that the Felix
> framework does something with this extension, when it doesn't.

I kind of agree that having the bundle installed and left at the
INSTALLED state can cause some confusion, but there is a difference
between INSTALLED and RESOLVED that users should be aware of.

> Further, and
> perhaps worse, in your case the dependencies wouldn't be tracked at all, so
> if the extension bundle was uninstalled the framework wouldn't know that
> anyone depended on it.

Bundles would depend on the framework extension bundle that exposes
the packages. Anyhow agree, that refresh and uninstall can be an issue
as there is the need to restart the JVM and this cannot be done
without external help, but I somehow think this is another problem.

Regards,
  Lucas


>
> -> richard
>
>>
>>
>> Regards,
>>    Lucas
>
>
>

Re: About boot class path framework extensions

["Richard S. Hall" <he...@ungoverned.org>]

On 7/15/12 16:35 , Lucas Galfaso wrote:
> Hi,
>    Would it be possible/within the spec if, when deploying a boot class
> path fragment bundle, for Felix to install the bundle and keep it at
> the INSTALLED state and not move it to the RESOLVED state? This is to
> actually install the bundle and refuse to change it to RESOLVED,
> instead of refusing to install the bundle.
>
>
>    Context for this question to make sense:
>
>    So far, I was able to work around all needs to have a bundle that
> does a boot class path, but now I need to run Felix with a class path
> that I cannot control and within this Felix, need to do Jaas
> authentication. As you probably know LoginModule and LoginContext is
> not as OSGi friendly as one may like, so at a minimum there is a need
> to add a LoginModuleProxy to the boot class path (somehow just like
> what Karaf does, but with small changes so blueprint is not needed).
> Felix does not support boot class path fragment bundles, so to work
> around this, I did a bundle that performs the following tasks:
>    - Deploys a framework extension bundle that exports the package
> com.sun.tools.attach (of course, without the implementation)
>    - Attaches to the JVM and deploys an agent
>    - The agent does Instrumentation::appendToBootstrapClassLoaderSearch
> to append the .jar to the boot class path
>    - Detach the agent
>    - Deploy a framework extension bundle that exports the packages at
> the .jar (without any implementation)
>
> This is Sun/Oracle JVM specific way to do this, but it gets the job done.
>
>
> Now, I would like to build a bundle that, when a user tries to deploy
> a boot class path fragment bundle, it does all this. This is, deploy a
> bundle that would add this capability to Felix in a more ad-hoc way.
> Once again, this might not be ideal, but it gets the job done. The
> issue is that Felix just throws when it sees a boot class path
> fragment bundle and refuses to do anything with it, so there is no way
> for an external bundle to deploy the fragment using the mechanism
> described above.

Are you really trying to create a general mechanism here (i.e., a poor 
man's implementation of the spec feature)? If not, why not just have 
your bundle add the content that it needs directly and be done with it?

If yes, then perhaps you could install your boot class path bundles 
using a URL handler with a different protocol so you can massage away 
the boot class path extension fragment and just convert into into a 
framework extension fragment, where you take care of the other issues on 
the side.

The difficulty of just allowing this to pass into the installed state in 
the "normal" case as you suggest is that it gives the impression that 
the Felix framework does something with this extension, when it doesn't. 
Further, and perhaps worse, in your case the dependencies wouldn't be 
tracked at all, so if the extension bundle was uninstalled the framework 
wouldn't know that anyone depended on it.

-> richard

>
>
> Regards,
>    Lucas