Question
Morgan Stanley
CA
Last activity: 25 Jul 2018 9:57 EDT
Pega - import dependent jar's
Hi,
I have a jar with 50 dependent jar's.
Example:
- MainJar:
DependentJar1
DependentJar2
DependentJar3
DependentJar50
I am able to import "MainJar" using Import Wizard inside pega but can anyone tell me how to import dependent jar's ?
Pegasystems Inc.
US
Hi Saurabh,
Pega import wizard allows us to import application raps(jar/zip) and third party jars if any into corresponding codesets.
The way of import is no different for main jar file or dependent jar files with current import wizard, you can just import both the main jar and dependent jars without any order. This is because any jar import(unlike application raps) performed on import wizard would need a server restart so that the corresponding classes get loaded during JVM startup.
Hence, you can proceed with importing dependent jars and restart the servers to apply them.
Hope this clarifies!
Morgan Stanley
CA
Hi Harish,
As you mentioned, I have to import 50 dependent jar's through current import wizard.
However , I have more than 50 dependent jar's. This will be hard to import jar's one by one.
Is there any other way ? Are there other places to specify these dependent jar's which can be used by main jar ? Any dependency management technique which can help here ?
thanks
Pegasystems Inc.
US
Hi Saurabh,
I don't think there is any way to just import main jar file into engineclasses and dependent jars file from some other place(outside pega db). It will be a hard import of the dependent jars into pr_engineclasses table. That's the place PRPC loads the class for you. I am afraid we have nothing much to offer on this use-case.
However to address the concern of importing jars one by one, you can consider using prpcUtils or prpcServiceUtils and make use of IMPORT operation and edit the properties file to includcomma-separateded jar file locations, so that all the jar files gets added to DB at one-go.
Thanks!
Swedbank AB
SE
Hello Saurabh,
To reduce the file upload time, you can physically paste the jar files in the \ServiceExport directory.
Let us know if you need any further help.
Thank you,
Pawan
Morgan Stanley
CA
Thanks Pawan,
There are some problems to this approach:
1) Main jar has more than 50 dependent jar's.
2) Also, if we import like this it will add imported dependent jar's (>50) in pega database (pr_engineclasses table)
3) Our versions of dependent jar's are upgrading every three months.This will require importing it again
4) If versions of dependent imported jar's (example: spring-context-4.2.6) conflicts with the already present jar's (spring-beans-4.1.0) in pega.
How can we solve above problem ? Is there any other approach ?
Pegasystems Inc.
IT
Hello Saurabh,
Regarding your points:
Hello Saurabh,
Regarding your points:
- You can repackage your jar with its dependencies into a single "uber jar" with all the dependencies. In this way you have a single fat jar to distribute each time.
You can use the maven shade plugin for such purposes.
- If you don't want to import the jar(s) as recommended (which is the easiest way to accomplish with this task) you can place the jar(s) into a reachable path and then add this path to the Pega Compiler Class-path (Default paths field) otherwise, where supported, you can leverage Application Server "Shared Library" features.
- Alternate solutions in previous point should already address this point.
Otherwise in case of jars imported into the Pega database you can leverage the Customer Codeset name and Codeset version to filter out previous versions.
The PRPC classloader logs at bootstrap the active codesets( internal.mgmt.PRNodeImpl) INFO - Using codeset version and timestamp map: {pega-enginecode=07-10-35@2018-05-08 16:16:00.0, customer=06-01-01@1970-01-01 00:00:00.0}
You can specify a custom codeset version using a DASS (e.g.: DATA-ADMIN-SYSTEM-SETTINGS PEGA-ENGINE!PROPERTIES/COM.PEGA.PEGARULES.BOOTSTRAP.CODESET.VERSION.<MY_CODESET>/DEFAULT '06-01-01')
In any case, considering the frequent changes expected, I would evaluate the previous options
- It is quite difficult to determine the impact considered the amount of classes to be loaded. Classloading conflicts must be resolved one by one.
In a similar scenario I would consider packaging these Jars into a separated application to be integrated in Pega via REST or SOAP connectors.
Morgan Stanley
CA
Thanks Domenico,
Thanks Domenico,
- You are suggesting 'fat jar'.
- I can use class path and load dependent jar's by tomcat class path -
I tried loading dependent jar's in Tomcat class path but due to number 4) I am stuck because Pega comes with spring version which is different then my dependent jar version. Also, it seems like jar's loaded through tomcat class path are loaded first (I think higher precedence) and doesn't see jar's present in database while loading. This simply skips classes which are dependent on database jar's
Example: Dependent jar : spring-jdbc-4.1.0 loaded by tomcat classpath has class : Class A extends B{}
Note: Where B should come from spring-beans-4.1.0 which comes with Pega installation and added to pega database (pr_engineclasses) . In this case A is skipped and not loaded by the loader because seems like it doesn't see B. - I need to specify custom codeset version while importing jar's to manage - What should I do for cleaning up unused jar's after importing every three months ? Do I need to delete from database with older codeset version ?
- Classloading conflicts must be resolved one by one -- Currently, our Pega version comes with spring-beans-4.1.0, but my jar requires spring-context-4.2.6. What should I do here ?