Nabble - Helma - Dev

[Bug 701] URL encoded + get lost

2009-12-17T05:25:36Z

http://dev.helma.org/bugs/show_bug.cgi?id=701

--- Comment #2 from Hannes Wallnoefer <hannes@...> 2009-12-17 14:25:36 ---
Unfortunately, Apache Commons Codec behaves just like
java.net.URLEncoder/Decoder in always escaping space as "+". The only Java URL
encoder/decoder library i could find that lets you define how to treat spaces
is the one in the Google Data API:

http://code.google.com/p/gdata-java-client/source/browse/trunk/java/src/com/google/gdata/util/common/base/PercentEscaper.java

The license is Apache 2, so the only thing preventing us from grabbing the code
would be too much dependencies.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 701] URL encoded + get lost

2009-12-17T04:40:00Z

http://dev.helma.org/bugs/show_bug.cgi?id=701

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |hannes@...

--- Comment #1 from Hannes Wallnoefer <hannes@...> 2009-12-17 13:40:00 ---
I just tested helma with mod_proxy (both via http and ajp protocols) and found
that mod_proxy _only_ decodes "%2B" to "+" - all other "%xx" sequences are
passed through.

As it is, the only possible workaround I see for this is not to ever use '+'
for encoding of space characters. It might be worth to report this on
issues.apache.org.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 701] New: URL encoded + get lost

2009-12-17T02:04:33Z

http://dev.helma.org/bugs/show_bug.cgi?id=701

Summary: URL encoded + get lost
Product: Helma
Version: 1.6.4
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P3
Component: Web Support
AssignedTo: helma-dev@...
ReportedBy: marius.lessiak@...

If you use an encoded + in a URL it gets decoded to a space by helma. Try
loading http://helma.org/%2B%2B%2Bplusgetslost and you will see it in the
notfound message. Supposedly this originates in a double decoding done by the
AJP13 connector (i.e. mod_jk) which decodes the %2b to + and helma further
decodes the + to an empty space. The later behaviour stems from helmas way of
dealing with spaces in an accessname of an hopobject: they get converted to a +
when using hopobject.href() to generate its link (javascript for example
encodes a space to %20). a workaround for this problem using mod_jk is to use
the options described at
http://tomcat.apache.org/connectors-doc/reference/apache.html . for example
ForwardURIEscaped or ForwardURICompatUnparsed but beware that this may breakt
apache url rewriting.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

unsubscribe

2009-12-08T07:00:45Z

Cheers,
Tim

--
Tim McLaughlin
President, Siteworx
703-657-1225

----- Original Message -----
From: bugzilla-daemon@...
To: helma-dev@...
Sent: Tuesday, December 8, 2009 9:34:56 AM GMT -05:00 US/Canada Eastern
Subject: [Helma-dev] [Bug 700] helma.File's readln() not working

http://dev.helma.org/bugs/show_bug.cgi?id=700

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |INVALID

--- Comment #1 from Hannes Wallnoefer <hannes@...> 2009-12-08 15:34:55 ---
You need to open() the file before calling readln(). This is true for most
methods that operate on file content, with the exception of readAll() which
includes the calls to open() and close().

This is all the fault of the prehistoric error reporting mechanism in
helma.File (calling setError() instead of throwing the error). I wanted to fix
that a long time ago, but it slipped off my radar at some point. We should
probably fix this in Helma 1.7.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 700] helma.File's readln() not working

2009-12-08T06:34:56Z

http://dev.helma.org/bugs/show_bug.cgi?id=700

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |INVALID

--- Comment #1 from Hannes Wallnoefer <hannes@...> 2009-12-08 15:34:55 ---
You need to open() the file before calling readln(). This is true for most
methods that operate on file content, with the exception of readAll() which
includes the calls to open() and close().

