Forums de discussion

External Jar for Liferay DXP

thumbnail
Manish Jha, modifié il y a 6 années.

External Jar for Liferay DXP

Junior Member Publications: 50 Date d'inscription: 07/02/13 Publications récentes
I am creating Liferay DXP service and it has dependency on external jar. These jar have dependency on other jar as transitive dependency. This includes dependency on spring jars.

I followed option 4 on the following link to include dependent jar in the module.
https://web.liferay.com/web/user.26526/blog/-/blogs/osgi-module-dependencies

However, i do not want to include jar already provided by liferay OSGI container. I do not have idea how to get list of jars provided by OSGI container.

I would like to know is there any way to know jars provided by liferay OSGI container ?
thumbnail
Christoph Rabel, modifié il y a 6 années.

RE: External Jar for Liferay DXP

Liferay Legend Publications: 1554 Date d'inscription: 24/09/09 Publications récentes
You can list all services through the gogo shell with the lb command
https://dev.liferay.com/develop/reference/-/knowledge_base/7-0/using-the-felix-gogo-shell

telnet localhost 11311
lb

On windows telnet is usually not installed, it can somehow be added, but it's probably easier to download putty.
thumbnail
Manish Jha, modifié il y a 6 années.

RE: External Jar for Liferay DXP

Junior Member Publications: 50 Date d'inscription: 07/02/13 Publications récentes
OSGI service list does not list available jars for OSGI modules.
For example , I searched for Spring jar in the gogo shell, i could not jars listed. We know that spring jars are provided by Liferay OSGI container and we do not need to include the jar in the module's class path.
thumbnail
David H Nebinger, modifié il y a 6 années.

RE: External Jar for Liferay DXP (Réponse)

Liferay Legend Publications: 14919 Date d'inscription: 02/09/06 Publications récentes
Manish Jha:
I would like to know is there any way to know jars provided by liferay OSGI container ?


No.

Normally you find out what is missing and fill in the holes until you get no more undefined references. Any transitive dependencies that do not get flagged as undefined refs will represent packages that are available.

That's also a key to understanding, though, there's no concept of "available jars" or "provided jars" in OSGi, there's just "exposed packages". Any packages not exposed are going to represent dependencies that you have to satisfy.

Looking for jars can mess you up because I could add commons-codec into my bundle, but I could also export the packages thus exposing commons-codec without you finding a jar anywhere.









Come meet me at the 2017 LSNA!