Generating Liquibase change set from the differences of two Two database Instances

One of the easiest way to generate the Liquibase Changeset is to keep the two sets of database instances and update one instance with the required changes and generate the changeset using the following command

liqubase.bat --driver=oracle.jdbc.OracleDriver \
        --url=jdbc:oracle:thin:@testdb:1521:test \
        --username=bob \
        --password=bob \
    diffChangeLog \
        --referenceUrl=jdbc:oracle:thin:@localhost/XE \
        --referenceUsername=bob \
        --referencePassword=bob

Writing such a long command could be error prone and if you create a batch file(or shell script) that could be used only for diffChangeLog, if you want to see just the diff then you have to write one more batch file, in the same way for every liquibase command (parameterised batch also could not work well for all possible command options).

Alternatively you can just create liquibase.properties file in the liquibase root folder as in the below example

changeLogFile = changeset.xml

url = jdbc:postgresql://localhost:5432/instance1

username = username1

password = password1

referenceUrl = jdbc:postgresql://localhost:5432/instance2

referenceUsername = username2

referencePassword = password2

driver = org.postgresql.Driver

Once created this file, you can simply execute the commands like

liquibase diff

liquibase diffChangeLog

etc

with out passing any parameter. Liquibase will use the liquibase.properties file for the parameters. 

Read More

Mock Service Integration Testing with SoapUI and Maven

Now the days mock testing is very common in all developments, usually we mock the object behaviors and use them in Unit tests.

 When it comes to web services testing, just mocking the object is not good enough to test. We actually have to mock the behavior at SOAP message level. It is good practice to test against mock services before actually doing the integration test against the actual service. 

Using SoapUI, one approach to do this is, 

1. Create a Mock service Project in SoapUI project using the WSDL

2. Define mock request and responses.

3. start the mock service in SoapUI

4.  run your tests against that.

you can read http://www.soapui.org/Service-Mocking/mocking-soap-services.html for step by step example to create and start mock services. 

This may be helpful during the development in developer machine, but when we want to include this tests as part of automated tests and to execute in continues integration tests. The better approach could be to include the starting and stopping of the mock services without installing the SoapUI. This can be achieved using SoapUI maven plugin. 

1. Create a mock service project in SoapUI project using WSDL (refer   http://www.soapui.org/Service-Mocking/mocking-soap-services.html)
2. Define Mock requests and responses.
3. copy the SoapUI mock services project into your classpath.
4. Include the following in you pom file

  <plugin>

          <groupId>eviware</groupId>

          <artifactId>maven-soapui-plugin</artifactId>

          <configuration>

            <projectFile>${basedir}/target/myservice-soapui-mock-project.xml</projectFile>

            <noBlock>true</noBlock>

          </configuration>

          <executions>

            <execution>

              <id>soapui-test</id>

              <phase>test</phase>

              <goals>

                <goal>mock</goal>

              </goals>

            </execution>

          </executions>

        </plugin>

This will start the mock services at the start of the test phase and stop at the end of the test phase. Now you can execute the tests as part of the automated unit tests against this mock services to ensure more reliable code.

<noBlock>true</noBlock> is for automated tests, otherwise manual intervention is required to stop the mock service.

Read More

bug with JDK 1.6.0.29?

I came across an weird issue, We communicate with an existing web service from one of our new projects, when I try to execute the project from my system which talks to the web service in test server (GlassFish), The request was failing in server end with the following error.

"The markup in the document preceding the root element must be well-formed."

And the error was intermittent. The same project executes fine in my all other teammates systems. After doing all the normal initial trouble shooting (syncing with the latest in code base, clean up the maven repo, capturing outgoing message and try from SoapUI etc). The only difference between my system and others were jdk version, I was using 1.6.0.29, and other were using 1.6.0.27. After I reduced my JDK version to 1.6.0.27, it started to work fine. So Weird, I did not find any difference in the outgoing SOAP message too. I will update this post if I found any thing useful in this.

Read More

APIs at Project Level or Application Server Level?

As all of us know, any libraries, apis could be included at application server level or at project level (within war file).

Like any other libraries, Metro web services could be included at project level or application server level. Main difference here with other libraries is, usually installing at project level is the default choice, and server level installation is rare, but Metro suggests this in its documentation and it comes with GlassFish as pre-installed package. Metro also provides an installer to install Metro to Tomcat, so here including at server level becomes default choice.

We can always avoid Metro at application server level, and include it at Project level.  Here it triggers some thoughts on best approach, not just for Metro but for any Libraries, in my view,

Including at project level is better, because

• Libraries should be specific to projects, not common to all the projects deployed in the application server
• Upgrading all the projects in an Application server to new version of the library is not practical
• Keeping projects independent of application server specific libraries is always increases manageability and avoids release issues.
• Usually upgrading and installing the libraries at server level will be the task of Server admins, In my view handling libraries should be the task of developers not admins.
• Including at project level bundles the library with the project, so at the stage of delivery the project has been tested along with the library, so it reduces the delivery time bugs.
• It keeps the application server as unchanged from its installation and avoids configuration issues
• Clean application server, so no conflict with the libraries from the project.

In my recent experience, we faced a library conflict issue because of using metro at server level, now we changed to project level and looks our project and application server is independent of each other and works fine. Share your views too. Thanks.

Read More