JSR 223: Scripting Pages in Java Web Apps Early Draft Review


News: JSR 223: Scripting Pages in Java Web Apps Early Draft Review

  1. The early review draft for JSR 223, Scripting Pages in Java Web Apps, is now available. The JSR will define how scripting languages (with PHP as their default example) can access servlet artifacts such as context, session, request, response and other java objects in a standard way.

    Checkout the early draft and homepage for JSR 223.

    It's interesting that it took the expert group a full year to come up with the Early Review draft.

    Threaded Messages (13)

  2. Difference to JSTL?[ Go to top ]

    Without being able to read the draft (download server was down), I wonder how this is going to differ how the JSTL is the standard way of accessing request/context/application resources. Does it not seem like lately there's a number of JSRs that overlap each other. If the intent is to standardize on how to do something, how does one know from which standard to pick (EJB persistance vs. JDO, JSTL vs. this)? ;)
  3. I just downloaded it fine, try it again.

  4. 中文[ Go to top ]

  5. I could see this being good for allowing better interoperability between nice CMS frameworks, like Zope and Plone, and J2EE backend services. I was sort of disappointed to read that the Zope camp has sort of dropped the ball with regards to connecting to Java classes. To me, a really nice website solution (buzzword bingo!) would have Plone for handling the View in MVC, while tapping into nice backend services implemented in J2EE. It would seem to be the best of both worlds. I honestly don't know if this JSR would be redundant with others, but the need is there, I think.
  6. ok[ Go to top ]

  7. If you take a look you'll see that JSR-223 has become more than just a web scripting interface. It is a general Java scripting language API akin to IBM/Apache BSF, but much more complete. It includes recommended Java language bindings for non Java based languages, a discovery mechanism for engines based on language types, as well as APIs for interacting with script interpreters of varying capabilities and threading models. There are some powerful (and hotly debated) features here such as pluggable namespaces - you can have your app implement a Map and simply plug it in to the namespace of a script interpreter.

    I think people are going to find this very interesting.

    Pat Niemeyer, author of Learning Java, O'Reilly & Associates, the BeanShell Java Scripting Language, and member of the JSR-223 expert group.
  8. Some of the Java scripting languages already have their own
    servlet class. I've skimmed the early draft, but I am not clear
    why JSR223 will also be useful for those language systems, if so.
    If a scripting engine is provided in a separate JAR file,
    it could have its own servlet class in it.

    I was expecting that JSR223 would define PHP-style tags;
    <% %>, <%= %>, <%- %>, etc. I've implemented these kinds
    tags for Pnuts, and found that the most part of the implementation
    was language-neutral.
  9. advantages...[ Go to top ]

    The advantage of the language neutral API and discovery mechanism is that a user could drop in a new language jar and the discovery mechanism would find it and support scripts in that language automatically. From the point of view of web scripting this means that one dispatcher servlet can handle all languages uniformly... And furthermore scripts written in those languages know what to expect in terms of how to access container resources such as the request, session, etc.

    More generally, the general scripting API allows new languages to be supported as scripting / extension languages in any application in the same way. With BSF you could sort of do this, but there was no discovery mechanism... you had to manually register engines and there was no meta-data to help you decide what language mapped to a given script or whether you could support the characteristics of the engine.

    Pat Niemeyer
  10. advantages...[ Go to top ]

    The advantage of the language neutral API and discovery mechanism is that a user could drop in a new language jar and the discovery mechanism would find it and support scripts in that language automatically.
    Clearly this has value beyond server page templating. Eg, Batik. This JSR should be as general as possible.
  11. advantages...[ Go to top ]

    In terms of Web scripting, we can define servlet-mapping in web.xml and don't have to dispatch requests manually, right? Or is it for a page that contains multiple scripting languages? Also, even a single langauge could have multiple templating syntax, each of which would assign a different file name extension. Is it possible to dispatch requests to those pages through JSR 223 API?
  12. JSR223 Feedback[ Go to top ]

    I'm looking for feedback from anyone who has used jsr223.

    Im working at a small company with a number of php developers with a large code base in php, who really dont want to pick up another markup language like JSTL or JSF, and I'm having a hard time convincing them to do so when Java Studio Creator the supposed RAD JSF IDE is so slow, anyone who is using it and doesnt have this experience please let me know what we may be doing wrong (we are using JSC Early Access 2) and compile and redeploy times that take 5-10 minutes or design time redraws in the ide that take 30 seconds to 1 minute are not acceptable for people who are application developers used to worknig with langauges like php. So why dont We just use php, well it doesnt scale well and there are so many apis that are available via java only.
    We also have a heck of a time with sockets in php and the java sockets api works really well and fast for us.

    I've got jsr223 samples working in tomcat 5.5 with php5. I can call a php page from inside of tomcat via a php servlet which is able to access java objects and apis that are on the tomcat web app classpath. ( Which I think is amazing and maybe a great solution for us considering our investments and need for developer productivity).

    Our initial concept was to write the view tier in php, however I feel that this will quickly deteriorate to writing the controller in php as well and I think we may end up using only hibernate for persistence (the model) and axis for web services and Java for other heavy lifting tasks such as socket calls.

    However I have not been able to find any real world feedback on this or any actual examples of anyone setting uop this architecture and the only think I have is a few examples from the jsr site which are more POC examples.

    Anyone with any information please let me know. I have googled the heck out of jsr223 and jsr223 examples and am coming up emtpy handed and am worried tha tthe last time the jsr223 site was updated was may 2005.

    Thanks in advance for any feedback,
  13. I dont understand[ Go to top ]

    I dont understand the purpose of this JSR.

    Are they going to replace JSP with PHP ? Why they wasted so much effort with JSP 2.0 ? Or is this some kind of connectivity between J2EE and PHP ?
  14. I dont understand[ Go to top ]

    Sounds like an integration JSR.

    I haven't looked at the JSR in detail but the idea is a good one. There should be a common way for other scripting languages to be integrated. The benefit is, of course, choice.