This is all the fault of the prehistoric error reporting mechanism in
helma.File (calling setError() instead of throwing the error). I wanted to fix
that a long time ago, but it slipped off my radar at some point. We should
probably fix this in Helma 1.7.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 700] New: helma.File's readln() not working

2009-12-07T02:50:58Z

http://dev.helma.org/bugs/show_bug.cgi?id=700

Summary: helma.File's readln() not working
Product: Helma
Version: 1.7.0
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: helmaLib, helmaTools
AssignedTo: helma-dev@...
ReportedBy: philipp.naderer@...

I tried to read a file line by line but it seems like the readln() function is
broken.

Tested on Mac OS X and Windows XP.

testfile.txt:
http://google.com
http://orf.at
http://tenez.at
http://tuwien.ac.at

Test-Action:
Root.prototype.testReadLine_action = function() {
res.contentType = "text/plain";

var file = new helma.File("D:/testfile.txt");
var line;
do {
line = file.readln();
res.write("Line: " + line);
} while(line);
res.write("\n--- Read All ---\n");
res.write(file.readAll());
};

Output:
Line: null
--- Read All ---
http://google.com
http://orf.at
http://tenez.at
http://tuwien.ac.at

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 699] New: deserialize() throws exception for serialized() function

2009-12-01T05:11:37Z

http://dev.helma.org/bugs/show_bug.cgi?id=699

Summary: deserialize() throws exception for serialized()
function
Product: Helma
Version: CVS trunk
Platform: Other
OS/Version: Macintosh
Status: NEW
Severity: normal
Priority: P5
Component: JavaScript Interpreter
AssignedTo: helma-dev@...
ReportedBy: interface@...

It is no problem to export a JavaScript function with serialize():

serialize(function() {return 1}, "test.txt");

However, trying to re-import the serialized data fails:

deserialize("test.txt");

helma.scripting.ScriptingException: Wrapped java.lang.ClassNotFoundException:
org.mozilla.javascript.gen.c478
(/Users/tobi/Projects/helma/./apps/antville/dev/Global/debug.js#23)
helma.scripting.ScriptingException: Wrapped java.lang.ClassNotFoundException:
org.mozilla.javascript.gen.c478
(/Users/tobi/Projects/helma/./apps/antville/dev/Global/debug.js#23)
at /Users/tobi/Projects/helma/./apps/antville/dev/Global/debug.js:23
Full trace: org.mozilla.javascript.WrappedException: Wrapped
java.lang.ClassNotFoundException: org.mozilla.javascript.gen.c478
(/Users/tobi/Projects/helma/./apps/antville/dev/Global/debug.js#23)
at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1773)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:183)
at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:413)
at org.mozilla.javascript.optimizer.OptRuntime.callName(OptRuntime.java:97)
at
org.mozilla.javascript.gen.c478._c4(/Users/tobi/Projects/helma/./apps/antville/dev/Global/debug.js:23)
at
org.mozilla.javascript.gen.c478.call(/Users/tobi/Projects/helma/./apps/antville/dev/Global/debug.js)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:398)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3065)
at
org.mozilla.javascript.gen.c478.call(/Users/tobi/Projects/helma/./apps/antville/dev/Global/debug.js)
at org.mozilla.javascript.Context$1.run(Context.java:504)
at org.mozilla.javascript.Context.call(Context.java:515)
at org.mozilla.javascript.Context.call(Context.java:502)
at helma.scripting.rhino.RhinoEngine.invoke(RhinoEngine.java:316)
at helma.framework.core.RequestEvaluator.run(RequestEvaluator.java:414)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.ClassNotFoundException: org.mozilla.javascript.gen.c478
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at java.lang.ClassLoader.loadClass(ClassLoader.java:254)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:399)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604)
at
org.mozilla.javascript.serialize.ScriptableInputStream.resolveClass(ScriptableInputStream.java:90)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at helma.scripting.rhino.GlobalObject.deserialize(GlobalObject.java:647)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:161)
... 13 more

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 690] String.isUrl() allows invalid URLs

