Enabling assertions in Eclipse

For the entire project

1. Go to menu Window > Preferences
2. In the dialogue that appears, select Installed JREs
3. Select your JRE, and click Edit. A new dialog opens.
4. Enter -ea under Default VM Arguments
5. Click Ok to save the change.

For a particular program execution

1. Open the Run Dialog (this should be an option under the “Run” menu).
2. Click on the tab, “(x)= Arguments.”
3. In the field for “VM arguments,” enter -ea to enable assertions.
4. Click on the “Apply” button.

Unit Testing Struts 1.2 with StrutsTestCase, EasyMock and Aspects

We have a legacy application and a lot of presentation code is written using Struts 1.2.4. For unit tetsing the action classes we used the following approach.

StrutsTestCase provides both a Mock Object approach and a Cactus approach  to actually run the Struts ActionServlet, allowing you to test your Struts code with or without a running servlet engine. When you want to execute your tests as a part of the continuous integration environment in which all the unit tests should execute without deploying the application to the container.

For the following entry of Struts-config.xml

<action path="/login" type="com.dnbi.simpleaction.LoginAction" name="loginForm" input="/login/login.jsp" scope="request">
			<forward name="success" path="/action/simpleAction" />
			<forward name="failure" path="/failurePath" />
		</action>

and for the following action,

public class LoginAction extends Action {

	public ActionForward execute(ActionMapping mapping, ActionForm form,
			HttpServletRequest request, HttpServletResponse response) {

		ActionErrors errors = new ActionErrors();

		String username = ((LoginForm) form).getUsername();
		String password = ((LoginForm) form).getPassword();

		if ((!username.equals("vikas")) || (!password.equals("pass")))
			errors.add("password", new ActionError("error.password.mismatch"));

		if (!errors.isEmpty()) {
			saveErrors(request, errors);
			return new ActionForward(mapping.getInput());
		}

		HttpSession session = request.getSession();
		session.setAttribute("authentication", username);
		return mapping.findForward("success");

	}

the test would look like this

Difference between Abstraction, Encapsulation and Information Hiding

So this one completes the hat-trick on blogs related to differences in succession.

Today during our discussion about defining service orchestrations we came up with the argument about the difference between Encapsulation and Information hiding. I cover abstraction here as a bonus

Abstraction – in a nutshell is making visible what you want the external world to see and keeping the other details behind the wraps. Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. It hides the complexity. It is a technique by which we decide what information to hide and what to expose.

Information hiding - is making inaccessible certain details which would not affect other parts of the system. Just hiding it so that it is not exposed.

Encapsulation - is like enclosing in a capsule. That is enclosing the related operations and data related to an object into that object.If encapsulation was “the same thing as information hiding,” then one might make the argument that “everything that was encapsulated was also hidden.” This is obviously not true. For example, even though information may be encapsulated within record structures and arrays, this information is usually not hidden and is available for use. Encapsulation is just getting a set of operations and data together which belong together and putting them in a capsule.

Abstraction, information hiding, and encapsulation are different but related. Abstraction is a technique that helps us identify which specific information should be visible, and which information should be hidden. Encapsulation is the technique for packaging the information in such a way as to hide what should be hidden, and make visible what is intended to be visible. Encapsulation can be thought of as the implementation of the abstract class.

Pull or Push, What do you like?

There is enough confusion and debate about what is the best model for publishing from a CMS based system. Some advocate the pull model and others the push model based on the ability to scale and be more reliable.

Let us see the pros and cons of these

Pull

• Suited for highly dynamic content
• Suitable for situations in which you want to feed content based on personlization.
• Pull CMS must be used with caching for ensuring faster reads and content independence.
• Can feed data on demand and does not need time based or trigger based push mechanism

Push

• Content Independence – if the CMS engine or database is unavailable the site could be down but with push, users would not know
• Pull CMS with it’s server side scripting language and database requirements could place a higher load on a server than a Push CMS, at least during heavy usage hence Push would be useful for static content with a lot of reads.
• Is server independent, it can push a set of HTML files in a web server independent format for consumption
• Should have a schedule based or trigger based push mechanism

Theoretically, one can achieve push benefits by using pull+caching and hence all the benefits and dynamicity of pull come along with it.

Any page with the need of frequent updates such as real time statistics, user comments, automated relevant links and a host of other things would become stale pictures of the “baking” moment in a push environment such as described.

1. Information on push
2. Comparison between push and pull

Cron and Control-M

In our production environment we had to review and replicate all the CRON jobs running on one of the stacks to the other new stack. Since the stack consists of multiple nodes clustered together running Jboss and another cluster of tomcat nodes, we would have to collect the details from all the servers.

By definition CRON has a single-tier architecture. This means that it is running as a single process on a single machine without any agents or server to communicate with. It also means that each instance of CRON is isolated and a problem in one of the instances on one of the machines would not affect others. This prevents it from becoming a SPOF (Single point of failure) but increases the maintenance and data aggregation overhead. Any changes have to be installed on all the nodes instead of a central machine. Therefore, each scheduler must reside on its own machine and contain its own database. Since there is no integration between the schedulers on the various machines, it is not possible to transfer jobs from one machine to the other, even if one machine has a heavy workload.

To view all the cron jobs on a machine by a user use

• crontab -u exampleuser -l

You can create a cron job from that file as follows:

• crontab /tmp/my_cron_jobs.txt

(Or for exampleuser:

• crontab -u exampleuser /tmp/my_cron_jobs.txt

For more information on creating and editing a cron job refer this and this.

Control-M by BMC software, takes the scheduling and execution of jobs at a higher level of abstraction where in all the jbos can be defined on multiple nodes using a central console. The results would be available on the central dashboard and can be tracked. Alerts are generated from the central location. There is failover support too.

For more differences between Control-M and Cron, refer to this pdf.