it can't open the requested log file. Instead it displays an error message
and sees if the file becomes writable. So there's no use in catching the
Exception and getting a Logger to std out/err anymore.
display an error message on standard out, try again and again
to open and write to the log file, and discard queued
log messages and display a warning message every now and then.
- Applied patch From Stefan Pollach that results in better log file rotation
and gzips old log files
- Added sanity checks that re-creates a log file if it has been moved or
deleted
- Added sanity check that closes a logger that can't write to its file.
- Added some method for real time introspection of logging system
Todo: Decide what should happen when a Logger can't write to its file.
"build package" now works in helma/work-directory only.
added targets "build snapshot" and "build snapshotcompile" to build helma.jar
added target "build helmadocs" to download documentation from helma.org.
- definition of root class is moved from app.properties to class.properties file.
- optional use of fields "root.factory.class" and "root.factory.method" in class.properties to retrieve an instance of the root object.
This was caused by lastParentSet not being set not being updated
in the setParent() method called from JavaScript, so if it hadn't already been
set before, getParent would still do its whole parent evaluation
work, overwriting the previously set parent.
Fixed bug 68: _extends does not allow additional property mappings
The problem was that the standard (parent) prototype mapping was alweys
used to initialize new Nodes from a SQL result set in the relational Node
constructor. The right sub-prototype was determined at the beginning,
but since both the method parameter and the class fields were called dbmap,
the local parameter was used for initializing the node's properties.
server field will never be assigned the Server object (because
the Server constructor never returns, because the calling thread
ends up in the loop checking for updates in apps.properties).
which can contain one singel directoy in which to look for skins.
The skin resolution looks like this now:
1) res.skinpath (directory)
2) nodemanagers (internal HopObjects marked as skinmanagers)
3) application directory
href() and renderSkin() functions, without all the other functions in
Helma objectmodel Nodes that don't apply to Java objects. This
was a problem because it "covered" methods in the Java objects
with the same name, e.g. list(), delete() etc.