2009-12-01T03:06:56Z

http://dev.helma.org/bugs/show_bug.cgi?id=690

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |FIXED
Target Milestone|--- |1.7.0

--- Comment #5 from Hannes Wallnoefer <hannes@...> 2009-12-01 12:06:56 ---
Fixed in revision 10003. I updated the regexps to the ones from Antville trunk
and removed the java.net.URL code from isUrl().

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 690] String.isUrl() allows invalid URLs

2009-11-28T12:57:32Z

http://dev.helma.org/bugs/show_bug.cgi?id=690

--- Comment #4 from Philipp <philipp.naderer@...> 2009-11-28 21:57:31 ---
The Apache Commons Validator package also ships a JavaScript implementation.
This can be found under commons-validator-1.3.1.js in the download package.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 697] Changes from 4 Nov 2009 break one of my apps completely

2009-11-26T05:42:55Z

http://dev.helma.org/bugs/show_bug.cgi?id=697

--- Comment #2 from tobi <interface@...> 2009-11-26 14:42:55 ---
(In reply to comment #1)
> That's kind of strange, because the changes I made on that day don't look
> particularly risky. Could you try again with an up-to-date snapshot (revision
> 9994)?
>
> If the problem persists I guess I'll have to add some debugging output to get
> the stack trace from exceptions caught in macro evaluation.

Tried it with SVN snapshot from today (rev 9998) and still no luck.
:(

Will dig deeper into the issue when I got the time again.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 675] Add support for onBeforeCommit, onCommit and onAfterCommit

2009-11-25T13:34:49Z

http://dev.helma.org/bugs/show_bug.cgi?id=675

--- Comment #8 from Maksim Lin <maksim.lin@...> 2009-11-25 22:34:49 ---
I would be very happy with that Hannes.
onAfterCommit() would cover use cases like the one I mentioned, as it would
allow you to write actions that happenafter a successfully DB commit.
While onBeforeCommit() would allow you to write code that does checks of the
data about to be committed (eg. special validation) that could then abort the
transaction before the DB commit takes place.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 698] Creating a java.security.MessageDigest from a Date object returns different results in versions 1.5 and 6 of Java

2009-11-25T11:57:33Z

http://dev.helma.org/bugs/show_bug.cgi?id=698

--- Comment #3 from tobi <interface@...> 2009-11-25 20:57:33 ---
One more question just out of pure curiousity, and as I am totally blank about
the idea behind a localized time zone in an otherwise un-localized date string:

Thu Jan 01 1970 01:00:00 GMT+0100 (MEZ)

We have Thu for Thursday but MEZ for Mitteleuropäische Zeit... Looks a little
bit whimsical to me; is there any pointer on what the Java folks were up to?

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 698] Creating a java.security.MessageDigest from a Date object returns different results in versions 1.5 and 6 of Java

2009-11-25T10:07:07Z

http://dev.helma.org/bugs/show_bug.cgi?id=698

--- Comment #2 from tobi <interface@...> 2009-11-25 19:07:07 ---
Oh, I did not know that; thanks for the information.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 698] Creating a java.security.MessageDigest from a Date object returns different results in versions 1.5 and 6 of Java

2009-11-25T09:54:36Z

http://dev.helma.org/bugs/show_bug.cgi?id=698

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |INVALID

--- Comment #1 from Hannes Wallnoefer <hannes@...> 2009-11-25 18:54:36 ---
This is because Java 6 renders the timezone as localized string (probably
"MEZ") while Java 5 always uses English timezone names (e.g. "CET").

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 698] New: Creating a java.security.MessageDigest from a Date object returns different results in versions 1.5 and 6 of Java

2009-11-25T09:40:46Z

http://dev.helma.org/bugs/show_bug.cgi?id=698

