jakarta-bsf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Langley, John" <langl...@telcordia.com>
Subject RE: Any open source or comercial javascript engine other than Rhino
Date Fri, 26 Jan 2007 17:40:32 GMT
Actually... I believe the license is MPL (Mozilla Public License),
someone please correct me if I'm wrong. MPL is less restrictive than
GPL, but would require you to contribute your modifications of rhino
(the js engine) back to the community that developed it. However, it
_would not_ require you to contribute all of the code for an application
that uses it to the community. The distinction is quite significant (in
most cases). 

Just my 2 cents.

Langley 

-----Original Message-----
From: Daling Xu [mailto:daling_xu@yahoo.com] 
Sent: Friday, January 26, 2007 12:13 PM
To: Bean Scripting Framework users
Subject: Any open source or comercial javascript engine other than Rhino

Hi,
   
  Because of the concern on the Rhino's GPL license. We would like to
find some LGPL or comercial javascript engine supported by BSF. 
   
  So far, I found only one which is FESI. But it looks pretty old.
   
  Anybody here used any javascript engine other than Rhino?

Thanks
   
  Linda

"Rony G. Flatscher" <Rony.Flatscher@wu-wien.ac.at> wrote:
  Hi Linda,

Daling Xu wrote:
> I continued to drill down on this issue. From reading of the BSF
source code, I found that the "bsf" object that was put into the
javascript global context is actually a object of BSFFunctions object
which only contains a subset of BSFManager methods. The BSFFunctions
doesn't have a getObjectRegistry method.
> 
> This explains the reason of the exception I ran into. 
> 
> Now my question is
> (1) Why BSFFunctions doesn't support the getObjectRegistry method?
> 
Don't really know what the developers had in mind here.

> (2) How can I retrieve the bean objects from the ObjectRegiestry
inside the script code?
> 
You can't. The real reason is with the original authors, maybe Sanjiva,
if he reads this, could shed some light on this.

However there may be one (good) reason: security. One never can be sure
who writes which scripts. So for security reasons it makes sense to give
no one the ability to figure out what the ObjectRegistry holds. The Java
hosts (Java programs that dispatch scripts via BSF) would know what they
put into the registry for the scripts to interact/work with, so for the
scripts that would not really be a shortcoming. In the case that one
needs to make a collection of Java objects available to the scripts,
then one is able to register a collection object for the script.

HTH,

---rony

P.S.: The nice thing about FOSS is that in the case that you really hit
a barrier you do not want to cope with, that you can go back to the
sources and enhance/change/tailor the code to your needs.


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



 
---------------------------------
 Get your own web address.
 Have a HUGE year through Yahoo! Small Business.

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


Mime
View raw message