Skip to main content
R
rbeck1-Visitor
1-Visitor
October 21, 2020
Solved

Thingworx Java extension dependencies

  • October 21, 2020
  • 1 reply
  • 2286 views

Hello,

 

I look for the good practice of dependencies management across multiple Java extensions.

I work on a project where we have developed multiple Java extensions and where we use standard extensions. We always facing troubles with JAR dependencies across extensions and we finish to comment jar resource dependency within the metadata.xml in order to import extension.

Moreover in some cases we need to know the order of import of extensions.

 

For example:

- We have imported the extension DataExporter which contains the jar poi-4.0.0.jar

- We need to import a custom extension which depends on poi-4.1.2.jar

 

And from here we can't import our custom extension.

Checking ThingWorx system JARS conflict(s) detected [package: XXXXXX].

A workaround for this situation, as mentioned earlier, is to comment the poi-4.1.2.jar in the metadata.xml and rely on the existing  jar poi-4.0.0.jar already imported in the platform.

 

Do you guys have a cleaner workflow?

Do you know if in future versions of Thingworx the class loader will be sandboxed by extension?

 

Thank you

 

Best regards

Best answer by VladimirRosu_116627

I have not invested in finding a solution, but I experienced the same issue as you.

I'm usually establishing the baseline - the lowest version of all the JARs I have in the system (that come with ThingWorx). I'm then working from that list, and using either new ones and adding them to the list (so that I always keep the list updated), or using the existing version if that matches my needs.

That raises the question: what is happening if you absolutely must use a newer version of a specific JAR than one that you can not remove, due to the fact that it is used internally by ThingWorx for example.

In practice I haven't yet met this situation, but in such case I would offload the extension in a separate JAVA Edge SDK implementation as a remote service (it should be a simple copy/past type of code from the extension to the edge sdk code), running in the same machine. In that way it's sandboxed, doesn't impact the ThingWorx JVM , and depending on what you do, it's also a bit more scalable.

Disadvantage is that it is a bit more harder to maintain that Edge, and in some cases you can't even access the OS of the machine hosting ThingWorx, so you need a separate VM.

The good thing is that this situation does not happen that often 🙂

1 reply

V
VladimirRosu_11662719-TanzaniteAnswer
19-Tanzanite
October 22, 2020

I have not invested in finding a solution, but I experienced the same issue as you.

I'm usually establishing the baseline - the lowest version of all the JARs I have in the system (that come with ThingWorx). I'm then working from that list, and using either new ones and adding them to the list (so that I always keep the list updated), or using the existing version if that matches my needs.

That raises the question: what is happening if you absolutely must use a newer version of a specific JAR than one that you can not remove, due to the fact that it is used internally by ThingWorx for example.

In practice I haven't yet met this situation, but in such case I would offload the extension in a separate JAVA Edge SDK implementation as a remote service (it should be a simple copy/past type of code from the extension to the edge sdk code), running in the same machine. In that way it's sandboxed, doesn't impact the ThingWorx JVM , and depending on what you do, it's also a bit more scalable.

Disadvantage is that it is a bit more harder to maintain that Edge, and in some cases you can't even access the OS of the machine hosting ThingWorx, so you need a separate VM.

The good thing is that this situation does not happen that often 🙂

R
rbeck1-VisitorAuthor
1-Visitor
October 26, 2020

Hello,

 

Thank you for your answer.

I'm not familiar with JAVA Edge SDK but thank you for mentioning it. I keep it in mind.

 

I agree with your idea of the baseline for our own libraries. However, most of the time we depend on third parties extensions or third party library which have a transitive dependency which conflicts with THX or other extensions.

 

For example a lot of libraries rely on apache common-lang but a third-party extension may rely on v3.0, my extension on v3.11 and a library I rely on may add a transitive dependency of v3.3.

S
slangleyCommunity Manager
Community Manager
November 4, 2020

Hi @rbeck.

 

If you feel your question has been answered, please mark the appropriate response as the Accepted Solution for the benefit of others with the same question.

 

Regards.

 

--Sharon

Terms & ConditionsCookie settingsAccessibility statement