This is part 2 of the article describing how to provision an OFMW domain with System Artifacts, click here for part 1.
Not all OFMW domains we encounter are as default as others. And when you need to provision a non-vanilla domain with Rubicon Red MyST Studio, these customer-specific customizations can sometimes be hard to fit into your Platform Blueprint or Platform Model.
This post is part of a Series in which Robert Jan de Groot and I explore the inner and hidden parts of Rubicon Red MyST Studio which might come in handy at times.
As a reminder: the case in hand: we need to provision our domain with the addition of a jar-file in the domain/bin folder.
This jar file houses some classes required for start up. This jar is developed in house by the client, and (luckily) is available in the internal Binary Repository Manager (Sonatype Nexus).
Now that we have made MyST be able to use Maven on nodes where it has not been installed as a prerequisite, it’s time to get to the actual reason we headed in this direction. Place a library on a specific location during provisioning.
We have to gather some information beforehand, specifically we need to know WHAT to place WHERE, and WHEN to place it. Only after knowing these three things can we get everything working.
Locate your artifact
Our artifact can be found in Nexus with these Maven coordinates:
GroupId: nl.customer.application.library
ArtifactId: common-lib
Version: 1.0.0
Where does it need to be placed
Here, this library needs to go into the lib folder in the domain home in order for it to be available during startup of our domain.
MyST has a little trick up it’s sleeve here, the location you provide is auto-computed to be relative to your Domain Home. This behavior can be altered by setting a flag on the System Artifact. (Please see below)
Determine phase
Now that we know WHAT and WHERE, only the WHEN is left to do.
MyST uses a system of phases and actions to provision OFMW environments, and all you need to do now is choose an appropriate phase to execute the placing of your System Artifact.
This can be registered on a per Artifact basis, so each and every artifact can have its own phase.
Here, we’ll choose to place the artifact on the filesystem right after the creation of the domain, but before it is being started. This way, the placement of the jar only happens during provisioning, and not when the environment is restarted.
The phase we choose is copy-domain. As we want the System artifact to be rolled out after it completed, the phase will be copy-domain-post.
Create System Artifact in MyST
With all the information gathered, we can now create our System Artifact in MyST Studio. As System Artifacts are generic for all environments, it is best to create these in your Platform Blueprint.
Navigate to your Platform Blueprint, and click Edit.
Scroll down to ‘System Artifacts’ in the left column, and click the ‘+’.
Type in the desired name, and click OK.
You’ll need to punch in these details:
Name: common-lib
Type: Jar Library
GroupId: nl.customer.application.library
ArtifactId: common-lib
Version: 1.0.0
phase: copy-domain-post
target-directory: /lib/
Please note that the bottom two (phase and target-directory) need to be added manually to ‘Other Metadata’.
If you require your System Artifact to be placed somewhere not relative to your domain home, e.g. on a fixed location on the filesystem, you can add the following flag to your System Artifact to enable this behavior:
target-is-domain-directory=false
By default, this flag is true, so by setting it to false it enables you to place your System Artifact somewhere else. Please note you’ll have to give the full path on the machine in target-directory.
Roll out the System Artifact
When you provision your environment with a System Artificat in it, you’ll be able to see something along the lines of the below snippet in your MyST Studio logs:
... Domain created at /u01/app/weblogic/configuration/aserver/my_domain >> Started executing deployment of artifact commonlib /u01/app/weblogic/installation/oracle_common/modules/internal/features/jrf_wlsFmw_oracle.jrf.wlst.jar added to the classpath /u01/app/weblogic/installation/wlserver/modules/features/wlst.wls.classpath.jar added to the classpath ============================================================= ============================================================= ============================================================= About to Deploy 1 Artifact common-lib library 1.0.0 ============================================================= /u01/stage/myst-workspace/2193015b-3b8f-4453-8188-1ba433a91bdf/target/artifacts created successfully Archive: /u01/stage/myst-workspace/2193015b-3b8f-4453-8188-1ba433a91bdf/target/artifacts/nl.customer.application.library/common-lib.jar Generating dependencies template. To provide a custom template specify the file location relative to the MYST_WORKSPACE with the property core.product[maven].param[dependencies-template] No local repository home specified by core.product[maven].param[repo-local-home]. Maven default will be used. /u01/app/weblogic/installation/oracle_common/modules/internal/features/jrf_wlsFmw_oracle.jrf.wlst.jar added to the classpath /u01/app/weblogic/installation/wlserver/modules/features/wlst.wls.classpath.jar added to the classpath Deploying library : commonlib library_location=/u01/stage/myst-workspace/2193015b-3b8f-4453-8188-1ba433a91bdf/target/artifacts/nl.customer.application.library/common-lib.jar Looking for past versions machines: rxr.infra.Compute-1_as,rxr.infra.Compute-2,rxr.infra.Compute-1 Copying locally common-lib.jar to: /u01/app/weblogic/configuration/domains/my_domain/lib/ on machine: host01.application.customer.nl Task "import" started. Task "import" started. ... >> Finished executing deployment of artifact commonlib
This indicates that MyST has found your artifact, downloaded it and placed it in the right location on all your hosts in your FMW domain.
More options
The avid reader might have noticed that the artifact is called common-lib.jar, where one might have anticipated the file to be called commin-lib-1.0.0.jar. That is how this file is named in your Binary Repository Manager according to the Maven standard naming convention.
There is a nice little trick up MySTs sleeve, and that is the ability to strip the version number from the name of the file as it is being put on the filesystem somewhere.
This is tucked away behind the ‘Show advanced properties’ toggle, so this’ll have to be flipped before the right field is shown.
After this the field ‘Strip Version’ is shown, where you can select the value ‘Yes’ from the dropdown. This will make MyST delete the version number from the name of the file. Profit!
We’ll discuss other types of System Artifacts in other blogposts if you are interested. Please let us know!
You can reach me via @maartentijhof or by leaving a comment below.
