Hi,

I have included the following lib http://www.datejs.com

It works great, except for when I change some code and reload a web page, then Rhino or Helma instance just keeps on running until it times out.  It takes up 180% cpu on my MacBook.  The code runs fine as long as I don't change thing, but as you guys can see this will not work.

Is this a bug in Rhino, Helma or something to do with date.js.  I know that that lib is stil in alpha and it is mostly for clientside, but one thing I like about helma is that I will be able to use clientside js lib on serverside as well.  Please let me know if there are any work around. Thanks.

Julian

Sometimes when I have an object with arrays

I'm doing

if(!session.data.jobulousSurvey.Review.responses) session.data.jobulousSurvey.Review.responses = []

if I uneval.

uneval(session.data.jobulousSurvey.Review.responses)  // this is  end up to be org.mozilla.javascript.NativeArray

1. why is this happening?
2. this doesn't work with session.data.jobulousSurvey.Review.toJSON()

I don't really mind using a mozilla array, as long as I can use toJSON method on it.

Any recommendation or insight as why this is happening?  Is this a bug?

Julian

Hi Julian,

my first guess would have been that the parent scope or prototype of the array are wrong or null, maybe because it has been serialized/deserialized or was created in another scope.

org.mozilla.javascript.NativeArray is indeed the class Rhino uses to implement javascript arrays, but you shouldn't see that when you do an uneval() or toSource().

Hannes

PS the helma mailing list has moved to http://groups.google.com/group/helma - I just haven't managed to turn the switch on the old list yet So I'm cross-posting my answer to the new list.

2008/10/1 Julian Tree <julian.tree <at> gmail.com>

Hi i've come into a series of problems with logging so far when mixing helma and
other libraries around (especially the apache commons). For example i'm using FOP
all the time for render PDF reports, and if you use FOP in debug mode there are chances to
get StackOverflows here and there. So the only way to disable FOP debugging in helma is to
modify the Logging LogFactory class this way.

keep track of a system (but better app.properties) variable that keeps which kind of classes
you need to disable:

    Vector disabledLoggers = new Vector ();
    String disabledClasses = System.getProperty("helma.disablelog", "");

    String[] disabled = disabledClasses.split (":");
    for (int i = 0; i < disabled.length; i++)
    {
        String disableTempClass = disabled[i].trim();
        if (disableTempClass.length () > 0)
            disabledLoggers.add (disableTempClass);
    }

then in public Log getInstance(String logname) we do:

    // normalize log name
    logname = logname.replaceAll("[^\\w\\d\\.]", "");

    for (int i = 0; i < disabledLoggers.size(); i++)
        if (logname.startsWith ((String) disabledLoggers.get (i)))
            return getNoLog();

and getNoLog is like this:

    // static global to the class no logger
    static NoOpLog noLog = new NoOpLog ();

    /**
     * Get a no logger
     * <at> return a logger that writes to Nirvana
     */
    public static Log getNoLog() {
        return noLog;
    }

----------------------------------------------------------------------

Anyway while browsing the Logging code i see the line in constructor:

    logdir = System.getProperty("helma.logdir", "log");

After doing some debugging, "helma.logdir" is set when Server starts from the server.properties logDir
property (if it isn't system wise), but actually server.properties is parsed AFTER the Logging class have
been initialized. So for instance we can have dicrepancies between the actual log directories and the
ones we have specified in the server.properties.


Let me know what u think

ps. Keep up the good work with HelmaNG !!!

Cheers,

Lucio