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 <ruch...@wso2.com> 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: ruch...@wso2.com <ruch...@wso2.com>, blog: > ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, > mobile: +94 77 5493444 <%2B94%2077%205493444>* > > _______________________________________________ > Architecture mailing list > architect...@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Cheers, Madhuka Udantha http://madhukaudantha.blogspot.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
