Mother Generating Processes M.G.P

Mother Generating Processes M.G.P

Released 5 years ago , Last update 5 years ago

An automated program that launches automatically several samples of processes in more than one JVM and without human intervention. With M.G.P you can save yourself from the agony of waiting to start a computer program of some private or public business that you are operating.

From the Various business requirements we face in building our programs, there are some needs to achieve. For example:

1) executing processes exactly at a specific date and time chosen by the user.
2) executing independents and parallels processes.
3) executing dependents processes of previous ones.
4) executing processes by order of completion.
5) continuing or quitting the program after a failure in the last executing process.
6) stopping a process after a failure.
7) dropping human intervention from the whole procedure.

"Mother Generating Processes" or M.G.P shows an efficient simulation in which it accomplishes each of these needs by using Spring batch, an open source framework, for process running and also by using at runtime the execution method of processes each on a separate JVM.

There are other components that offer similar solutions. Quartz is one of them. It utilizes Thread pool which is managed by a JVM, an Operating System and a CPU. Thread pool could cause problems like data corruption, bad performance, Dead-locks and others knowing that it preceded the Java platform. On the other hand, creating more than one JVM will save us from these high risks caused from the overload of threads. Also, having separate JVM’s is easier when it comes to ending or killing a specific JVM without affecting the others.

From a Software component view, M.G.P can be considered as a package that contains 6 Java classes represented by 1 main process, and 5 others automatically generated, each referenced by its own application context. This is the simulation I applied to clearly cover the most important scenarios that could be faced when dealing with scheduled jobs. This way other simulations could be applied by simply developing as many processes needed that will execute programs or even act as main processes for generating others and so on.

Let us see more explanation in the Program documentation.


14 day 14-day money-back guarantee


Application License

  • Perpetual license

  • 1 application

  • Can distribute binary products only

  • Commercial use

  • 6 months support


Hosted License

  • Perpetual license

  • 1 site, 1 server

  • No distribution (hosted use only)

  • Commercial use

  • 6 months support

Need custom services for this product? Get a quote

Instructions and documentation file


I wrote my program in java code using JRE, JDK version 1.5+ as reference and run it on Windows operating system. As for the jars i used for my code, you can either set their Class Path once for all in your JAVA_HOME or do as mentioned in the upcoming paragraphes. I did not run it under Linux system but it should work with a slice change (refer to PS at the end of the document). Let us see the instructions on how to run my program from the Command Prompt:

After downloading my program you need to do the following:

A) Copy and paste folder MotherGeneratingProcesses under (C:)

If you paste it in another directory you will have to set the correct path in 2 or 3 things which are:

i)the Class Path of the 11 jars in step C) below and in the .bat files

ii)the folder batFiles under MotherGeneratingProcesses containing the .bat of my jobs, read in my code:

process1[3] = "C:\\MotherGeneratingProcesses\\batFiles\\runJobOne.bat";

iii)the folder txtFiles under MotherGeneratingProcesses containing the .txt of my jobs, read in my code:

FileWriter fstream = new FileWriter("C:\\MotherGeneratingProcesses\\txtFiles\\processOne.txt");

B) In the CMD, execute the following command:

    cd C:\MotherGeneratingProcesses\javasoftwaregenerating\src\autogeneratingprocesses

C) After, you need to set the Class Path of the 11 jars for my program. Paste and execute the following in the CMD:

    set CLASSPATH=C:\MotherGeneratingProcesses\javasoftwaregenerating\bin;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.aopalliance_1.0.0.v200905130917.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.apache.commons.logging_1.1.1.v201101211721.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.springframework.aop-3.1.0.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.springframework.asm-3.1.0.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\spring-batch-core-2.1.8.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\spring-batch-infrastructure-2.1.8.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.springframework.beans-3.1.0.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.springframework.context-3.1.0.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.springframework.core-3.1.0.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.springframework.expression-3.1.0.RELEASE.jar;C:\MotherGeneratingProcesses\javasoftwaregenerating\alljars\org.springframework.transaction-3.1.0.RELEASE.jar

D) Then execute step 1) from below of the following paragraph.


I used the Spring framework batch technique to be able to do the following steps:

1) Launching my program by using the CommandLineJobRunner class. This class takes 2 arguments: the xml application context containing the job to launch and the bean id of that job. Here’s how to launch a job with java command from cmd.exe in Windows or from sh in Linux:

    java simpleJob.xml simpleJob time1=12:59:57  time2=13:00:02 job4=1 param4=hello

The other 5 parameters are optional and you can add as much as you want. I added them to use in my program. The difference between time1 and time2 is 5 seconds. As for job4 equals 1, I used it as a launching code for job four, and param4 to be the message to print.

2) Processing multiple jobs concurrently by starting them as new processes on different JVMs. My program has 5 jobs to execute. They are represented by the following application contexts and their bean definition classes:






simpleJob.xml is the main job for generating all 5 jobs. Its bean simpleJob refers to the class. We can refer to it in this document as our Main Program.

3) Passing optional parameters to use in calling each process depending on the business needs. My program starts executing job one when the System Time becomes equal to the date + time1 input parameters, or stays on hold until the condition satisfies. In case the System Time has passed the calculated time entered, main job throws an exception and the program will exit (Quitting the main program). When applying the right scenario, a .bat file will execute job one, at runtime, as a new ‘process one’ on its own JVM. File runJobOne.bat sets the Class Path of the jars used and calls the CommandLineJobRunner class taking 2 parameters the simpleJobOne.xml and simpleJobOne.

4) Executing ‘process two’ with another way of launching using jobLauncher class to run the job. We define which application context to use by calling ClassPathXmlApplicationContext.

    AbstractApplicationContext applicationContext = new ClassPathXmlApplicationContext("simpleJobTwo.xml");

The bean id is referred to by the property job defined in the application context simpleJobTwo.xml along with properties jobLauncher and jobRepository.

   <!-- Adding below bean's configuration responsible for launching Job Two -->
<bean id="mainProcess" class="autogeneratingprocesses.MainProcess">
    <!-- 3 properties to be imported by our main job definition class:MainProcess -->
    <property name="jobLauncher" ref="jobLauncher" />
    <property name="jobRepository" ref="jobRepository" />
    <!-- property job refers to the bean simpleJobTwo -->
    <property name="job" ref="simpleJobTwo" />

All 3 properties are imported by class. To run job two, jobLauncher class takes 2 parameters the job bean and the job parameters.

   // Launching job two by passing job and job parameter to jobLauncher., builder.toJobParameters());

Using this method, to launch a job, results in an instance from the jobRepository class. This way we can retrieve the job execution status whether completed or not.

   // Each run of a job results in an instance which is a JobExecution.
    // Retrieving information of the last job executed, that of job two.
    JobExecution jobTwoExecution = jobRepository.getLastJobExecution(
            job.getName(), builder.toJobParameters());

    // If job two has succeeded then job three starts executing
    if (jobTwoExecution.getStatus().equals(BatchStatus.COMPLETED)) {....}

This is an advantage if I need to execute a consecutive process depending on the previous one. Nevertheless, we can read, from our Main Program, all the objects implemented in which is the bean class definition of job two retrieved by the application context.

   // After the execution of job two finishes, we can access any object
    // from its bean definition.
    ProcessTwo processTwo = (ProcessTwo) applicationContext.getBean(
            "jobtwo", ProcessTwo.class);

Implementing jobLauncher to run a process is useful in case of returning information needed for the other processes to be executed.

5) Executing ‘process three’ depending on process two’s execution status. If ‘process two’ is successful then, at runtime, a .bat file will execute job three as a new ‘process three’ on its own JVM. File runJobThree.bat sets the Class Path of the jars used and calls the CommandLineJobRunner class taking 2 parameters the simpleJobThree.xml and simpleJobThree. Whether if ‘process two’ fails then ‘process three’ won’t execute and we continue (Continuing the main program). If ‘process three’ fails then it throws an exception (Stopping process three after a failure).

6) As said in 2), ‘process four’ is generated by class. It is run like the following:

    CommandLineJobRunner.main(new String[]{"simpleJobfour.xml", "simpleJobFour"
    , "jobFourVal="+jobFourParam, "messageFour="+msgFourParam});

CommandLineJobRunner and jobLauncher have by default a JVM systemExiter. To disable it and make more than one launch in the same JVM, we write the following in class:

    CommandLineJobRunner.presetSystemExiter( new SystemExiter() { 
                              public void exit( int status ) {} } );

This way 'process four' will start running after 'process two' has finished executing.

7) Finally after 'process four' finishes executing, 'process five' will execute at runtime and on its own JVM. File runJobFive.bat sets the Class Path of the jars used and calls the CommandLineJobRunner class taking 2 parameters the simpleJobFive.xml and simpleJobFive with optional parameters.

Overall my program can solve the problem of late or early launches of many programs, related or not, of a specific business you need without human intervention by manipulating in the implementation and in the number of processes and reusing the basic engine of my simulation.

PS: my program basically runs on Linux system but you need to change basically the local directory (C:) I am using in my program to (/home) and especially the writing of the following code syntax:

Instead of:

String[] process = new String[4];

process[0] = "cmd";

process[1] = "/C";

process[2] = "start";

process[3] = "C:\\MotherGeneratingProcesses\\batFiles\\runJob.bat";

Runtime.getRuntime().exec( process ); 

Write something like that:

String[] process = {"/bin/bash", "/home/MotherGeneratingProcesses/batFiles/"};  

It should work.

3 licenses, starting from From » $99999.99 View Licenses

Get A Quote

What do you need?
  • Custom development
  • Integration
  • Customization / Reskinning
  • Consultation
When do you need it?
  • Soon
  • Next week
  • Next month
  • Anytime

Thanks for getting in touch!

Your quote details have been received and we'll get back to you soon.

or Get a quote

for customization or integration services

Or enter your name and Email
No comments have been posted yet.