External Configuration File for *.aar service archive Is Ignored


I am following the user guide to set an external configuration file for the service .aar file we have. This is because we have multiple environments and we only want to use one .aar file and have one configuration file for each environment that will override the broker node and service name detail set inside .aar file.

I have added the below parameter in axis2.xml in the parameter section:

This is the content to my entirex-config.xml (I’ve changed the service name and broker detail just for this post):

<?xml version="1.0" encoding="utf-8" ?> BROKER:5552 RPC/SERV1/CALLNAT BROKER:5552 RPC/SERV1/CALLNAT true

But it seems it is still using the broker and service name inside the .aar file.
Have I missed something? Do I need to change anything in the web.xml that comes from the wsstack code?
Any help you can provide is much appreciated.


Hi Irene,

I can’t see anything which looks wrong. Did you restart Tomcat after you changed the axis2.xml file?

You should run a supported version and have the latest fixes applied.

Thanks Rolfe.

I did restart Tomcat, a few times.
We are currently running wsstack obtained from version

Is there anything I need to change in the web.xml (original version from the package)?

I am at a lost as to why this is not working.

I can only guess: is the location in the parameter section correct?

Brian also had some problems with this, but he got it working. Maybe he can comment on this.

If this doesn’t help I suggest contacting support.

I think so… I placed the entirex required parameter on this location within …/WEB-INF/conf/axis2.xml

true true false false
<!-- External Configuration File for Web Services overriding the config in web service archive file -->
<parameter name="EntireX-XML-Listener">
    <parameter name="services" location="/v/global/user/proj/entirex_wsstack/config/DEV-ws-entirex-config.xml" />
<parameter name="exx-trace-propertiesfile">/v/global/user/proj/entirex_wsstack/config/entirex.trace.properties</param


I did check the other post you mentioned. But alas I’m still none the wiser as to why this is not working for me.

Check the Web Service Stack (or Axis2) documentation about the location of the axis2.xml file.
If you use the Common Tomcat the docu says:

This file is located in the Software AG_directory/profiles/CTP/workspace/wsstack/repository/conf directory

I deployed it as an exploded war file.
I cannot find directory structure that resembles
/profiles/CTP/workspace/wsstack/repository/conf directory

What application server are you using? The Common Tomcat which gets installed by the Software AG installer, a stand-alone Tomcat, or something else?

Anyway, somewhere you should have a WS-Stack\repository\conf directory.

I am using a corporate hosted server with virtual servers utilisation allocation (built on top of Apache Tomcat server).
The way I deploy it is by pointing it to the exploded war file location of ws-stack.

So the axis2.xml I’ve changed is in /WEB-INF/conf/axis2.xml

You’re right, if you have a standalone Tomcat /WEB-INF/conf/axis2.xml is the correct place of the axis2.xml file.
I see that you have specified the exx-trace-propertiesfile parameter. If that works then the location of the axis2 file is okay.

You can try to use a file url for the services parameter:

What version of the entirex.jar are you using in the Tomcat?
Just run java -jar entirex.jar.

It looks like I’m using entirex.jar version
Let me try to use the same version of entirex.jar as the ws-stack version and restart Tomcat.

The latest fix on Empower is You should use this one.

Thanks Rolf. I’ll give it a go.
Do you happen to have the download url for that entirex.jar from empower website?

Try this one: https://empower.softwareag.com/sl24sec/SecuredServices/KCFullTextASP/viewing/view.asp?key=519473-17011618&DST=UPDATE

Updating the entirex.jar to the latest version worked!!!

Thanks a million for your help Rolf! You’re ace!!

Hi Irene,

Sorry I didn’t check the forums to see your post when you needed help, but I am glad you were able to resolve the issue. My issue had to do with poorly coded XML tags, but once that was fixed it worked like a charm. We were already using a version of WSStack that had the fix to your issue.

I had other issues when I first started that were resolved by applying the latest fix. I think as a general rule this is a good thing to do with this product - consistently apply the latest fixes for WSStack and Designer.