Yes, it is the same, except application object itself is replaced by a module.
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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
