Hopbot log for 2009-12-01 - Helma IRC channel: #helma on irc.freenode.net

2009-12-01:

[8:05] <hannesw> bon jour
[8:16] <hannesw> simono: could you give me some demo data to use as arguments for createTable() in jala.Database?
[8:16] <hannesw> That would make it easier for me to debug this alone, and you won't have to provide a full demo app
[8:16] <hannesw> :)
[8:16] <hannesw> just a table with a few columns will do (so I don't have to figure this out)
[8:22] <hannesw> ok, starting to figure out myself :)
[8:40] <hannesw> simono (when you're back from meeting or whatever :)
[8:40] <hannesw> I can't trigger the bug with this simple code:
[8:40] <hannesw> http://helma.pastebin.com/m729b549e
[8:41] <hannesw> can you check what you do different/in addition to trigger it?
[9:33] <simono> will do.. probably after noon, busy morning
[9:33] <hannesw> yo, no problem
[9:34] <hannesw> I'll let you know if i figure it out myself
[9:34] <simono> ok, i'll try to at least get demo data out of our app now
[9:39] <simono> i updated your paste with createTable info that triggers the problem for me http://helma.pastebin.com/f46e5a79e
[9:39] <hannesw> thanks!
[9:39] <simono> never looked at it.. very verbous.. this is how oracle returns the metadata and we just forward it
[10:01] <hannesw> simono: no luck, still can't reproduce this
[10:19] <triotex> buna dimineata! good morning!
[10:20] <triotex> last week we had to fix a xss hole which was based on bug 690 - email & url validation. so i just want to asked if this will be fixed in 1.7 or not.
[10:20] <triotex> because if not, we have to use our own validators: http://code.google.com/p/tenez/source/browse/trunk/apps/base/Global/tenez.FormSecurity.js#90
[10:21] <triotex> maybe anyone here (hannes?) might answer that question.
[10:26] <hannesw> triotex: good morning
[10:26] <hannesw> I'd like to fix this.
[10:27] <hannesw> using the js version of apache commons validator seems like the best solution to me
[10:27] <hannesw> what do you think?
[10:27] <hannesw> (haven't looked at the code yet, but assuming it's not too terrible)
[10:27] <hannesw> we could just copy-past that code into ours (apache license isn't a problem)
[10:28] <triotex> but commons need two additional jars in the classpath. that's the problem.
[10:29] <hannesw> what, the js version isn't standalone?
[10:29] <triotex> oh the js version is ;)
[10:29] <triotex> sorry for the confusion
[10:30] <hannesw> ok. my plan would be to just use the code from the js version
[10:30] <triotex> we used the java-version in our code to show how to access java-stuff from helma
[10:30] <hannesw> I'm looking at it now
[10:33] <hannesw> still clueless what to do about String.URLPATTERN
[10:33] <hannesw> should be removed, but there may be code depending on it.
[10:36] <hannesw> Oh, ok - commons validator doesn't have URL validation in the .js file
[10:36] <hannesw> only Email (and a bunch of other stuff)
[10:36] <hannesw> so plan b: regexp from antville trunk
[10:39] <triotex> the two are taken from the jQuery Validation guy, so it should be proofed code
[10:39] <hannesw> yep
[10:40] <triotex> but it will accept only http/https/ftp urls
[10:40] <hannesw> triotex: I assume the java.net.URL/exception code should be kicked - only use regexp, right?
[10:41] <triotex> jep. because if i remember it does return the exeption instead of true or false
[10:42] <hannesw> it returns the java.net.URL object. but that's easy to fix.
[10:42] <simono> hannesw: i will try a newer h2, what version do you have?
[10:42] <hannesw> but the problem is java.net.URL may be able to parse even if it's not a valid URL
[10:42] <hannesw> simono: whatever is in helma svn
[10:42] <hannesw> so only relying on the regexp will give stricter/better results IMO
[10:43] <hannesw> I'm trying now with helma-ng, will backport to helma1
[10:43] <hannesw> (doing helma-ng first so i can actually test stuff without writing apps :)
[10:48] <simono> h2.jar doesnt ship with jala nor helma, just checked.. but my version is from last year, trying new one nwo
[10:55] <hannesw> simono: sorry, my bad
[10:55] <hannesw> i have h2-1.1.118.jar in lib/ext
[10:56] <hannesw> triotex: pushed fix to helma-ng: http://github.com/hns/helma-ng/commit/cf5297f5eb86edf0bfca170cb3ed28dc84b969f6
[10:56] <hannesw> seems to be working fine (http://<foo>bar no longer is a avalid URL)
[11:07] <hannesw> triotex: fix is in svn
[11:07] <hannesw> http://dev.helma.org/trac/helma/changeset/10003
[11:18] <triotex> oh nice!
[11:51] <simono> hannesw: the problem was that the test-db had the same name as the real db source
[11:52] <hannesw> oh, ok. and it worked before, right?
[11:52] <simono> yes it did
[11:52] <simono> before = 20 revisions ago
[11:53] <hannesw> yes, quite clear. before we used the properties object as hash key, now we're using the dbsource name
[11:54] <hannesw> will try to make it work again - after the lasagne al forno :)
[11:54] <simono> mahlzeit! :)
[11:54] <hannesw> tx :)
[12:29] <simono> i'll now write a demo-app for another problem i have. i also tell you know, in case it's obvious to you:
[12:31] <simono> i have a grouped collection with generic filters (local.1 = $id, etc).
[12:32] <simono> within one request: i remove objectA from the collection and after that i add objectB to the same collection (they both end up in the same group, i'm not sure yet this matters)
[12:33] <simono> at the end of that request i still find both, objectA and objectB, in the collection
[12:33] <simono> subsequent request correctly return only objectB
[12:34] <simono> the problem does not appear when i re-order the add and remove. so: first add objectB, THEN remove objectA and everything is fine
[13:38] <hannesw_> simono: I'd have to check the test suite
[13:38] <hannesw_> may or may not be a known issue
[13:59] <simono> ok. also i think this never worked but we only recently noticed
[14:57] <daniel> Hi all. As I have been away for a while and I am going to ask a question now (i.e. take) I'll start off with giving something ;-)
[14:58] <daniel> I have just finished a quite huge Helma application where the Helma application contrary to the usual case does not generate any frontend, but does solely deliver data to a Adobe Flex application. Adobe is in favour of it's own binary AMF3 protocol. You can find the serializer / de-serializer for JS/Helma, some server-side as well as client-side utilities (lets call it Chopper for Flex) in the SVN here: http://www.sf.net/projects/w
[14:58] <daniel> There is a demo application for Helma as well as Flex in the SVN repository as well. I will compile a release file when I have time.
[15:00] <daniel> Now the question part :-) Hannes, I am about to replace the mentioned huge Helma / Flex application with a more typical Helma web application (i.e. HTML/JS). Due to the size of the application I will need more than one Helma server which I would like to keep in sync with HelmaSwarm.
[15:00] <daniel> Is there a way to configure HelmaSwarm to act synchronously rather than asynchronously?
[15:12] <oberhamsi> hi the sf.net link is broken :)
[15:13] <daniel> are you sure? it does work fine for me.
[15:16] <oberhamsi> hm, no it's broken in my client and the transcript doesnt like it either http://helma.zumbrunn.com/hopbot/
[15:16] <oberhamsi> re helmaswarm.. we use it, but no idea about sync. isn't tcp async good enough?
[15:25] <daniel> indeed, part of the url was gone. lets blaim it on the web irc client ;-)
[15:26] <daniel> project is called warpfx on sf.net
[15:27] <daniel> helmaswarm: when i said sync i wasn't talking that low in the protocol stack. i meant sync in the sense of a Helma action does not complete and send the output to the client before not all the other swarm members have been updated
[15:28] <daniel> i haven't yet looked into the source code of helmaswarm, i was just wondering if something like that is in there before i start to invent something to get the desired result.
[15:31] <daniel> i would probably prefer it the other way around though: new requests to other swarm members are blocked until the swarm has a consistent state.
[17:30] <emilis_info> http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-javascript-on-path-for-world-domination.ars

 

 

In the channel now:

Logs by date: