Posted by larryjava
on June 29, 2012 at 10:22 AM PDT
For us at Amway Corp, a key part of creating batch processes, with Java, was using the LaunchClient command and
J2EE Client applications. We felt we were very close to being able to run our Java batch processes on the
application server. But more trials and tribulations were ahead of us.
We created a J2EE Client application\program that would call a "hello world" EJB.
After deploying the code to the application server, we started our first Java batch process.
Nothing happened. There was no evidence that the client or EJB executed on the application server.
Upon investigation, we learned that the J2EE Client container was a separate, optional, install
on the application server. So we corrected this by having our application server administrator
install the client container. Once again, we started our test Java batch process.
A little progress. The client program attempted to run. We saw evidence on the app server logs.
But the client did not execute successfully.
Upon investigation, we learned that the app server implementation of the J2EE Client container
contained a software bug. A fix from the app server vendor was needed to fix this.
So we corrected this by having our application server administrator
install the software fix to the client container. Once again, we started our test Java batch process.
A little more progress. The client program attempted to run. We saw evidence on the app server logs.
But the client seemed to "freeze" at a certain point in its execution.
Upon investigation, we learned that a client "login" screen was appearing on the app server.
The J2EE Client program would not be allowed to execute until someone or something completed the
login process. At this point we made the decision to disable security on the client container.
This would prevent the login screen from appearing when running the client program on the app server.
We would deal with the login screen at a later time.
Once again, we started our test Java batch process.
Success! We executed the LaunchClient command from the app server, which started the J2EE Client program,
which invoked a "hello world" Stateless Session EJB. It all worked!
We never thought we would be so happy to see a "hello world" message on the app server message log.
But we were.
Now a new issue confronted us.
Within the application, the name of the client program is "hardcoded" in a property file.
It was called a "Java class entry point".
This creates the situation where only one J2EE client program can be useable or "active" per application or EAR file.
We have many batch processes. Each batch process has their own client program.
We didn't want to have a separate application (or EAR file) for each batch process.
We wanted one application\EAR to contain all of our batch processes.
Hardcoding the name of the active client program within the application would not work for us.
We hit another roadblock in our quest for batch processing with Java. This was a big one.
And we still had to resolve the client container login screen issue.
Were we ever going to figure it all out regarding Java batch?
The answer was "YES"; and the solutions, we were looking for, would come from an unlikely Java source.
To be concluded...