In IS 10.5, there is a service in WmRoot called wm.server.packages:getPackageResourceTree and it takes the input String ‘package’ and returns the output String ‘packageInfo’. Running it in Designer, the results tab shows the packageInfo is more than just a String. It contains a structure with a String, documents, nested documents, and arrays of documents, lots of good information. It would be awesome to get at parts of the packageInfo data. In my case, I’m interested in getting the path to the current package’s config directory, but I don’t understand how to translate the output String into something usable.
Are we expected to create our own document that has the structure found in the packageInfo String, and somehow convert the String into a document in order to use the data from that service?
there is no need to get the absolute path of the packages config diectory.
It is “packages/<packageName>/config”.
Just replace the packageName with your real package name.
@dsalisbury you may be aware that services in the WmRoot package are not intended for direct use by us. They are not “published” nor described in documentation.
That said, as you’ve seen by observation, the output of this service is not the string that the Input/Output tab declares. It is a document with a pile of elements that reflect the file system components that comprise the package.
You can create your own document type that defines the structure simply by copying the packageInfo structure from the results pane after you run the service to a new doc type. Keep in mind that the directories in the list are those that are present in the file system – it is not any sort of “these are what are supposed to be present” list. It’s basically an ls/dir listing. If you use this, support will not help you with any issue. And it could potentially break in future versions (though unlikely).
An alternative you can do as @Holger_von_Thomsen suggests, which I’ve done in the past at times.
Yet another alternative is to use a component that is defined for our use, com.wm.app.b2b.server.ServerAPI which has a method named getPackageConfigDir and is described in the wM IS javadoc. Here is a Java service that uses that, accepting an optional filename and returns a fully-qualified name to either the config dir (no input filename) or the file in the config dir (input filename provided):
public static final void getPackageConfigDir(IData pipeline) throws ServiceException {
IDataCursor idc = pipeline.getCursor();
String packageName = IDataUtil.getString(idc, "packageName");
String filename = IDataUtil.getString(idc, "filename");
java.io.File f = com.wm.app.b2b.server.ServerAPI.getPackageConfigDir(packageName);
if(filename != null && !("".equals(filename.trim())))
f = new java.io.File(f,filename);
IDataUtil.put(idc, "configDir", f.getPath());
idc.destroy();
}
Copy to your “public utility” package or where ever.
I would also strongly recommend against storing any environment-specific items in any package directory. Increases the risk of incorrect settings in a given environment. Environment-specific config settings should be outside of the package, IMO.
for this case we have defined our own sub directory (with structure of course) under the instance wide config directory “config”.
This has the advantage that this config dir will be backed up automatically every time IS starts successfully (“Config directory copied to backup” in the server.log file).
During the last migrations we have moved all of these configs from the packages config dirs to the new structure in the central config dir.
We do a similar approach but define a directory that is a peer to the standard config directory instead. We used to put custom config files in the central config directory but stopped doing that in part because the auto backup feature typically didn’t provide the “previous” setting as one might like. Restart IS a couple of times and the previous settings are gone. Of course, backups/version control other than this auto-backup are essential.
The main idea though is never have environment-specific things within a package. Manage those separately because it is too easy to miss updating a package during/after deployment, which could have significant negative impact.
Similar constraint for adapter connection pools – should never be defined in “deployable” packages. Instead, defined in a central package that is never deployed/copied from one environment to another.
