users@glassfish.java.net

Re: EJB3 Observer pattern

From: <glassfish_at_javadesktop.org>
Date: Wed, 20 Feb 2008 17:56:41 PST

Yea, I see what you mean. Bother.

I once had the opportunity to talk with the JBI developers a bit ago, and they said that they had this capability. Perhaps they punted on it. And I do appreciate the desire to avoid serializing the form.

So, I will offer a 3rd solution to you for you to consider.

One word: JavaScript.

(or any scripting language, frankly...)

It comes with Java 6 already, or you can get it here:
http://www.mozilla.org/rhino/

Rather than using JBI and XML to represent your processes, use JavaScript.

It's pretty painless to start with, and you can learn the ins and outs of using it better via the documentation.

So, what you have is a ScriptingBean which has a method (lets call in "run") that takes a reference to a blob of Javascript (internal DB reference, a file name, simply a String filled with Javascript, whichever).

Your "run" method prepopulates the Java script context with references to your other service SessionBeans, and it can even inject your Loan Application object.

your Javascript can literally be (this should look very familiar):
[code]
    var scheduleGenerator = new ScheduleGenerator(loan);
    var schedule = scheduleGenerator.getResult();
    
    loanDao.persistSchedule(loan, schedule);
    
    if (loan.getProposal().isRestructuring()) {
        loanService.loanRestructActivation(loan);
    }
    documentsService.groupGenerateActivationDocuments(loan);
    loan.setLoanStatus(em.getReference(DictLoanStatus.class,
            DictLoanStatus.ACTIVE));
    loan.setStatusChangeDate(new Date());
    
    actionService.genereteOrUpdateBeforeEndAction(loan, schedule);
[/code]

The benefit is simply that you can expose the javascript to end users, you can write a simple interface that generates the Javascript on the fly (if you like, for example, you can simply have a list of processes in a table, and a user could put them together how they like with your generator doing the detail work), etc. However the Javascript is created, you evaluate it dynamically, at run time.

Even in its most crude form, for simple scripts like this, whatever overhead incurred by Javascript is lost in the overall backend processing taking place.

Change it on the fly, no deploys, no restarts, just run it again. Works like a dream.

Give it a look, you can get a script running in your code probably in less than a 1/2 hour.

We use JS everywhere for all sorts of things.

Give that a look, may do the trick for you.
[Message sent by forum member 'whartung' (whartung)]

http://forums.java.net/jive/thread.jspa?messageID=260068