Calling java from flowscripts: best practices?

[Thomas Kjeldahl Nilsson <tn...@marcello.no>]

Hello all,

	I have a queston on calling Java from flowscripts. In my project, we 
have most of the businesslogic running on a weblogic server, implemented 
as stateless sessionbeans. I call these beans from a simple "client" 
class, which I instantiate in my flowscripts.
Currently, in every flowscript function that needs access to 
businesslogic I import and instantiate the "client" class that talks to 
the weblogic server.

Questions:
Is this an efficient way of doing this? Given that our webapplication is 
going to be under heavy load (popular national-wide telecom 
application), will my current approach scale well? My client class seems 
to be cached on successive different function calls to it, but I'm a 
little wary of later problems with scalability.

The "official" cocoon doc is somewhat short on info best practices in 
flowscript->java situations. My current impression is "you can 
instantiate classes, call static methods without instantiating, or wrap 
your code into Avalon components that may or may not give you 
performance benefits." :-)

Thoughts on this?

regards,
Thomas Nilsson




(Example from my flowscript below- I call a function 'shortnumber' to 
set up a jxtemplate page with a basic form in it, and 
'shortnumber_submit' gets called when the form is submitted.)



Flowscript snippet:
----------------------------

function shortnumber(){

    try {

       //Get shortnumber from service layer
       importClass(Packages.no.marcello.wo.client.test.CocoonClient);
       var client = new CocoonClient();
       var shortnumber = client.getShortNumber();
   	
       // Prepare language elements used in the page.
       var language = {
	shortnumber: "Kortnummer",
       	store: "Lagre",
       }

       cocoon.sendPage("shortnumber.xml", {"shortnumber" : shortnumber, 
"language" : language});
       				
     } catch (e) {
	var error = "Error:" +e.name +" Error message: " + e.message;
	cocoon.sendPage("error.xml", {"error" : error});
     }

}


function shortnumber_submit(){

    try {

  // Get newShortnumber from form input
  var newShortNumber = cocoon.request.getParameter("shortNumberInput");

  // Update shortnumber
  importClass(Packages.no.marcello.wo.client.test.CocoonClient);
  var client = new CocoonClient();
  client.setShortNumber(newShortNumber);

  // Show confirmation message in the shortnumberset webpage
cocoon.sendPage("shortnumberset.xml", {"shortnumber" : newShortNumber});

     } catch (e) {
	var error = "Error:" +e.name +" Error message: " + e.message;
	cocoon.sendPage("error.xml", {"error" : error});

     }

}


---------------









---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Calling java from flowscripts: best practices?

[Joerg Heinicke <jo...@gmx.de>]

On 24.05.2004 09:02, Thomas Kjeldahl Nilsson wrote:

> The "official" cocoon doc is somewhat short on info best practices in 
> flowscript->java situations. My current impression is "you can 
> instantiate classes, call static methods without instantiating, or wrap 
> your code into Avalon components that may or may not give you 
> performance benefits." :-)

It's a new technology and there are not many people having so much 
experience for providing best practices. I did it with an Avalon 
component, but I can't imagine that this solution is faster than 
instantiating a plain java object as you have to assign the Avalon 
lifecycle (I use Cocoon logging in my class). Even pooling will not elp 
much as a lookup often takes more time than an instantiation. But this 
depends obviously heavily on the class to instantiate of course. If you 
need heavy calculation for it, remote lookups, etc. it will be probably 
better to pool it. Otherwise not.

All IMO.

Joerg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org