Better tooling for handling OSGI Bundles
Description
Attachments
- 29 Oct 2018, 03:37 am
relates to
Activity
Zac Spitzer 6 February 2022 at 16:41
here is a CFC solution https://github.com/cfsimplicity/luceeOsgiLoader
as recently discussed https://dev.lucee.org/t/createobject-issue-with-bundles/9625
Bruce Kirkpatrick 29 October 2018 at 19:18
Brad,
I'm willing to refactor it over then soon, sure.
If you want to see the extension source, I can share it. This structure in conjunction with the fld xml is how all of the java based Lucee cfml functions/tags work. I isolated the relevant bits for the install function below:
package com.jetendo.extension.reloadLuceeExtension.functions;
import com.jetendo.extension.jetendoShared.FunctionSupport;
import lucee.commons.io.res.Resource;
import lucee.loader.engine.CFMLEngine;
import lucee.loader.engine.CFMLEngineFactory;
import lucee.runtime.PageContext;
import lucee.runtime.exp.PageException;
import lucee.runtime.osgi.OSGiUtil;
import org.osgi.framework.Bundle;
import org.osgi.framework.BundleException;
import java.io.IOException;
public class OSGIBundleInstall extends FunctionSupport {
public static Bundle call(PageContext pc, String name) throws PageException {
OSGiUtil osgi=new OSGiUtil();
CFMLEngine engine = CFMLEngineFactory.getInstance();
Resource resource=engine.getResourceUtil().toResourceExisting(pc, name );
try {
Bundle bundle = OSGiUtil.installBundle(engine.getBundleContext(), resource,true);
return bundle;
} catch (IOException e) {
throw new RuntimeException("Failed to load OSGI Bundle: "+name, e);
} catch (BundleException e) {
throw new RuntimeException("Failed to load OSGI Bundle: "+name, e);
}
}
@Override
public Object invoke(PageContext pc, Object[] args) throws PageException {
if(args.length==1) return call(pc, (String)args[0]);
throw exp.createFunctionException(pc, "OSGIBundleInstall", 1, 1, args.length);
}
}snippet from fld:
<function>
<name>OSGIBundleInstall</name>
<class bundle-name="{bundle-name}" bundle-version="{bundle-version}">com.jetendo.extension.reloadLuceeExtension.functions.OSGIBundleInstall</class>
<keywords>OSGIBundleInstall</keywords>
<description>Reloads the OSGi extension.</description>
<argument>
<name>bundleFilePath</name>
<type>string</type>
<required>yes</required>
<description>The absolute path for the OSGi Bundle you want to reload.</description>
</argument>
<return>
<type>org.osgi.framework.Bundle</type>
</return>
</function>
That along with the right packaging and dependencies, and you end up with built in native cfml:
OSGIBundleInstall("/path/to/CFLint.jar");
The references to jetendo are for organizing my extension work. The final version would be lucee namespaces.
Brad Wood 29 October 2018 at 18:58
@Bruce Kirkpatrick Also, I just realized I meant to link to this post as well:
http://wwvv.codersrevolution.com/blog/using-osgi-to-load-a-conflicting-jar-into-lucee-server
That post shows what I was doing when I came up with the sample code to load an OSGI bundle (with Micha's help via Slack) and the SQLite post was just a more real-life example of loading a random jar from the CLI, even though the SQLite Jar wasn't an OSGI bundle, the use case would have been the same, just a slightly different way of calling it.
Brad Wood 29 October 2018 at 18:54Edited
It sounds like you want them to answer that they agree with the feature and will support it.
@Bruce Kirkpatrick Actually, I had a lengthy conversations with Micha in the Lucee slack prior to entering this ticket and he agreed it would be a good solution. This was really more a reminder for him to actually do it 
I could move my code to the core, and submit a pull request
If you're reasonably sure Micha would merge your code I wouldn't have an issue with that. I'm not really sure about whatever Extension stuff you were adding in, but I'd love to see the core functions I outlined in this ticket:
OSGIBundleList()
OSGIBundleInstall()
OSGIBundleUninstall()
Thanks for your time discussing this and providing feedback. Adding the Java security checks is a great idea I think to prevent these features from being highjacked.
Bruce Kirkpatrick 29 October 2018 at 04:56
Brad,
It sounds like you want them to answer that they agree with the feature and will support it. I can't answer that of course, but I could move my code to the core, and submit a pull request. It would function the same, and it is using the same Java structure they are using for everything.
I'd probably add integration with the same options that allow disabling direct access to java when moving this to the core.
Was there anything else missing?
I heard you on everything else.
Details
Assignee
UnassignedUnassignedReporter
Brad WoodBrad WoodNew Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Priority
New
Details
Details
Assignee
Reporter
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Priority
New
We are trying to push people to use OSGI in Lucee 5 over classic jars, but there are some basic functions missing to make this easy. These functions need to be accessible from CFML code at runtime with no access to a web administrator or server install home.
List installed OSGI Bundles.
This is possible with the following undocumented code, but I would propose a BIF like OSGIBundleList() to do it
admin type="server" password="yourServerContextPassword" action="getBundles" returnvariable="bundles";Install a bundle from a jar file path
This is possible with the following code and I would recommend we wrap it up as a BIF called something like OSGIBundleInstall( 'path/to/bundle.jar' )
CFMLEngine = createObject( "java", "lucee.loader.engine.CFMLEngineFactory" ).getInstance(); OSGiUtil = createObject( "java", "lucee.runtime.osgi.OSGiUtil" ); resource = CFMLEngine.getResourceUtil().toResourceExisting( getPageContext(), expandpath( 'CFLint.jar' ) ); bundle = OSGiUtil.installBundle( CFMLEngine.getBundleContext(), resource, true);Uninstall an OSGI Bundle
Not sure of the demand for this one, but it seems like it should exist, but there should be a way to uninstall/unload an OSGI bundle at runtime if a module or library is being removed from an app and the bundle is no longer needed. I recommend a BIF such as OSGIBundleUninstall()