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 > > >
