Air Jordan 11 Gym RedCheap Air Jordans SaleCheap Air Jordans For SaleCalcioxp.comCheap Jordans Sale

Air Jordan 11 Gym RedCheap Air Jordans SaleCheap Air Jordans For SaleCalcioxp.comCheap Jordans Sale
Uncategorized - Notes and Thoughts

Archived posts in ' "Uncategorized"

Back home

纽约佳士德寻宝

05/15/2017

No Comments

Flushing Spring

05/8/2017

No Comments

Who win the war

02/21/2017

Armies, no matter how great or small, poised between defeat and victory, depend more than anything else on the leadership of junior officers.

— The Coldest Winter

No Comments

Avoiding conflicts with WebSphere’s JAX-WS runtime

02/20/2017

Avoiding conflicts with WebSphere’s JAX-WS runtime

The JAX-WS runtime in WebSphere Application Server is based on a modified version of Axis2 and these classes are visible to application class loaders. This means that when deploying a standard version of Axis2 on WAS 7.0 (and WAS 6.1 with the Web Services feature pack installed), special configuration is required to avoid conflicts with the Axis2 classes used internally by WebSphere. In particular it is necessary to change the class loader policy of the Web module to parent last. However, this is not sufficient because Axis2 creates additional class loaders for modules and services, and these use parent first class loading by default. Therefore, two things must be done to make a standard Axis2 distribution work with WebSphere:

  1. Before deploying the Axis2 WAR, edit the axis2.xml file and set the EnableChildFirstClassLoading parameter to true. Please note that this parameter is only supported in Axis2 1.5.5 or higher. The parameter is already present in the default axis2.xml file included in the WAR distribution, but its value is set to false. Therefore it is enough to change the parameter value.
  2. After deployment, modify the application configuration to enable parent last class loading for the Web module: in the WebSphere admin console, go the the configuration page for the enterprise application, click on Manage Modules and locate the WAR containing Axis2 (in the default WAR distribution, the module is called Apache-Axis2), then change the Class loader order option to Classes loaded with local class loader first (parent last). Note that the class loader policy for the enterprise application itself (which can be specified under Class loading and update detection) is irrelevant, unless a custom EAR distribution is used that includes the Axis2 libraries in the EAR instead of the WAR.

Deploying services and modules

By default (i.e. if the Distribute application option has not been disabled explicitly) WebSphere will deploy the application in exploded form. The standard location for these files is in the installedApps subdirectory in the WebSphere profile directory. This means that AAR and MAR files can simply be deployed by dropping them into the corresponding folders. In this scenario, hot deployment is supported and there is no need to update the services.list and modules.listfiles.

However, the directory is still under control of WebSphere and manually deployed AAR and MAR files will be removed e.g. when the application is upgraded. It may therefore be a good idea to configure Axis2 to use a repository location outside of the installedApps directory.

Deploying older Axis2 versions

The instructions given above apply to Axis2 1.5.5 or higher. Older versions don’t support the EnableChildFirstClassLoading parameter, and we don’t provide any support for deploying these versions on WAS 6.1 (with the Web Services feature pack installed) or 7.0. However, IBM has published a technote with an alternative approach that may work for older Axis2 versions.

No Comments

Luck vs Odds

02/17/2017

“They actually believe in luck,” he said. “That is stupid. You want to believe in odds.”

— Charles Munger on Chinese’s love of gambling.

 

No Comments