Helma with jetty7 and rhino master

[Simon Oberhammer]

Hi Helmauts,
I produced a new Helma, which has Rhino updated to git master (1_7R3pre) & Jetty is now the latest 7 release (7.6.2.v20120308).

The result of both is in my `jetty7` branch:

    https://github.com/oberhamsi/helma-mirror/commits/jetty7

Because of the new native `JSON` object and a couple of `mortbay.StringUtil` dependencies, you must use these updated `modules` with it:

    https://github.com/oberhamsi/apps-modules-mirror/commits/jetty7

Everything seems to work with our applications and our mode of deployment (behind apache with mostly ajp and sometimes http proxying).

With the new Rhino you get the 1.7R3 features and whatever the busy devs did towards R4, so at least those: https://developer.mozilla.org/en/New_in_Rhino_1.7R3 and with jetty7 you get a not-end-of-life webserver ;)

Have a nice day
 Simon

[Simon Oberhammer]

Correction: Rhino 1_7R*4*pre

I pulled it from here last week: https://github.com/mozilla/rhino/commits/master

 Simon

[Tobi Schäfer]

thanks a lot, simon!

i merged your changes into my own helma fork at github and so far my reference app (aka antville) is running fine – at least on my local machine.
:)

i am going to try it out with the test installation (aka a lot of real data), soon and let you know if anything unusual should happen.

btw. i immediately added an empty JSON.js file to modules/core to prevent breaking apps using the obsolete module path.

thinking further, i came to the conclusion that i might be better to check if JSON, the Array extensions etc. are already defined and conditionally define them otherwise. this would keep the modules backwards-compatible… what do you think?

anyway, thanks for the good work, it is very much appreciated.

cheers,
tobi

[Simon Oberhammer]

On Mar 22, 6:47 pm, Tobi Schäfer <interf...@p3k.org> wrote:
> thanks a lot, simon!

Thanks for testing :)

> thinking further, i came to the conclusion that i might be better to
> check if JSON, the Array extensions etc. are already defined
> and conditionally define them otherwise. this would keep the
> modules backwards-compatible

Just so we're talking about the same thing:

we have lots of code using the old `Object.toJSON()` and
`String.parseJSON()`. We don't want to change our application code to
use the new `JSON.*` methods, yet. So to provide backwards
compatibility, `Object.toJSON()` should stay available but it should
use the native `JSON.stringify()`.

The problem is, that `JSON.stringify()` calls `Object.toJSON()`, if
available, to determine an object's JSON representation. Endless loop:

Object.prototype.toJSON = function() {
return JSON.stringify(this);
}

Hannes then mentioned we could use __noSuchMethod__, something like
this:

Object.prototype.__noSuchMethod__ = function(id) {
if (id === 'toJSON') {
return JSON.stringify.apply(JSON, [this].concat(arguments));
}
};

The above works for em. We will use it on our dev machines for a
while. We really want to test/use the new Rhino but we don't want to
fix all our toJSON() calls, yet.

simon