Hi Rasika, Agree on all you the points. >>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. Let me explain the issue, The JDK/JVM is not we provide or have control over. Customer will choose among many different builds of the JVM. If we rely on JDK provided libraries, and then any issue is reported due to that, will be a support nightmare. Because usually we look into our code/library first and then only we realise it is an issue with JDK provided libs. Valuable time will be lost and not to mention customer confidence. Finding an issue latent in particular JVM build is very difficult, and knowledge is rare. Therefore I fundamentally against relying on Java provided libraries.
Cheers, Ruwan 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 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Ruwan Abeykoon* *Architect,* *WSO2, Inc. http://wso2.com <http://wso2.com/> * *lean.enterprise.middleware.* email: [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