Summary: Creating a java.security.MessageDigest from a Date
object returns different results in versions 1.5 and 6
of Java
Product: Helma
Version: CVS trunk
Platform: Other
OS/Version: Macintosh
Status: NEW
Severity: normal
Priority: P5
Component: JavaScript Interpreter
AssignedTo: helma-dev@...
ReportedBy: interface@...

The following code returns different results when run in different Java
versions:

var d = new Date(0); // Thu Jan 01 1970 01:00:00 GMT+0100 (CET)
var hash = java.security.MessageDigest.getInstance("SHA-1");
hash.update(java.lang.String(d).getBytes());
var s = java.lang.String(hash.digest()).enbase64()
res.debug(s)

In Java 1.5 I get:

XSHvv73vv73vv71n77+977+9de+/vUZG77+977+9JdSTAO+/vXc=

And in Java 6:

au+/vWrvv73vv71nO1Dvv70V77+9LAN2Vu+/vdCO77+9KA==

This happens only with date objects – strings, numbers, arrays and plain
objects are fine as far as I can tell.

(Note: I only did the call for the enbase64 method to better show the
differences; the actual digests are different, too. Thus, it should not be
related to the sun.misc.BASE64Encoder package that is viciously used in the
String module.)

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 675] Add support for onBeforeCommit, onCommit and onAfterCommit

2009-11-25T06:40:28Z

http://dev.helma.org/bugs/show_bug.cgi?id=675

--- Comment #7 from Hannes Wallnoefer <hannes@...> 2009-11-25 15:40:27 ---
I think this would be easier to agree on if there was just the one onCommit
callback, or maybe two - onBeforeCommit and onAfterCommit, both called with the
inserted/updated/deleted nodes as arguments. What do you think?

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 696] log level display is not settable via app.properties

2009-11-25T02:58:33Z

http://dev.helma.org/bugs/show_bug.cgi?id=696

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |FIXED

--- Comment #2 from Hannes Wallnoefer <hannes@...> 2009-11-25 11:58:33 ---
There was a buglet where debug logging level wasn't unset if the debug property
was set to false during runtime. This is fixed in revision 9995.

Note that setting log levels via debug property only works when using helma's
own (default) logger implementation. It doesn't work with other logging
implementations as commons-logging doesn't provide an interface for setting log
levels.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 697] Changes from 4 Nov 2009 break one of my apps completely

2009-11-25T02:37:41Z

http://dev.helma.org/bugs/show_bug.cgi?id=697

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |hannes@...

--- Comment #1 from Hannes Wallnoefer <hannes@...> 2009-11-25 11:37:41 ---
That's kind of strange, because the changes I made on that day don't look
particularly risky. Could you try again with an up-to-date snapshot (revision
9994)?

If the problem persists I guess I'll have to add some debugging output to get
the stack trace from exceptions caught in macro evaluation.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 697] Changes from 4 Nov 2009 break one of my apps completely

2009-11-24T10:23:50Z

http://dev.helma.org/bugs/show_bug.cgi?id=697

tobi <interface@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.7.0
OS/Version|All |Macintosh
Severity|enhancement |normal

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 697] New: Changes from 4 Nov 2009 break one of my apps completely

2009-11-24T10:23:07Z

http://dev.helma.org/bugs/show_bug.cgi?id=697

Summary: Changes from 4 Nov 2009 break one of my apps
completely
Product: Helma
Version: CVS trunk
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: Database Layer
AssignedTo: helma-dev@...
ReportedBy: interface@...

If I try to run one of my apps with a Helma snapshot as of 5 November or later
I get a [Macro Error: Error retrieving Node] due to a NPE.

The application works flawlessly with earlier snapshots reaching back to
December 2008.

As the app makes heavy use of inheritance (_extends property) and other Helma
extravaganza it is quite hard to track down the problem.

However, I noticed that there is a strange SQL query that could be related to
the problem:

SELECT base.* FROM base WHERE base.id = null

Of course, this does not look really good from the point of view of the
application development; however, this query appears in both cases, with a
pre-Nov-4 and a post-Nov-4 Helma.

