Hi there, can I import and use 3rd party Java jar libraries in Ignition?
Yes, mostly. Via the Module SDK. However, packaged modules are signed, blocking the ability of end-users to do any substitution. This makes it all but impossible to legally put GPL or LGPL or similarly-licensed code in a module.
For use only on the gateway, you could try modifying ignition.conf to include the relevant jars.
For gateway-only access you can also just drop jar files into the lib/core/gateway folder (and then restart).
Just don’t expect these to be part of any backups, available outside gateway scope, or available on another Ignition gateway unless you put them there also. Basically, you need to remember that you added those jars, else your project may someday stop working because you’ve found yourself running on an installation that does not have them.
I don't think so. Users can simply open up a signed module and remove the code signing files such as certificates.p7b and signatures.properties. This effectively converts a signed module into an unsigned module. Users can then replace LGPL jar files. Then users can add the wrapper.java.additional.7=-Dignition.allowunsignedmodules=true flag to the ignition.conf file so that Ignition can still install the module.
Or users can replace the LGPL jars and then resign the module with their own certificate.
It seems to me that these methods make using LGPL libraries in Ignition modules possible.
1 Like
Hmmm. That would be a serious gap in Ignition's license enforcement system -- the signature domain wouldn't match the module ID. Anyone in IA care to comment on that?
Yeah, if any module can be signed by anyone else, a user could replace an LGPL jar. Totally depends on a broken signature verification system, though.
This isn't something we track or enforce, as good as it might sound. It puts us back in the business of policing modules and would require either a mapping built into the software and constantly updated or a connection to a web service to verify the module ID is allowed to be signed by the certificate.
As a 3rd party module author, signing currently only provides users proof that a module came from that author and the ability to treat that author as an approved source of modules.
Makes sense. My cert doesn't have a domain name within, just my company details. I'd like my module to be able to enforce that it is only signed by me, though. Could the certificate subject string or the certificate object itself be made available in the API as part of the license object?
I think that’s an idea worth looking into. Either the thumbprint of the certificate, or the certificate itself, that signed a module could be made available somehow.
In setup() of your module hook you would then check that both the module ID you got loaded as is the one you expect and that the certificate that signed you is the one you expect. If not, throw a nasty exception and don’t start.
2 Likes
Hi Kevin,
I hope this isn’t reviving too much of a dead thread. I’m trying to use a vendor SDK in my system that I modified slightly. I put it in both the lib\core\gateway and lib\core\common folders, both times when I try to execute the code (via a button), I get ‘Import Error: No module named ____’.
The folder structure is lib\core\gateway\OctaneSDK.jar
In OctaneSDK.jar, the folder structure is com\impinj\octane*.class and all of the classes I need reside in octane.
The code on my button is:
from com.impinj.octane import ReadTagsPeriodicTrigger
reader1 = ReadTagsPeriodicTrigger('hostname=10.18.71.100')
Any recommendations? Thank you in advance!
I would also like to know if this issue was resolved.
What part? You can integrate just about any pure java jar via the module SDK. Without the SDK, options vary greatly, and vary by Ignition version.
1 Like