I found that packages in my IS are not loading in an order as per webMethods default behavior (loading packages in alphabetical order) during IS restart.
I investigate this further and confirming that
no package dependency set on the package which is loading first
The same package is not loading first after wM packages are loaded. First package that loads is keep changing
the manifest file for that package (which is loading first) has no fault entries in it
no extended property set in the server to make class loading search on priority defined.
Could you please confirm if there a way to instruct IS (explicitly) to load packages in alphabetical order ? if yes, how.
Also, by setting the property “watt.server.classloader.pkgpriority” , can we instruct IS to load the packages in the order that is defined for this property? Hope, setting this property don’t impact wM packages’ loading and always wM packages load first.
I am not aware of such a feature beside defining package dependencies.
As each package is loaded in its own classloader (except it depends on other packages, then it will be loaded into the same classloader as the other ones), it is not important in which order these will be loaded.
Packages starting with Wm* will be loaded prior to custom packages as these are required for all other operations of IntegrationServer.
Therefore it is not neccessary to define dependencies to these packages with some very rare use cases (i.e. SAP Adapter).
We have couple of common/generic schema files and documents from the schema can be used across multiple packages. Now, Developers keep copy&pasting schema files and documents into their each local package and who miss to do this activity getting package/WSDL loading issues which causes transaction failures (even in PROD).
During restart we found that custom packages are not loading in alphabetical order too. Hence, package reloading immediate after restart required for few packages , which is very poor design.
We want to make a generic package which holds all common schema and documents, also this package should load first on every restart to avoid any dependency issues.
1/ create a package called CommonDocuments and put all your IS documents, schemas etc., in this and set this package as a dependency on other packages. In Common and shared approach, make sure you deploy the patch always for future deployments and have proper governance.
2/ create a doc folder (which will contain the IS documents, schemas) in your interface specific package and do not set any dependency.
During IS Startup, it will load WmRoot, WmPublic and followed by other in-built packages like Default and then custom packages will start loading.
There is no alphabetical order followed.
Package loading sequence dependent on the IS global class loader which is the parent of all of the IS Package class loaders.
None of the package class loaders has another package class loader as a parent. The IS Package manager instantiates a class loader for each package, when it loads or reloads it.
IS Packages get loaded according to their dependencies, as these are defined in their manifest files. When some IS package code tries to instantiate a class, first the JVM determines whether the package’s class loader has already been recorded as the initiating loader of the class.
If it is, we don’t need to load the class. Otherwise the JVM invokes the “loadClass” method of this class loader. The class loader will first try to locate the class locally, using the locations mentioned above.
If it cannot locate the class, it will search up the dependency chain and try to figure out the dependencies on other packages.
All this happens on IS startup time. There is no way to load the Custom build packages in Alphabetical order.
If we set dependency on one common package, during a new package deployment into production, that will make the common package reload as we set dependency on the common package. While common package is being loaded, live transactions in other packages may be affected as those package using documents from the same common package.
Yes, this we are doing now.
@ Shahbaz Khan, Thanks for clarifying this.
I have a query here. No issue in copying the documents to local package, but with schema files??
If the case is to use same xsd file to create a schema & documents across multiple packages,
– Is it so that, once schema created first time in a server package, the same schema file(s) will not be created in other packages if we try create using same XSD? If same schema is being used/copied in other packages, all those packages are being listed in reference search for every related doc in each package
@ Holger, As per Shahbaz Khan, no option make package loading in the order. Our requirement is to have generic package which hold all needed docs and schema files which are used by many other packages to avoid having same docs in all available packages. But, how to avoid marking dependency on the common package (as mentioned in point 1 in this post).
a XSD can be used only once to create a schema node as this will be bound to the namespace in the xsd.
When generating from the XSD multiple times at different locations only the documents will be created but will point to the schema node created during the first creation.
When copying documents to other packages, how do you make sure these will get updated when the source schema/document is updated for some reason?
Best pratice might be to define a time slot where these deployments can take place, i.e. with low traffic.
When some transactions break during this time there should be a way to either resubmit them or get them sent once more from origin.
I don’t think that is accurate. The common package will not be reloaded when a dependent package is loaded. It is the reverse. If the common package gets reloaded, then all packages dependent on that common package will be reloaded – which is what you want.
For example:
CommonA
MyB - dependent of CommonA
MyC - dependent of CommonA
MyB and MyC can be reloaded at will, nothing happens to CommonA. If MyD is added later, CommonA remains as is and is not reloaded. If CommonA is reloaded (or updated via Deployer or whatever) then MyB, MyC and MyD will be reloaded.