Questions about BSF in Server Side Scripting

[Charlie Consumer <fa...@yahoo.com>]

Hi,

I'm trying to integrate BSF into a server side
application.  The documentation of BSF doesn't discuss
some important questions with regards to server side
scripting.  I wanted to use one BSFManager for the
entire application.  I have a couple of questions:

1)  Is BSFManager thread safe?  Are there any rules
the BSFEngines have to adhere to with regards to the
thread model?  Do seperate threads get seperate stack
frames or seperate global variable declarations?

2)  What is the type of the argument for the "Object
script" in BSFManager.exec()?  I've seen code using a
String, but what else can it be?  Can it be a file? 
Why is it of type of Object?

3)  What happens if two threads run the following code
at the same time?

   String language = manager.getLangFromFilename(
scriptFile.getName() );
   manager.declareBean( "request", request,
request.getClass() );
   manager.declareBean( "response", response,
response.getClass() );
   manager.exec( language, scriptFile.getPath(), 0, 0,
script );

Will calling declareBean() result in two different
instance variables, or will they overwrite each other?

4)  Calling exec() twice retains state from the
previous run.  

   BSFManager.exec( "jython", "", 0, 0, "i = 3" );
   BSFManager.exec( "jython", "", 0, 0, "print i" );

That will print out 3.  In a server application you
don't really want retention of state since it could
result in unpredictable behavior.  Are exec() and
eval() the same?  The exec() method I expect to simply
fire off a script and not retain state between calls
or threads, but eval() I expect should retain state. 
Sort of like interactive programs would use eval(),
but users who want to run a script and retain no state
could use exec().

Thanks
Charlie

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org

Re: Questions about BSF in Server Side Scripting

["Rony G. Flatscher" <Ro...@wu-wien.ac.at>]

Charlie,

attempting a few answers (if you look at the sources, you probably can 
answer most of your answers yourself) ...

>1)  Is BSFManager thread safe?  Are there any rules
>the BSFEngines have to adhere to with regards to the
>thread model?  Do seperate threads get seperate stack
>frames or seperate global variable declarations?
>
A BSFManager allows the invocation of multiple engines, whereby it 
caches each engine.

You can create multiple BSFManagers which would have their own cached 
engine instances.

You can create BSFEngine-instances individually.

>3)  What happens if two threads run the following code at the same time?
>
>   String language = manager.getLangFromFilename(
>scriptFile.getName() );
>   manager.declareBean( "request", request,
>request.getClass() );
>   manager.declareBean( "response", response,
>response.getClass() );
>   manager.exec( language, scriptFile.getPath(), 0, 0,
>script );
>
>Will calling declareBean() result in two different
>instance variables, or will they overwrite each other?
>
If working with the same instance of BSFManager they would overwrite 
each other.

>4)  Calling exec() twice retains state from the
>previous run.  
>
>   BSFManager.exec( "jython", "", 0, 0, "i = 3" );
>   BSFManager.exec( "jython", "", 0, 0, "print i" );
>
>That will print out 3.  In a server application you
>don't really want retention of state since it could
>result in unpredictable behavior.  Are exec() and
>eval() the same?  The exec() method I expect to simply
>fire off a script and not retain state between calls
>or threads, but eval() I expect should retain state. 
>Sort of like interactive programs would use eval(),
>but users who want to run a script and retain no state
>could use exec().
>
Have you tried different instances of BSFManagers or BSFEngine for that matter?

Hope that helps a little,

---rony



---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org