+1 for the Nashorn update. Is it possible for us to follow an API similar to NodeJS? This will make it easy for JavaScript developers to use Jaggery runtime. Also would love to get console.log() for logging instead of making Log objects and logging things (just a thought).
Cheers~ On Mon, Jun 2, 2014 at 2:02 AM, madhuka udantha <[email protected]> wrote: > > > > On Mon, Jun 2, 2014 at 12:46 PM, Ruchira Wageesha <[email protected]> > wrote: > >> Yes, it is the same, except application object >> > > >> itself is replaced by a module. >> > +1 > >> >> >> On Mon, Jun 2, 2014 at 12:33 PM, madhuka udantha < >> [email protected]> wrote: >> >>> Hi, Ruchira >>> >>> 'app.server()' is similar for existing 'application.serve()' in jaggery >>> , isn't it regard functionality? >>> >>> Here[1] is sample for application.serve(). >>> >>> [1] >>> https://github.com/Madhuka/MadhukaBlogRepo/tree/master/SampleApps/JaggeryApps/service/ >>> >>> >>> >>> On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> We have started the integration of JSR-223 i.e. javax.script API with >>>> Jaggery. Sorry for the lengthy mail, but this is just to share the status >>>> and get your all kinds of feedbacks. A Jaggery fork and a distribution with >>>> the following improvements can be found at [1] and [2] respectively. In >>>> case you want to try this out before sharing your feedbacks, you can >>>> download a Jaggery distribution with all the above implementations at [2]. >>>> It consists of 5 demo apps. (At the moment, this has been tested only on >>>> linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 >>>> supports only an older version of ECMAScript, this pack will not work. But >>>> in order to get the support even on JDK 6, we will have to pack the JSR-223 >>>> rhino implementation with a rhino 1.7 version, following a similar way >>>> described at [7]) >>>> >>>> With the integration with JSR-223, we had to and thought to do a few >>>> changes and improvements to Jaggery which will be detailed below. BUT, >>>> please note that, every existing Jaggery application will work as it is, >>>> independent of those improvements. i.e. With a version field in >>>> jaggery.conf, we internally decide, whether to go with the newer version. >>>> >>>> *Key Decisions* >>>> >>>> 1. JSR-223 support >>>> - With this, Jaggery will use Nashorn from JDK8 onwards and will >>>> fallback to JDK's embeded Rhino version with JDK7 or below. >>>> 2. Saying good bye for hostobjects >>>> - Hostobjects are a concept of Rhino and it was needed to follow >>>> certain conventions when you write your hostobjects. With JSR-223, we >>>> cannot have it anymore. But, instead of that, you can refactor only >>>> the >>>> hostobject *.java class into *.js file which contains the Java code >>>> and >>>> plug it. >>>> 3. Dropping E4X support >>>> - E4X was an extension to ECMAScripts and usage of E4X is being >>>> deprecated in many places. Also, AFAIK, there is no support for E4X >>>> in >>>> nashorn. This will be replaced by a Axiom/DOM like modules. i.e. >>>> without >>>> altering the spec. >>>> 4. Except the bare minimal, everything else is separated into >>>> commonjs modules >>>> - This will give much more flexibility and extendability for >>>> Jaggery. i.e. In order to extend Jaggery, developers don't need to >>>> be Java >>>> developers anymore >>>> 5. Introduction of app.server() method >>>> - In the current version, routing mechanism has been implemented by >>>> Jaggery core and there is no way to intercept that. This makes it >>>> harder to >>>> write cooler modules for Jaggery, such as express, connect for node. >>>> Using >>>> app.server(), Jaggery core delegates request serving to a single >>>> callback. >>>> But, via that callback, users can call their own routing modules and >>>> do >>>> whatever they want. You can even implement the current *.jag model, >>>> on top >>>> of app.server()[refer demo3]. Also, we have written an express like >>>> routing >>>> framework which can be used to define REST APIs very easily through >>>> Jaggery. This will be a good alternative for JAX-RS developers too. >>>> 6. Servlet 3.0 Async support >>>> - Another key feature is utilizing Async servlet support. So, >>>> concurrency will not be restricted by the available thread count >>>> anymore. >>>> 7. CommonJS module system >>>> - At the moment, Jaggery has its own module system. Instead of >>>> that, we though of going ahead with commonjs module specification. >>>> With >>>> this, commonjs compliant modules will be able to use within Jaggery. >>>> i.e. >>>> Any node module which doesn't depend on node core APIs, can be used >>>> in >>>> Jaggery as well, without doing any change. >>>> 8. Module versioning and nested module support >>>> - Another improvement is, adding module versioning support for >>>> Jaggery modules. i.e. x app(or module) can use y1 version of y >>>> module, >>>> while another z app(or module) can use y2 without conflicting each >>>> other. >>>> For this too, we are also using package.json as per the commonjs >>>> specification >>>> 9. Support for deploying directly on top of tomcat >>>> - With the above Jaggery core minimisations, a Jaggery app can >>>> be even deployed on top of tomcat, subjecting to a WEB-INF directory >>>> which >>>> contains jaggery core jars and web.xml >>>> 10. Improved command line tool >>>> - clamshell-cli based command line tool with history support >>>> etc. With this, we expect people to write more command line tools >>>> such as >>>> built tools, package managers etc. using Jaggery >>>> >>>> *Demo Apps* >>>> >>>> 1. https://github.com/ruchiraw/jaggery/tree/master/apps/demo1 >>>> - this is the bare minimal with app.server() >>>> - can be accessed via http://localhost:9763/demo1 >>>> 2. https://github.com/ruchiraw/jaggery/tree/master/apps/demo2 >>>> - this shows about module versioning and nested modules >>>> - can be accessed via http://localhost:9763/demo2 >>>> 3. https://github.com/ruchiraw/jaggery/tree/master/apps/demo3 >>>> - this shows how you can implement *.jag support on top of >>>> app.serve() >>>> - can be accessed via http://localhost:9763/demo3/index.jag >>>> - you can click on "See Docs" link too >>>> - at the moment, this doesn't support all the APIs of the >>>> current version, but this is a PoC for that. >>>> 4. https://github.com/ruchiraw/jaggery/tree/master/apps/demo4 >>>> 1. this shows the usage of express like routing module developed >>>> by SameeraM[3] >>>> 2. can be accessed via http://localhost:9763/demo4/users/1 or >>>> http://localhost:9763/demo4/apps/1 >>>> 5. https://github.com/ruchiraw/jaggery/tree/master/apps/demo5 >>>> - by copying this into the webapps directory of an apache tomcat >>>> server, you can try out how Jaggery can work on tomcat >>>> - this app is exactly like aboute demo4, but this time, it runs >>>> on tomcat. >>>> - can be accessed via http://localhost:8080/demo5/users/1 or >>>> http://localhost:8080/demo5/apps/1 >>>> >>>> When, above demos are run, you will be able to see module resolution >>>> log messages at the moment. Hence, if you are doing any kind of load >>>> testing etc., >>>> >>>> - If it is Jaggery server, please make "development" as false in >>>> jaggery.conf >>>> - If it is on tomcat, set "jaggery.development" as false in >>>> web.xml. >>>> >>>> This will enable caching for loaded modules, pooling for script engines >>>> and async servlets. Further, you can fine tune the performances using the >>>> jaggery.conf[4] parameters on Jaggery and web.xml[5] parameters on tomcat. >>>> I have done only a small load test to test the server concurrency. Will do >>>> a proper benchmarking round after improving further. >>>> >>>> *Command Line Tool* >>>> >>>> - In order to use the cmd tool, you need to first set the >>>> environment variable JAGGERY_HOME pointing to your unzipped Jaggery >>>> distribution >>>> - export >>>> >>>> JAGGERY_HOME=/Users/ruchira/binaries/jaggery/1.0.0/m0/jaggery-0.9.0-SNAPSHOT >>>> - Then download *.jar at [8] >>>> - Execute the downloaded *.jar using >>>> - java -jar >>>> org.jaggeryjs.cmd-0.9.0-SNAPSHOT-jar-with-dependencies.jar >>>> - You can require the modules >>>> - relative to your working directory. e.g. require('./foo') if >>>> it the module foo is at <cwd>/foo.js or <cwd>/foo/ >>>> - If you have a jaggery-modules directory working direcotry as >>>> <cwd>/jaggery-modules, then you can require any module exists there >>>> using >>>> require('foo') etc. >>>> >>>> Current implementation is just the core to get started and demonstrate >>>> what I have mentioned above. We have plans along the line to write >>>> a comprehensive Jaggery Package Manager, a maven plugin to execute unit >>>> tests etc. >>>> >>>> [1] https://github.com/ruchiraw/jaggery >>>> [2] >>>> https://github.com/ruchiraw/sandbox/raw/master/jaggery/1.0.0/m0/jaggery-0.9.0-SNAPSHOT.zip >>>> [3] https://github.com/splinter/jaggery-pipe >>>> [4] >>>> https://github.com/ruchiraw/jaggery/blob/4560a303f809d532ad041125c1a29ecc2eb9df55/apps/tomgery/jaggery.conf >>>> [5] >>>> https://github.com/ruchiraw/jaggery/blob/master/apps/demo5/WEB-INF/web.xml >>>> [6] https://github.com/vladimirvivien/clamshell-cli >>>> [7] >>>> https://wiki.openjdk.java.net/display/Nashorn/Using+Rhino+JSR-223+engine+with+JDK8 >>>> [8] >>>> https://github.com/ruchiraw/sandbox/raw/master/jaggery/1.0.0/m0/org.jaggeryjs.cmd-0.9.0-SNAPSHOT-jar-with-dependencies.jar >>>> >>>> >>>> -- >>>> >>>> *Ruchira Wageesha**Associate Technical Lead* >>>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>> <http://wso2.com>* >>>> >>>> *email: [email protected] <[email protected]>, blog: >>>> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >>>> mobile: +94 77 5493444 <%2B94%2077%205493444>* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> Madhuka Udantha >>> http://madhukaudantha.blogspot.com >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Ruchira Wageesha**Associate Technical Lead* >> *WSO2 Inc. - lean . enterprise . middleware | wso2.com <http://wso2.com>* >> >> *email: [email protected] <[email protected]>, blog: >> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >> mobile: +94 77 5493444 <%2B94%2077%205493444>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Cheers, > Madhuka Udantha > http://madhukaudantha.blogspot.com > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulitha.me <http://dulitha.me>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>* *~Github @dulichan <https://github.com/dulichan>* *~SO @chan <http://stackoverflow.com/users/813471/chan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
