Hi Rasika, We use the same implementation and use javax.script.*; even with the bsf and bsf also provide the rhino16 engine. In script mediator we need to use the Scriptable interface and that interface package name is different in JDK7 and JDK8 when the script is executed. and also internal classes as the implementation in JDK. There is no interface in javax.script to cast that objects. In script mediator we use custom class binding with script and that is the hard part we can handle. Please refer the setPayloadXML(Object payload) in [1]. That is why we decided not to change the script engine and used the same rhino16 engine. Then the script mediator behaviour is same in any JDK version.
[1] https://github.com/wso2/wso2-synapse/blob/master/modules/extensions/src/main/java/org/apache/synapse/mediators/bsf/ScriptMessageContext.java Thanks, Nuwanw On Thu, May 5, 2016 at 11:49 AM, Rasika Perera <[email protected]> wrote: > @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 > -- Nuwan Wimalasekara Senior Software Engineer - Test Automation WSO2, Inc.: http://wso2.com lean. enterprise. middleware phone: +94 71 668 4620
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
