CODEWITHSUNDEEP
javamavensoapjaxbwsdl
Khuzi
Khuzi

Reputation: 2912

Different WSDL for different eviornment

I am consuming SOAP web services in my application. I am generating jaxb classes using maven by providing wsdl at build time. Now these wsdls are getting changed for each higher environement i.e. Dev, Integration, Stage and Prod.

That means I will have to build my project everytime I move up the environment. This would violate the deployment rule - The tested build should be moved up the environment till Prod.

How can I avoid rebuilding of the application everytime I move up the environment and also have jaxb classes as per wsdl of that environment.

Upvotes: 2

Views: 3188

Answers (2)

mhasan
mhasan

Reputation: 3709

Try using maven to FILTER PROPERTIES in wsdl files during the build process. For your example, you could replace the ${ws.url} placeholder in your WSDL with the corresponding value from your properties file by including the replacement text in your pom file.

Upvotes: 2

Gyanendra Dwivedi
Gyanendra Dwivedi

Reputation: 5557

I believe that it is not possible to change JAXB classes without a re-build. But, here I am wondering whether the structure of the WSDL (not taking about data values) is changing from environment to environment? If it is all together a different WSDL, obviously you need a fresh build.

In the above scenario, you may use Maven Profile feature.

If it is the same WSDL (only data values changes as per environment), then it is your code logic should be generic enough to work with different possible data values. If it is so, a single build should be working in all the environment.

EDIT - As per Op comments

Yes I am using maven profile for environment based build. And, the wsdl structure is going to be same across the environments so code break is not a problem. I was just wondering if there is way to this scenario.

As per the comments, I feel that it is not a build related area, but related to deployment of an artifact with below assumption:

  1. Once tested in test environment, the build would work perfectly in other environment.
  2. The build would be able to pick right internal config based on a parameter provided externally. e.g. If Java app build is having a env-dev.config and env-prod.config files, then based on a JVM flag -Denv=prod; it should pick right config file at runtime.

With this assumptions, you do not need a maven profile. Now coming to deployment, you may use some kind of webstore. e.g. a maven repository. The deployment script should pick the artifacts from the webstore and deploy it.

The process flow may be summarized as:

  • Use a CI (continuous integration) tool like Jenkin to make a test build.
  • In the CI tool, make a provision to upload the artifacts to webstore as part of post-build step. E.g. You may upload to your local maven repository server.
  • As part of deployment, the deployment script would get the artifacts from webstore and deploy on the test environment.
  • Deploy the artifact on test environment through above mechanism. Perform the testing.
  • If a bug is found during testing, fix the bug and re-build/deploy through CI tool.
  • Again use CI tool for stage/prod deployment. Please note that you need to simply skip build process. This would be a deployment-only process.
  • The deployment process should always pick latest (or a configurable version). So, version control is an important aspect.

Upvotes: 2

Related Questions