I will try to track down the issue as far as I can but already wanted to make
notice of this behaviour – would be thankful for any suggestions how I could
isolate this thing.

One suspicion I have right now: Could it be that changeset:9981 [1] probably
should not be applied to mountpoints – as they are virtual but indeed should
prefetch their child nodes?

--
[1] http://dev.helma.org/trac/helma/changeset/9981

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 696] log level display is not settable via app.properties

2009-11-23T04:54:38Z

http://dev.helma.org/bugs/show_bug.cgi?id=696

--- Comment #1 from Marius Lessiak <marius.lessiak@...> 2009-11-23 13:54:38 ---
Created an attachment (id=129)
--> (http://dev.helma.org/bugs/attachment.cgi?id=129)
Sample App to reproduce bug

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 696] New: log level display is not settable via app.properties

2009-11-23T04:52:41Z

http://dev.helma.org/bugs/show_bug.cgi?id=696

Summary: log level display is not settable via app.properties
Product: Helma
Version: CVS trunk
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Generic/Other
AssignedTo: helma-dev@...
ReportedBy: marius.lessiak@...

I have some strange behaviour with log output of level DEBUG and the current
trunk (revision 9990) of helma: With the main application I am developing I get
no log output via app.logger.debug although I start the application with
debug=true in app.properties. When changing anything inside the app.properties
DEBUG level messages logged via app.logger.debug start to appear. Then I can
not turn them of via setting debug=false.

Following up on this using an empty test application (see attached archive) I
get a slightly different behaviour: Messages logged via app.logger.debug always
appear even if debug=false is set.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 690] String.isUrl() allows invalid URLs

2009-11-22T00:50:42Z

http://dev.helma.org/bugs/show_bug.cgi?id=690

--- Comment #3 from Philipp <philipp.naderer@...> 2009-11-22 09:50:42 ---
Apache Commons provides a validator for URL and E-Mail. This would be a quick
and clean fix for both.

http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/package-summary.html#package_description

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 695] new method that uses PreparedStatement in helma.Database

2009-11-18T15:35:24Z

http://dev.helma.org/bugs/show_bug.cgi?id=695

--- Comment #1 from Maksim Lin <maksim.lin@...> 2009-11-19 00:35:24 ---
Created an attachment (id=128)
--> (http://dev.helma.org/bugs/attachment.cgi?id=128)
Implementation of prepared query method

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 695] New: new method that uses PreparedStatement in helma.Database

2009-11-18T15:33:30Z

http://dev.helma.org/bugs/show_bug.cgi?id=695

Summary: new method that uses PreparedStatement in
helma.Database
Product: Helma
Version: CVS trunk
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P5
Component: helmaLib, helmaTools
AssignedTo: helma-dev@...
ReportedBy: maksim.lin@...

As mentioned in this mail list thread:
http://groups.google.com.au/group/helma/browse_thread/thread/afc1a6897ce66565

I've written an addition to helma.Database that provides a method that use jdbc
PreparedStatements. Its essentially a copy of executeQuery, so maybe should be
factored out of btoh into a seperate private funciton that both methods
delegate to?

I've attached the implementation as a seperate file that can just be added into
an app via addRepository() but it could easily be copy/pasted into the current
helma.Database.js

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 675] Add support for onBeforeCommit, onCommit and onAfterCommit

2009-11-18T14:50:13Z

http://dev.helma.org/bugs/show_bug.cgi?id=675

Maksim Lin <maksim.lin@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |maksim.lin@...

--- Comment #6 from Maksim Lin <maksim.lin@...> 2009-11-18 23:50:13 ---
I'm concerned about impact on performance too.
On the other hand I'd would be nice to have as a simple way of for instance
handling updating a FT index (eg. lucene) right after a successful commit into
the DB. But from the described changes I don't think this would work as
onAfterCommit would not be passed the relevant params ?

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 682] Provide a method for reading the content of an HTTP request for any content type

