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
