@Nuwan and All,
I am not very familiar with BSF. Besides Apache BSF does not appear to have
active development. My suggestion is we should go with Scripting API(JSR223
). This javax.script.* API is available on runtime(rt.jar).
Any scripting language which implements it, we can support through third
part libraries. List of scripting engines are listed in [1].
How we invoke a particular scripting engine through Scripting API is;
import javax.script.*;
ScriptEngine nashornEngine = new
ScriptEngineManager().getEngineByName("javascript");
ScriptEngine groovyEngine = new
ScriptEngineManager().getEngineByName("groovy");
Only *difference* about Nashorn is that it available as an extension on JRE
by default.
@Ruwan,
Please find inline comments.
1. This will cause any bugs in JS engine, or integration, to be reported as
> WSO2 product issue. e.g. Historically similar integrations cause bugs like
> [1] yield OOM in applications.
IMO I think it doesn't matter whether internal or external library, when
someone lacks parsing error trace it will always reported as a WSO2 product
issue.
2. We can upgrade the JS library at our own discretion, for performance or
> bugfixes if we use a library outside.
Yes. This can be done for any JSR223 implementation.
Incase of Nashorn vs. Rhino; Nashorn is more powerfull and fills the lack
of security in Rhino.
Nashorn brings a 2 to 10x performance boost over the former Rhino
implementation, although it is still somewhat short of V8, the engine
inside Chrome and Node.js. Please refer [2] for more details on comparison.
[1] https://java.net/projects/scripting/sources/svn/show/trunk/engines
[2]
https://www.infoq.com/articles/nashorn
On Thu, May 5, 2016 at 10:00 AM, Nuwan Wimalasekara <[email protected]> wrote:
> Hi Manuranga,
>
> if the script engine is loaded from bsf-all(rhino16),
> org.mozilla.javascript.Context will be used. But script engine is loaded
> from JDK, sun.org.mozilla.javascript.internal.Context is used and those are
> available in JDK itself. Nashorn or Rhino7 does not depend any third part
> library. It load all required classes from JDK it self. and also If we use
> JDK to load the script engine, behaviour may also be changed according to
> JDK we are running.
>
> Thanks,
> Nuwanw
>
> On Wed, May 4, 2016 at 8:47 PM, Manuranga Perera <[email protected]> wrote:
>
>> Hi Nuwan,
>> Maybe `org.mozilla.javascript.Context` is the one you are looking for,
>> not `sun.org.mozilla.javascript.internal.Context`?
>>
>> On Wed, May 4, 2016 at 11:13 AM, Nuwan Wimalasekara <[email protected]>
>> wrote:
>>
>>> Hi Manuranga and Rasika,
>>>
>>> Thanks for the reply. But this is a different one. Below are the classes
>>> we can not use in our class since those are internal classes in JDK and we
>>> can not compile a class with below imports since those are only available
>>> in runtime.
>>>
>>> import sun.org.mozilla.javascript.internal.Context;
>>> import sun.org.mozilla.javascript.internal.Scriptable;
>>> import sun.org.mozilla.javascript.internal.ScriptableObject;
>>> import sun.org.mozilla.javascript.internal.xml.XMLObject;
>>>
>>> Thanks,
>>> Nuwanw
>>>
>>> On Wed, May 4, 2016 at 8:30 PM, Rasika Perera <[email protected]> wrote:
>>>
>>>> Hi Nuwan and all,
>>>>
>>>> We also faced the same issue when accessing Nashorn on OSGi
>>>> environment. To overcome the class-loading issues; you can modify system
>>>> bundle's package exports to include the Nashorn scripting API package(using
>>>> Fragment Hosts approach suggested in [1]).
>>>>
>>>> Please refer "nashorn-osgi-fragment" module [2] in UUF.
>>>>
>>>> <Fragment-Host>system.bundle;extension:=framework</Fragment-Host>
>>>> <Export-Package>jdk.nashorn.api.scripting;
>>>> version="${nashorn-osgi-fragment.version}"</Export-Package>
>>>>
>>>> Thanks
>>>>
>>>> [1] https://github.com/mszu/nashorn-scripting-api-fragment
>>>> [2]
>>>> https://github.com/wso2/carbon-uuf/blob/master/nashorn-osgi-fragment/pom.xml
>>>>
>>>> On Wed, May 4, 2016 at 8:04 PM, Manuranga Perera <[email protected]> wrote:
>>>>
>>>>> Hi Nuwan,
>>>>> Is the limitation you are facing due to OSGi level class def not found
>>>>> exceptions? We faced something slimier and that was due to Nashorn classes
>>>>> not been exposed via OSGi. We created a fragment bundle for the system
>>>>> bundle to solve this. Please contact Rasika if that's the case.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> With Regards,
>>>>
>>>> *Rasika Perera*
>>>> Software Engineer
>>>> M: +94 71 680 9060 E: [email protected]
>>>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>>>
>>>> WSO2 Inc. www.wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>
>>>
>>>
>>> --
>>> Nuwan Wimalasekara
>>> Senior Software Engineer - Test Automation
>>> WSO2, Inc.: http://wso2.com
>>> lean. enterprise. middleware
>>>
>>> phone: +94 71 668 4620
>>>
>>>
>>>
>>>
>>
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : [email protected]
>>
>
>
>
> --
> Nuwan Wimalasekara
> Senior Software Engineer - Test Automation
> WSO2, Inc.: http://wso2.com
> lean. enterprise. middleware
>
> phone: +94 71 668 4620
>
>
>
>
--
With Regards,
*Rasika Perera*
Software Engineer
M: +94 71 680 9060 E: [email protected]
LinkedIn: http://lk.linkedin.com/in/rasika90
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