2009-11-18T00:07:27Z

http://dev.helma.org/bugs/show_bug.cgi?id=682

--- Comment #5 from Hannes Wallnoefer <hannes@...> 2009-11-18 09:07:26 ---
(Mit Bezug zu comment #4)
> Hannes, what is the reason for the WONTFIX?

I don't have a lot of time, and there are simple workarounds (listed in the
comments above, with ~ 4 lines of code).

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 682] Provide a method for reading the content of an HTTP request for any content type

2009-11-17T23:52:01Z

http://dev.helma.org/bugs/show_bug.cgi?id=682

--- Comment #4 from tobi <interface@...> 2009-11-18 08:52:01 ---
Hannes, what is the reason for the WONTFIX?

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 616] Problem with accessing mountpoint methods from another application

2009-11-17T02:18:31Z

http://dev.helma.org/bugs/show_bug.cgi?id=616

Bug 616 depends on bug 684, which changed state.

Bug 684 Summary: Application.dataRoot is not set anymore
http://dev.helma.org/bugs/show_bug.cgi?id=684

What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 684] Application.dataRoot is not set anymore

2009-11-17T02:18:31Z

http://dev.helma.org/bugs/show_bug.cgi?id=684

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #6 from Hannes Wallnoefer <hannes@...> 2009-11-17 11:18:31 ---
Closing as fixed. I'm not going to rename getDataRoot() after all, it just
ain't worth it.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 682] Provide a method for reading the content of an HTTP request for any content type

2009-11-17T02:16:59Z

http://dev.helma.org/bugs/show_bug.cgi?id=682

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX

--- Comment #3 from Hannes Wallnoefer <hannes@...> 2009-11-17 11:16:59 ---
Closing as wontfix.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 680] How do I render req.data["foo.bar"] as a macro?

2009-11-17T02:14:34Z

http://dev.helma.org/bugs/show_bug.cgi?id=680

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |WONTFIX

--- Comment #1 from Hannes Wallnoefer <hannes@...> 2009-11-17 11:14:34 ---
I'm afraid there is no way to render parameters with dots in the name. The best
solution is probably to define some generic getter macro. Closing as wontfix.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 675] Add support for onBeforeCommit, onCommit and onAfterCommit

2009-11-17T02:09:42Z

http://dev.helma.org/bugs/show_bug.cgi?id=675

--- Comment #5 from Hannes Wallnoefer <hannes@...> 2009-11-17 11:09:41 ---
I'm a bit ambivalent on adding not one, but three hooks on each commit. Have
you looked at how this affects performance with and without the hooks defined?
We're calling (or trying to call) the hooks on every request, after all.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 309] A Collection of objects of an extended prototype shows also all base prototype objects

2009-11-17T01:59:00Z

http://dev.helma.org/bugs/show_bug.cgi?id=309

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |FIXED

--- Comment #4 from Hannes Wallnoefer <hannes@...> 2009-11-17 10:58:59 ---
Should be fixed with the patch for #468

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 681] new "DISTINCT" based SQL for grouping causes an error with H2

2009-11-17T01:46:16Z

http://dev.helma.org/bugs/show_bug.cgi?id=681

Hannes Wallnoefer <hannes@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hannes@...
Resolution| |WONTFIX

--- Comment #1 from Hannes Wallnoefer <hannes@...> 2009-11-17 10:46:15 ---
As discussed on the mailing list, this is not a bug - H2 can't sort a grouped
select by a column that may have multiple values for each group.

http://groups.google.com/group/helma/tree/browse_frm/thread/64ded1b15172a797/138775b8cbf03d9e?rnum=1&_done=%2Fgroup%2Fhelma%2Fbrowse_frm%2Fthread%2F64ded1b15172a797%3F#doc_5787ef09f38f780e

Closing as wontfix.

--
Configure bugmail: http://dev.helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev