|Re: Integration of 3d party libraries [message #1717373 is a reply to message #1717098]
||Sat, 12 December 2015 11:12
| Nedelcho Delchev
Registered: May 2013
You brought up very interesting topic!
Indeed there are several use cases in Dirigible context to bring your own 3-thd party library and expose it to application developer afterwards. Following your definition:
Case 1: [Component] First you have to decide whether this feature should go to the standard core Dirigible product or will be custom built product for your own usage. Hence,
Case 1.1: [Standard feature] You have to follow the Eclipse IP process i.e. to create a CQ in the IPZilla https://wiki.eclipse.org/IPzilla . The easiest way is to find your library in the Orbit repository (current version used in Dirigible is here) and to go thru Piggyback shortcut.
Case 1.2: [Custom Built] You need to find OSGi bundle of your library or to make such by your own using standard Eclipse capabilities for Plugin Developers. You can find a tutorial about this as usual at Vogella site.
Once you are ready with your OSGi-fied library you can add it to the target descriptor org.eclipse.dirigible.platform.base.target, then to the p2.external feature and to the corresponding config.ini files. More or less this are the steps you have to follow.
Case 2: [Application dependency] Here again there are different cases:
Case 2.1: [Java Standard Classes] This is the case with the Datasource and the whole JDBC APIs. These classes are loaded once in the context of the App Server and then can be used thru all the layers Servlets, OSGi, Rhino, hence you can use them in the source code of your Dirigible's project. So, once they are injected in the JNDI or in the Session via the injectors of the DirigibleBridge you can use them without any issue.
Case 2.2: [Java Optional Classes] Ugly situation - for example javax.mail. On one side this library can be provided by the App Server (the usual case), but unfortunately it is not available for the OSGi (or at least I didn't manage to make it working). If you put this library in the OSGi environment, once you try to use it you will get ClassCastException, because the Class Loaders are different. In this case as of now, I just push down the implementation of the service (the one that uses this library) to p2.library and make another wrapper in the OSGi, side which just make calls via reflection. It is quite nasty, but still the only way I manage to see working.
Case 2.3: [In App Library] This is the case when you need to put a jar file in your Dirigible's project (within the ScriptingServices folder) and to use it afterwards from your Java Services. There is already and issue in Bugzilla for that. Technically, it should not be big deal to be implemented as far as for the Java services we use in-memory compilation and dynamic loading of dependencies anyway, but one have to explore a bit more this topic for the other non-functional aspects e.g. security, lifecycle management, "for-production" deployment options, etc.
Powered by FUDForum
. Page generated in 0.01777 seconds