From guillaume.deflache at wyona.com Tue Dec 1 12:01:09 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Tue Dec 1 12:07:31 2009 Subject: timeline (was: Re: [Yanel-dev] AllowEncodedSlashes Apache httpd reverse proxy) In-Reply-To: <4B144A8B.3060600@wyona.com> References: <4B144A8B.3060600@wyona.com> Message-ID: <4B14F775.4090306@wyona.com> Michael Wechner schrieb: > Hi Hi! > I have finally figured out how Apache httpd forwards %-encoded slashes: > > http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6849 Nice, now we really know what it was all about, thanks! :) > whereas because of this fix now our Simile Timelines work nicely, e.g. > > http://www.yanel.org/roadmap-timeline.html > > or > > http://www.wyonapictures.com/en/asf/a-brief-history-of-the-asf/timeline.html Yanel's one still looks pretty (well, completely) empty to me compared to ASF's. Do I need Flash for this? If yes, then how come ASF's does not? Cheers, Guillaume From michael.wechner at wyona.com Tue Dec 1 13:57:40 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 1 14:07:01 2009 Subject: [Yanel-dev] Re: timeline In-Reply-To: <4B14F775.4090306@wyona.com> References: <4B144A8B.3060600@wyona.com> <4B14F775.4090306@wyona.com> Message-ID: <4B1512C4.8000701@wyona.com> Guillaume D?flache wrote: >> whereas because of this fix now our Simile Timelines work nicely, e.g. >> >> http://www.yanel.org/roadmap-timeline.html >> >> or >> >> http://www.wyonapictures.com/en/asf/a-brief-history-of-the-asf/timeline.html > > > Yanel's one still looks pretty (well, completely) empty to me compared > to ASF's. did you pan to previous months/years? (also see the lower band for the little blue specs which indicate the "events") > > Do I need Flash for this? If yes, then how come ASF's does not? no Flash required. Why do you ask? Thanks Michi > > Cheers, > Guillaume From michael.wechner at wyona.com Tue Dec 1 15:23:04 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 1 15:32:45 2009 Subject: [Yanel-dev] Re: timeline In-Reply-To: <4B14F775.4090306@wyona.com> References: <4B144A8B.3060600@wyona.com> <4B14F775.4090306@wyona.com> Message-ID: <4B1526C8.7000305@wyona.com> Guillaume D?flache wrote: >> whereas because of this fix now our Simile Timelines work nicely, e.g. >> >> http://www.yanel.org/roadmap-timeline.html >> >> or >> >> http://www.wyonapictures.com/en/asf/a-brief-history-of-the-asf/timeline.html > > > Yanel's one still looks pretty (well, completely) empty to me compared > to ASF's. > > Do I need Flash for this? If yes, then how come ASF's does not? I think the problem is the date/locale. I have added a date by hand now. Can you give it another try? Thanks Michi > > Cheers, > Guillaume From guillaume.deflache at wyona.com Tue Dec 1 15:36:16 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Tue Dec 1 15:42:38 2009 Subject: [Yanel-dev] Re: timeline In-Reply-To: <4B1512C4.8000701@wyona.com> References: <4B144A8B.3060600@wyona.com> <4B14F775.4090306@wyona.com> <4B1512C4.8000701@wyona.com> Message-ID: <4B1529E0.5090308@wyona.com> Michael Wechner schrieb: > Guillaume D?flache wrote: >>> whereas because of this fix now our Simile Timelines work nicely, e.g. >>> >>> http://www.yanel.org/roadmap-timeline.html >>> >>> or >>> >>> http://www.wyonapictures.com/en/asf/a-brief-history-of-the-asf/timeline.html >> >> >> >> Yanel's one still looks pretty (well, completely) empty to me compared >> to ASF's. > > did you pan to previous months/years? (also see the lower band for the > little blue specs which indicate the "events") I could not, the timeline box was empty apart from the vertical "Timeline (C) SIMILE" text at the bottom left. >> Do I need Flash for this? If yes, then how come ASF's does not? > > no Flash required. Why do you ask? Because I had no clue and do not have Flash installed! ;) From guillaume.deflache at wyona.com Tue Dec 1 15:38:14 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Tue Dec 1 15:47:45 2009 Subject: [Yanel-dev] Re: timeline In-Reply-To: <4B1526C8.7000305@wyona.com> References: <4B144A8B.3060600@wyona.com> <4B14F775.4090306@wyona.com> <4B1526C8.7000305@wyona.com> Message-ID: <4B152A56.5010205@wyona.com> Michael Wechner schrieb: > Guillaume D?flache wrote: >>> whereas because of this fix now our Simile Timelines work nicely, e.g. >>> >>> http://www.yanel.org/roadmap-timeline.html >>> >>> or >>> >>> http://www.wyonapictures.com/en/asf/a-brief-history-of-the-asf/timeline.html >> >> >> >> Yanel's one still looks pretty (well, completely) empty to me compared >> to ASF's. >> >> Do I need Flash for this? If yes, then how come ASF's does not? > > I think the problem is the date/locale. I have added a date by hand now. > > Can you give it another try? This works for me now, thanks! :) From guillaume.deflache at wyona.com Tue Dec 1 16:46:44 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Tue Dec 1 16:53:14 2009 Subject: [Yanel-dev] Re: [Yanel-commits] Build failed in Hudson: Yanel-trunk #476 In-Reply-To: <17333230.2271259680775110.JavaMail.guillaume@wc-13.wyona.com> References: <17333230.2271259680775110.JavaMail.guillaume@wc-13.wyona.com> Message-ID: <4B153A64.4090309@wyona.com> hudson@wyona.com schrieb: > See http://195.226.6.72:8080/job/Yanel-trunk/476/changes > [...] Unfortunately Hudson cannot point us to the Canoo result page where the error is, because there are several reports (one per tested realm) and Hudson only supports linking to one. Al least the first line of a selection of the last log traces below tells us where to look: http://195.226.6.72:8080/job/yanel-trunk/ws/yanel-trunk.working-copy/src/realms/yanel-website/src/test/canoo/results/index.html Which should remind us we still have to skip the Yanel specific-tests for customer projects! > [xslt] Processing http://195.226.6.72:8080/job/Yanel-trunk/ws/yanel-trunk.working-copy/src/realms/yanel-website/src/test/canoo/results/WebTestOverview.xml to http://195.226.6.72:8080/job/Yanel-trunk/ws/yanel-trunk.working-copy/src/realms/yanel-website/src/test/canoo/results/index.html > [xslt] Loading stylesheet /opt/canoo/webtest-3.0-R_1758/resources/WebTestReportOverview.xsl > > wt.openResultFile.init: > > wt.openResultFile: > > wt.junitLikeReports: > [xslt] Processing http://195.226.6.72:8080/job/Yanel-trunk/ws/yanel-trunk.working-copy/src/realms/yanel-website/src/test/canoo/results/WebTestOverview.xml to http://195.226.6.72:8080/job/Yanel-trunk/ws/yanel-trunk.working-copy/src/realms/yanel-website/src/test/canoo/results/WebTestOverview.junit.xml > [xslt] Loading stylesheet /opt/canoo/webtest-3.0-R_1758/resources/WebTestOverview2JUnit.xsl > > wt.countWebtestResults: > > BUILD FAILED > http://195.226.6.72:8080/job/Yanel-trunk/ws/yanel-trunk.working-copy/src/build/targets/test.xml :6: The following error occurred while executing this line: > http://195.226.6.72:8080/job/Yanel-trunk/ws/yanel-trunk.working-copy/src/build/targets/test.xml :12: The following error occurred while executing this line: > /opt/canoo/webtest-3.0-R_1758/webtest.xml:431: 1 of 4 webtests have failed (3 successful)! > > Total time: 3 minutes 53 seconds > Recording test results From bugzilla at wyona.com Thu Dec 3 11:26:51 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 11:26:54 2009 Subject: [Yanel-dev] [Bug 7330] New: Yanel's HTMLSerializer adds line-breaks after closing "ins" and "del" tags => spurious whitespace on pages Message-ID: <20091203102651.DB91910C971@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7330 Summary: Yanel's HTMLSerializer adds line-breaks after closing "ins" and "del" tags => spurious whitespace on pages Product: Yanel Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal (C) Priority: P3 Component: General AssignedTo: yanel-development@wyona.com ReportedBy: guillaume.deflache@wyona.com QAContact: yanel-development@wyona.com In org.wyona.yanel.core.serialization.HTMLSerializer these tags are not in the inline tags' list, although they *may* be inline (but also block in other contexts, see : > These two elements are unusual for HTML in that they may serve as either block-level or inline elements (but not both). They may contain one or more words within a paragraph or contain one or more block-level elements such as paragraphs, lists and tables. ). Note that in this class the inline/block distinction which matters is not the structural one, but the presentational one, that is if the browser is likely to ignore whitespace after the closing tag (because the element is anyway going to be displayed on a separate line according to HTML standard, so this whitespace will not matter). IMHO it would be much simpler to allow line-breaks only on "non-hybrid" displayed-as-block elements, reversing the logic. A list of such elements can be found in : simply pick all elements which "display" property is exactly "block" there. We should also add the line-break before the element opening tag and not after the element closing tag, because http://www.w3.org/TR/html401/struct/global.html#h-7.5.3 says: > [...] Generally, block-level elements begin on new lines [it does not say: end with a line-break!] -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. You are the assignee for the bug, or are watching the assignee. From bugzilla at wyona.com Thu Dec 3 20:37:45 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:37:47 2009 Subject: [Yanel-dev] [Bug 4818] implement save of ODT resp. content.xml (zip...) Message-ID: <20091203193745.CAD8A10CA5F@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=4818 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |yanel-development@wyona.com -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 20:37:46 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:37:51 2009 Subject: [Yanel-dev] [Bug 4972] grep -rf TODO * Message-ID: <20091203193746.373F010CA97@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=4972 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |yanel-development@wyona.com -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 20:37:46 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:37:52 2009 Subject: [Yanel-dev] [Bug 5016] implement OSCOM website with Yanel and Yulup Message-ID: <20091203193746.DCBF110CA5F@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=5016 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |yanel-development@wyona.com -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 20:37:47 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:37:52 2009 Subject: [Yanel-dev] [Bug 5030] After authentication has been accomplished one should be redirected back to http (instead of https) Message-ID: <20091203193747.6017710CA97@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=5030 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |yanel-development@wyona.com -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 20:37:48 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:37:53 2009 Subject: [Yanel-dev] [Bug 5112] Enhance Yarep Website Message-ID: <20091203193748.D874410CA97@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=5112 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |yanel-development@wyona.com -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 20:42:46 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:42:47 2009 Subject: [Yanel-dev] [Bug 5119] using iCal with Yanel Message-ID: <20091203194246.5707310CA5F@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=5119 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|simone.gerber@wyona.com |michael.wechner@wyona.org ------- Comment #4 from guillaume.deflache@wyona.com 2009-12-03 20:48 ------- Michi has been running MacOSX for some time so we can figure it out himself directly! ;) -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 20:50:56 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:50:58 2009 Subject: [Yanel-dev] [Bug 4957] statistics Message-ID: <20091203195056.3427F10CA5F@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=4957 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|simon.litwan@wyona.org |bruno.vonrotz@wyona.com Priority|P3 |P1 ------- Comment #6 from guillaume.deflache@wyona.com 2009-12-03 20:56 ------- Bruno, Michi, you may want to use it this bug for our lead generation, etc. efforts (it is referenced from our current roadmap BTW). Michi, you might want to reference this bug number on your commits. For the record, since last update, Google Analytics engine support was added, and Wyona has some customer-specific code and experience on WebTrends integration. -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 20:57:08 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 20:59:18 2009 Subject: [Yanel-dev] [Bug 7306] Apply GUI guidelines to user-/group-management Message-ID: <20091203195708.3473910CA8F@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7306 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal (C) |enhancement Component|General |Design ------- Comment #1 from guillaume.deflache@wyona.com 2009-12-03 21:02 ------- This is an enhancement, not a bug. -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 21:21:01 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 21:21:03 2009 Subject: [Yanel-dev] [Bug 7307] implement Revisions menu Message-ID: <20091203202101.3382C10CAF4@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7307 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |7128 nThis| | Severity|normal (C) |enhancement Component|Navigation |UI Design Summary|Specify Revisions menu |implement Revisions menu ------- Comment #1 from guillaume.deflache@wyona.com 2009-12-03 21:26 ------- This is an enhancement, not a bug. IMHO was done in http://lists.wyona.org/pipermail/yanel-development/2009-April/003478.html and following, time to implement it! WDYT? -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Thu Dec 3 21:21:01 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Thu Dec 3 21:21:06 2009 Subject: [Yanel-dev] [Bug 7128] [wanted1.0+] toolbar: simplify "Edit" menu Message-ID: <20091203202101.B775610CAB2@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7128 guillaume.deflache@wyona.com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |7307 -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. You are the assignee for the bug, or are watching the assignee. From guillaume.deflache at wyona.com Fri Dec 4 09:18:39 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Fri Dec 4 09:24:44 2009 Subject: [Yanel-dev] Deploy Yanel within a Stax/Amazon-EC2 cloud In-Reply-To: <4AB6A9CF.5060807@wyona.com> References: <4AB6A9CF.5060807@wyona.com> Message-ID: <4B18C5DF.9040008@wyona.com> Hi! Michael Wechner schrieb: > I think it would interesting to give the Stax/Amazon-EC2 cloud > deployment a try: > > http://wiki.stax.net/w/index.php/Deploying_WAR_Files Some other tutorials: - Google App Engine http://www.ibm.com/developerworks/java/library/j-javadev2-1/ - another for Amazon EC2 http://www.ibm.com/developerworks/java/library/j-javadev2-2/ (Note: both use Groovy as a JVM language for demo purposes but it should be very similar to using Java) Also Windows Azure now seems to support JEE webapps too: http://microsoftpdc.com/Sessions/SVC50 Cheers, Guillaume From michael.wechner at wyona.com Fri Dec 4 09:55:13 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Dec 4 10:08:58 2009 Subject: [Yanel-dev] Moving the logs out of the build dir (concerns Yanel source version) Message-ID: <4B18CE71.50506@wyona.com> Hi Currently the log files are saved within YANEL_SOURCE_HOME/build/logs I would like to move them out of the build dir to YANEL_SOURCE_HOME/logs whereas I would make this configurable within src/build/local.build.properties The advantage would be that one can delete the build dir completely without loosing the log files and also one can have the logs dir configurable by local.build.properties. Any objections? Thanks Michi From guillaume.deflache at wyona.com Fri Dec 4 10:34:17 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Fri Dec 4 10:40:20 2009 Subject: [Yanel-dev] Moving the logs out of the build dir (concerns Yanel source version) In-Reply-To: <4B18CE71.50506@wyona.com> References: <4B18CE71.50506@wyona.com> Message-ID: <4B18D799.2030607@wyona.com> Michael Wechner schrieb: > Hi > > Currently the log files are saved within YANEL_SOURCE_HOME/build/logs > > I would like to move them out of the build dir to YANEL_SOURCE_HOME/logs > > whereas I would make this configurable within > > src/build/local.build.properties > > The advantage would be that one can delete the build dir completely > without loosing the log files > and also one can have the logs dir configurable by local.build.properties. > > Any objections? As discussed IRL, none except maybe make sure that the logs dir can be configured to be YANEL_SOURCE_HOME fro those like me who really want logs to be "in their face"! :) E.g. be careful if there is something somewhere deleting all logs by deleting the whole directory! ;) Cheers, Guillaume From michael.wechner at wyona.com Fri Dec 4 15:13:31 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Dec 4 15:23:00 2009 Subject: [Yanel-dev] Moving the logs out of the build dir (concerns Yanel source version) In-Reply-To: <4B18D799.2030607@wyona.com> References: <4B18CE71.50506@wyona.com> <4B18D799.2030607@wyona.com> Message-ID: <4B19190B.1060107@wyona.com> Guillaume D?flache wrote: > Michael Wechner schrieb: >> Hi >> >> Currently the log files are saved within YANEL_SOURCE_HOME/build/logs >> >> I would like to move them out of the build dir to YANEL_SOURCE_HOME/logs >> >> whereas I would make this configurable within >> >> src/build/local.build.properties >> >> The advantage would be that one can delete the build dir completely >> without loosing the log files >> and also one can have the logs dir configurable by >> local.build.properties. >> >> Any objections? > > As discussed IRL, none except maybe make sure that the logs dir can be > configured to be YANEL_SOURCE_HOME fro those like me who really want > logs to be "in their face"! :) that should be possible now. Overwrite the parameter log4j.path (see src/builld/build.properties) within src/build/local.build.properties Btw, I have introduced now also a dedicated 404 log, which means all 404 are being logged. Cheers Michi > E.g. be careful if there is something somewhere deleting all logs by > deleting the whole directory! ;) > > Cheers, > Guillaume From guillaume.deflache at wyona.com Fri Dec 4 15:39:15 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Fri Dec 4 15:47:28 2009 Subject: [Yanel-dev] Moving the logs out of the build dir (concerns Yanel source version) In-Reply-To: <4B19190B.1060107@wyona.com> References: <4B18CE71.50506@wyona.com> <4B18D799.2030607@wyona.com> <4B19190B.1060107@wyona.com> Message-ID: <4B191F13.5020102@wyona.com> Michael Wechner schrieb: > Guillaume D?flache wrote: >> [...] >> As discussed IRL, none except maybe make sure that the logs dir can be >> configured to be YANEL_SOURCE_HOME fro those like me who really want >> logs to be "in their face"! :) > > that should be possible now. Overwrite the parameter log4j.path (see > src/builld/build.properties) within src/build/local.build.properties OK, thanks! > Btw, I have introduced now also a dedicated 404 log, which means all 404 > are being logged. I don't think implementing it like this is such a good idea: - this adds some more configuration burden - the configuration is likely to be the same as the access log IMHO - what are you going to do when we will want to handle other 4xx (or even maybe 5xx) error codes separately??? Maybe we could log simples accesses, e.g. 1xx/2xx/3xx at the INFO level, 4xx's at the WARN level and 5xx at the ERROR level. Then it's trivial to filter out errors and warnings at the line level. >> E.g. be careful if there is something somewhere deleting all logs by >> deleting the whole directory! ;) I guess I'll see when I (dare to) try! ;) From michael.wechner at wyona.com Fri Dec 4 16:21:10 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Dec 4 16:30:39 2009 Subject: [Yanel-dev] Moving the logs out of the build dir (concerns Yanel source version) In-Reply-To: <4B191F13.5020102@wyona.com> References: <4B18CE71.50506@wyona.com> <4B18D799.2030607@wyona.com> <4B19190B.1060107@wyona.com> <4B191F13.5020102@wyona.com> Message-ID: <4B1928E6.4060503@wyona.com> Guillaume D?flache wrote: >> Btw, I have introduced now also a dedicated 404 log, which means all >> 404 are being logged. > > I don't think implementing it like this is such a good idea: > - this adds some more configuration burden > - the configuration is likely to be the same as the access log IMHO > - what are you going to do when we will want to handle other 4xx (or > even maybe 5xx) error codes separately??? > > Maybe we could log simples accesses, e.g. 1xx/2xx/3xx at the INFO > level, 4xx's at the WARN level and 5xx at the ERROR level. Then it's > trivial to filter out errors and warnings at the line level. of course we can introduce a http-status log, but I think the 404 are important to be dedicated, because it's something which content editors/authors want to know explicitely. But if we can can get these messages out with some filter, then this would be fine as well. WDOT? Cheers Michi From simon at 333.ch Fri Dec 4 19:19:55 2009 From: simon at 333.ch (simon) Date: Fri Dec 4 19:30:00 2009 Subject: [Yanel-dev] tinyMCE link and image lookup problem Message-ID: <4B1952CB.3070300@333.ch> hi all i just noticed a real problem within our tinyMCE integration. at the moment the lookup will insert path always with '../'. the lookup doesn't know anything about how relative the document is to the inserted path. i think the lookup needs to know this. probably the easiest way is to give a back2realm parameter when calling the lookup. and now the big problem number two: tinyMCE doesn't know the correct back2realm of the document either. and the big problem number three (a very ugly one): tinyMCE shows broken (or none) images if the document has another relation to the realm then tinyMCE (e.g {back2ream}/usecases/tinymce.html) has. as said above to fix the lookup problem is think a request parameter with the wished back2realm value would be an easy way to fix it. but to fix problem two and three there would be a bigger effort. one approach i can think of would be introducing parameter matching for resource-types. this is something i miss in yanel for a long time. i think this would simplify any editor integration a lot (and also other problems). this way an editor would be called with the same path as the web-view of a document but with a special request parameter, therefore it would be easy to get the right back2realm value when open the document with tinyMCE. problem number three would be gone as well. maybe there would be another (uglier) approach: calculating the back2realm value via the edit-path value. but i'm not sure this would help to solve problem number three since the solution to this seems to be setting the tinyMCE paramter 'document_base_url' [1] which has to be absolute. so the big question is do we want to finally introduce parameter matching? or does someone has another clean but simpler solution to this problems. to be honest i think this problems are show stoppers re releasing yanel. WDOT? [1] http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/document_base_url cheers simon From guillaume.deflache at wyona.com Fri Dec 4 19:24:21 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Fri Dec 4 19:30:23 2009 Subject: [Yanel-dev] AllowEncodedSlashes Apache httpd reverse proxy In-Reply-To: <4B144A8B.3060600@wyona.com> References: <4B144A8B.3060600@wyona.com> Message-ID: <4B1953D5.5040409@wyona.com> Michael Wechner schrieb: > Hi > > I have finally figured out how Apache httpd forwards %-encoded slashes: > > http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6849 Beware, it looks like it's still buggy and/or documentation is incorrect: https://issues.apache.org/bugzilla/show_bug.cgi?id=35256 ("%2F will be decoded in PATH_INFO (Documentation to AllowEncodedSlashes says no decoding will be done)") I also could not find a reason why it is a security issue (except ironically because only Apache does this so it allows detecting that some site is running on Apache!), maybe we should ask the Apache people? IMHO it is not really safe to rely on Apache or even other other servers doing this properly, so I suggest we keep our "^-encoding" method (cf. org.wyona.yanel.core.util.HttpServletRequestHelper#decodeURIinURLpath[1] for the decoder). For Yanel this would mean we should provide a corresponding '^-version' of org.wyona.yanel.core.util.PathUtil#getResourcesHtdocsPathURLencoded[2] probably with a different signature (I'd suggest getResourcesHtdocsPath(Resource resource, final char escapeCharacter)). I have had a (draft, untested) implementation of this sleeping on my local work hard drive for some time... [1]: http://svn.wyona.com/repos/public/yanel/trunk/src/core/java/org/wyona/yanel/core/util/HttpServletRequestHelper.java [2]: http://svn.wyona.com/repos/public/yanel/trunk/src/core/java/org/wyona/yanel/core/util/PathUtil.java And I think we should deprecated the other methods (not-encoded and URL-encoded one). WDYOT? From guillaume.deflache at wyona.com Fri Dec 4 22:19:58 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Fri Dec 4 22:31:21 2009 Subject: [Yanel-dev] [HEADS UP] ResourceManager and ResourceConfigurationMap class may die soon; resource-types' URL matching (e.g. on request parameters) In-Reply-To: <4A41DCEB.9000205@wyona.com> References: <4A41DCEB.9000205@wyona.com> Message-ID: <4B197CFE.5080500@wyona.com> Some progress report as Simon showed some renewed interest in this = lately! ;) Cf. = http://lists.wyona.org/pipermail/yanel-development/2009-December/004192.html Guillaume D=E9flache a =E9crit : > Hi! > = > As discussed with Simon some time ago (unfortunately no one took notes = > :(...) we would like to be able to choose the resource-type to use for a = > request by matching the value or presence of HTTP request parameters = > (ATM one can only match on the request URI). > = > As far as Michi and I can remember, we then considered at least 2 options: > = > = > *Option 1*: allow a syntax similar to "**?my-param-name=3D*" in map.rc-ma= p = > files in "matcher" elements for the "pattern" attribute. > = > Some issues: > - most probably we want to ignore the order of the request parameters as = > they are written in the pattern, as anyway AFAIK the servlet spec does = > not define it > - should we also match parameters passed through POST, albeit the syntax = > of the pattern could make use think it would only work for GET: Mich and = > I would say we should, and the servlet API makes that choice easier > - what would "**" mean in the query string part? I'd suggest it should = > either throw some parsing exception, or match any other parameter that = > could also be present (would allow use to distinguish between the two = > cases "only these parameters" and "these parameters and some others we = > do not care about", although that might be somewhat counter-intuitive) Any opinion about these issues, esp. Simon? On the 3rd I'd personally go = for the "match any other parameter" solution. > *Option 2*: allow full customization of the matching policy by = > introducing a new Java interface for it. > (1st please note that #1 can readily be implemented independently of #2 = > but of course we'd rather put new functionality in the new places if = > possible.) I did some (unfinished) work on this, please review the attachment. There is still some unfinished stuff, mainly around the TODO and XXX = markers, please ask me as they probably won't make any sense to anyone = else than me. > This interface would be almost identical to the = > org.wyona.yanel.core.ResourceManager class's (minus the deprecated = > parts) and especially provide getResource(Environment environment, Realm = > realm, String path, ResourceConfiguration rc): having access to the = > environment should allow any future kind of matching imaginable (see = > Apache Cocoon for wild ideas! ;) ). > I'd suggest to use a better name (*Manager is rather uninspiring): = > org.wyona.yanel.core.api.ResourceTypeMatcherV1 maybe? The current interface has the same name but provide = getResourceConfiguration(Environment environment, Realm realm, String = path) instead: indeed IMHO what we need to be configurable is only the = RC object selector, not a Resource selector (all Resource objects may be = instantiated in the same way for now, better not expose classloading = guts before we get our runtime-modularity story right). > Then as 1st step we would have to reimplement = > org.wyona.yanel.core.ResourceManager using the new interface and still = > use it as the default for backward-compatibility. > Then we would have to allow configuration of the concrete matching = > class. ATM this is done in the Yanel class, but Michi would like it to = That's more or less what is done in the patch. > be configurable per realm, and thanks to the way it's currently = > encapsulated there this is also possible only with some more = > deprecations (namely Yanel.getResourceManager). I did not tackle that yet. We may not need to change Yanel#getResourceManager or even = ResourceManager to do this, as ResourceManager#getResource has already = the realm as parameter. Maybe the ResourceManager should/could become a registry of = ResourceTypeMatcherV1 objects for all realms, adn then we would only = need = ResourceManager#setResourceTypeMatcherForRealm(ResourceTypeMatcherV1 = matcher, Realm realm)??? But then maybe we would only need = ResourceTypeMatcherV1#getResourceConfiguration(Environment environment, = String path) without the realm parameter? Or maybe we should wait and do that in ResourceTypeMatcherV2? > I'd also suggest we hide functionality actually in = > ResourceConfigurationMap in the concrete matcher implementations: the = > class only has static methods and needlessly expose mechanics. It also = This still can/should be done once dust has settled on all things above. > needs changing because Michi would like to be able to parametrize the = > "map.rc-map" file name. This will probably be left as an exercise to casual contributors! :P Cheers, Guillaume -------------- next part -------------- Index: conf/spring-yanel-config.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- conf/spring-yanel-config.xml (Revision 45854) +++ conf/spring-yanel-config.xml (Arbeitskopie) @@ -23,6 +23,8 @@ --> + + = This will have no effect on interfaces and is backwards compatible (but not forwards) and will give us some playing ground to better understand how we need to design a generic usecase registry. Any comments/feedback very welcome Cheers Michi From simon at 333.ch Fri Dec 11 00:08:13 2009 From: simon at 333.ch (simon) Date: Fri Dec 11 00:17:57 2009 Subject: [Yanel-dev] rc matching (e.g. on request parameters) In-Reply-To: <4B1C3D75.8060506@333.ch> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> <4B1C3D75.8060506@333.ch> Message-ID: <4B217F5D.5060703@333.ch> hi all i would like to volunteer on this matching request parameters issue. but i don't understand all of your ideas yet. to become more concrete i would like to naively propose something. first a new map which is backwards compatible with the old one. for proceeding the map still the ResourceConfigurationMap class would be responsible. but the implementation of how the entries in the map would match something would be moved to some matcher classes. whereas the matcher-classes would have to implement something like ResourceTypeMatcherV1. but ResourceTypeMatcherV1 would have to allow over give of arbitrary parameters e.g. pattern for the wildcard-path-matcher or parameter-name and paramter-value for the parameter-matcher. maybe the whole line as a string e.g. '' and the matcher knows what to get from it. any opinion is very appreciated. cheers simon From michael.wechner at wyona.com Fri Dec 11 09:29:28 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Dec 11 09:39:14 2009 Subject: [Yanel-dev] rc matching (e.g. on request parameters) In-Reply-To: <4B217F5D.5060703@333.ch> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> <4B1C3D75.8060506@333.ch> <4B217F5D.5060703@333.ch> Message-ID: <4B2202E8.8030406@wyona.com> Hi IIRC we wanted to introduce a class called ResourceTypeMatcherV1 (and an interface) which has at least the same functionality as now and make it the default Matcher (see Guillaume's recent email http://lists.wyona.org/pipermail/yanel-development/2009-December/004194.html) which can be configurable per realm. After that we/you can introduce a new version, e.g. ResourceTypeMatcherV2 covering your functionality below, whereas I need to study it more closely, but having said the above it doesn't really matter, because you could also create your own custom matcher version. Makes sense? Cheers Michi http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7205 simon wrote: > hi all > > i would like to volunteer on this matching request parameters issue. > but i don't understand all of your ideas yet. > > to become more concrete i would like to naively propose something. > > first a new map which is backwards compatible with the old one. for > proceeding the map still the ResourceConfigurationMap class would be > responsible. but the implementation of how the entries in > the map would match something would be moved to some matcher classes. > > > > class="org.wyona.yanel.impl.matcher.PaternMatcher"> > class="org.custom.yanel.impl.matcher.CrazyMatcher"> > > > paramter-value="tinymce" rcpath="/tinymce-yanel-rc.xml"/> > rcpath="/tinymce-yanel-rc.xml"/> > > > whereas the matcher-classes would have to implement something like > ResourceTypeMatcherV1. but ResourceTypeMatcherV1 would have to allow > over give of arbitrary parameters e.g. pattern for the > wildcard-path-matcher or parameter-name and paramter-value for the > parameter-matcher. maybe the whole line as a string e.g. ' type="parameter" parameter-name="editor" paramter-value="tinymce" > rcpath="/tinymce-yanel-rc.xml">' and the matcher knows what to get > from it. > > any opinion is very appreciated. > > cheers > simon From guillaume.deflache at wyona.com Fri Dec 11 10:57:57 2009 From: guillaume.deflache at wyona.com (=?UTF-8?B?R3VpbGxhdW1lIETDqWZsYWNoZQ==?=) Date: Fri Dec 11 11:03:19 2009 Subject: [Yanel-dev] Re: [Yanel-commits] rev 45956 - public/yanel/trunk/src/build In-Reply-To: <200912102118.nBALItOO016226@cvs-extra.wyona.com> References: <200912102118.nBALItOO016226@cvs-extra.wyona.com> Message-ID: <4B2217A5.7040309@wyona.com> michi@wyona.com schrieb: > Author: michi > Date: 2009-12-10 22:18:54 +0100 (Thu, 10 Dec 2009) > New Revision: 45956 > > Modified: > public/yanel/trunk/src/build/dependencies.xml > Log: > latest quartz scheduler added as dependency > > Modified: public/yanel/trunk/src/build/dependencies.xml > =================================================================== > --- public/yanel/trunk/src/build/dependencies.xml 2009-12-10 21:11:42 UTC (rev 45955) > +++ public/yanel/trunk/src/build/dependencies.xml 2009-12-10 21:18:54 UTC (rev 45956) > @@ -92,6 +92,7 @@ > > > > + > > > > Couldn't we for now depend only on some "quartz-core" instead of the whole bundle? From guillaume.deflache at wyona.com Fri Dec 11 11:00:44 2009 From: guillaume.deflache at wyona.com (=?UTF-8?B?R3VpbGxhdW1lIETDqWZsYWNoZQ==?=) Date: Fri Dec 11 11:06:06 2009 Subject: [Yanel-dev] Re: [Yanel-commits] rev 45957 - public/yanel/trunk/src/webapp/WEB-INF In-Reply-To: <200912102122.nBALMfSL016286@cvs-extra.wyona.com> References: <200912102122.nBALMfSL016286@cvs-extra.wyona.com> Message-ID: <4B22184C.6090808@wyona.com> michi@wyona.com schrieb: > Author: michi > Date: 2009-12-10 22:22:41 +0100 (Thu, 10 Dec 2009) > New Revision: 45957 > > Modified: > public/yanel/trunk/src/webapp/WEB-INF/web.xml > Log: > scheduler config added > > Modified: public/yanel/trunk/src/webapp/WEB-INF/web.xml > =================================================================== > --- public/yanel/trunk/src/webapp/WEB-INF/web.xml 2009-12-10 21:18:54 UTC (rev 45956) > +++ public/yanel/trunk/src/webapp/WEB-INF/web.xml 2009-12-10 21:22:41 UTC (rev 45957) > @@ -60,6 +60,13 @@ > > > > + > + > + scheduler > + false > + > + > + > > > static-content-cache-expires > Why not add it to Yanel configuration? AFAIU scheduling does not have to happen in a webapp context, and making it not require one would help for testing and general decoupling of things. From michael.wechner at wyona.com Fri Dec 11 11:20:37 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Dec 11 11:30:21 2009 Subject: [Yanel-dev] Re: [Yanel-commits] rev 45956 - public/yanel/trunk/src/build In-Reply-To: <4B2217A5.7040309@wyona.com> References: <200912102118.nBALItOO016226@cvs-extra.wyona.com> <4B2217A5.7040309@wyona.com> Message-ID: <4B221CF5.7080904@wyona.com> Guillaume D?flache wrote: > michi@wyona.com schrieb: >> Author: michi >> Date: 2009-12-10 22:18:54 +0100 (Thu, 10 Dec 2009) >> New Revision: 45956 >> >> Modified: >> public/yanel/trunk/src/build/dependencies.xml >> Log: >> latest quartz scheduler added as dependency >> >> Modified: public/yanel/trunk/src/build/dependencies.xml >> =================================================================== >> --- public/yanel/trunk/src/build/dependencies.xml 2009-12-10 >> 21:11:42 UTC (rev 45955) >> +++ public/yanel/trunk/src/build/dependencies.xml 2009-12-10 >> 21:18:54 UTC (rev 45956) >> @@ -92,6 +92,7 @@ >> > artifactId="commons-beanutils" version="1.6"/> >> > artifactId="commons-fileupload" version="1.2"/> >> >> + > version="1.6.6"/> >> >> >> >> > > Couldn't we for now depend only on some "quartz-core" instead of the > whole bundle? To be honest I am not familiar enough with Quartz libs to say what is really needed and what isn't and their instructions just said use the quartz-all (whatever that is). I understand your concerns, but since one cannot really make use of it at the moment I wouldn't worry too much about this and I definitely keep it in mind and will try to replace it by something minimal as soon as I understand it better. Cheers Michael From michael.wechner at wyona.com Fri Dec 11 11:21:32 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Dec 11 11:31:13 2009 Subject: [Yanel-dev] Re: [Yanel-commits] rev 45957 - public/yanel/trunk/src/webapp/WEB-INF In-Reply-To: <4B22184C.6090808@wyona.com> References: <200912102122.nBALMfSL016286@cvs-extra.wyona.com> <4B22184C.6090808@wyona.com> Message-ID: <4B221D2C.3070100@wyona.com> Guillaume D?flache wrote: > michi@wyona.com schrieb: >> Author: michi >> Date: 2009-12-10 22:22:41 +0100 (Thu, 10 Dec 2009) >> New Revision: 45957 >> >> Modified: >> public/yanel/trunk/src/webapp/WEB-INF/web.xml >> Log: >> scheduler config added >> >> Modified: public/yanel/trunk/src/webapp/WEB-INF/web.xml >> =================================================================== >> --- public/yanel/trunk/src/webapp/WEB-INF/web.xml 2009-12-10 >> 21:18:54 UTC (rev 45956) >> +++ public/yanel/trunk/src/webapp/WEB-INF/web.xml 2009-12-10 >> 21:22:41 UTC (rev 45957) >> @@ -60,6 +60,13 @@ >> >> >> >> + >> + >> + scheduler >> + false >> + >> + >> + >> >> >> static-content-cache-expires >> > > Why not add it to Yanel configuration? > AFAIU scheduling does not have to happen in a webapp context, and > making it not require one would help for testing and general > decoupling of things. agreed, will move it to the Yanel config. Thanks Michi From guillaume.deflache at wyona.com Fri Dec 11 11:57:33 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Fri Dec 11 12:03:56 2009 Subject: [Yanel-dev] Integration of quartz scheduler In-Reply-To: <4B21735D.9040809@wyona.com> References: <4B21735D.9040809@wyona.com> Message-ID: <4B22259D.2080406@wyona.com> Michael Wechner schrieb: > Hi > > I have started the integration of the quartz scheduler, which was rather > simple (according to > http://www.quartz-scheduler.org/docs/quick_start_guide.html) > > Now the actual design questions arise: > > - How do we want to make this scheduler available to the resources? I'd say the scheduler should be attached to the Yanel object, or even maybe to each Realm object. > If we want to keep Yanel itself independent of the actual scheduler > framework (like for example Quartz), then my suggestion would be to > create an interface > > interface ScheduableV1 { > void setScheduler(QuartzScheduler); > QuartzScheduler getScheduler(); > } Err... why would you name it QuartzScheduler if it is to be independant? My draft proposal for now: ---8<--- interface SchedulableV1 { void setScheduler(Scheduler); Scheduler getScheduler(); } abstract class Scheduler { /** * TODO What about notifications of [ab]normal termination? * @return jobID */ String schedule(Identity jobOwner, String cronExpression, Class jobClass, String... jobParameters); Iterable getJobIDs(); Job getJob(jobID); boolean cancelJob(jobID); } ---8<--- I am not sure that we need IDs, and it may indeed be problematic with Unix `cron` (see below) where are simply lines in a file... But then canceling a specific job would imply searching among all jobs for the given identity, which may be OK. Or if we do not care about cron (generally speaking: non in-JVM execution) we could use http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html or at least get some inspiration from it. > because this allows to introduce new scheduler frameworks at some later > stage. > > One could argue that there is not much out there than the Quartz > Scheduler and we rather couple it to the realm, which I'd say there is at least cron that sysadmins often prefer when they have the choice/can enforce it because that's something they may already have to manage anyway. > leads to another design question: > > - What about cross-scheduling in between realms? > > I could imagine there are case which require something like this, just > as cross-reading/writing of content, but > in most cases I would argue that people don't want to allow to see the > scheduled jobs of other realms. I cannot image the need for this, but sometimes I lack imagination! ;) Maybe for V2 then? > - The third questions then would be how do we connect access controlling > with scheduling? Every scheduled job having an URL would be a good start. Maybe every realm should also have a jobs URL which would hold them together? From michael.wechner at wyona.com Fri Dec 11 11:59:40 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Dec 11 12:09:22 2009 Subject: [Yanel-dev] Re: [Yanel-commits] rev 45957 - public/yanel/trunk/src/webapp/WEB-INF In-Reply-To: <4B221D2C.3070100@wyona.com> References: <200912102122.nBALMfSL016286@cvs-extra.wyona.com> <4B22184C.6090808@wyona.com> <4B221D2C.3070100@wyona.com> Message-ID: <4B22261C.5090609@wyona.com> Michael Wechner wrote: >>> >> >> Why not add it to Yanel configuration? >> AFAIU scheduling does not have to happen in a webapp context, and >> making it not require one would help for testing and general >> decoupling of things. > > agreed, will move it to the Yanel config. done Thanks Michi > > Thanks > > Michi > From simon at 333.ch Fri Dec 11 15:00:40 2009 From: simon at 333.ch (simon) Date: Fri Dec 11 15:10:29 2009 Subject: [Yanel-dev] rc matching (e.g. on request parameters) In-Reply-To: <4B2202E8.8030406@wyona.com> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> <4B1C3D75.8060506@333.ch> <4B217F5D.5060703@333.ch> <4B2202E8.8030406@wyona.com> Message-ID: <4B225088.2080206@333.ch> Michael Wechner schrieb: > Hi > > IIRC we wanted to introduce a class called ResourceTypeMatcherV1 (and > an interface) which has at least the same functionality as now and > make it the default Matcher IIUC same functionality means same as ResourceManager, right? > > (see Guillaume's recent email > > http://lists.wyona.org/pipermail/yanel-development/2009-December/004194.html) > > > which can be configurable per realm. > > After that we/you can introduce a new version, e.g. > ResourceTypeMatcherV2 covering your functionality below, whereas > I need to study it more closely, but having said the above it doesn't > really matter, because you could also create your own custom matcher > version. > > Makes sense? maybe i don't understand. as far as i understand guillaume's mail and the attached patch he wants to replace the ResourceManager and add an interface for it. which i think make sense in order to clean up. but i don't see how this helps to allow parameter (or what ever) matching. i don't want to replace the current matching mechanism i want to extend it. actually i mainly want to extend the ResourceConfigurationMap (chain-of-responsibility) part of it. maybe you can help me to understand better. thanks simon > > Cheers > > Michi > > > http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7205 > > simon wrote: >> hi all >> >> i would like to volunteer on this matching request parameters issue. >> but i don't understand all of your ideas yet. >> >> to become more concrete i would like to naively propose something. >> >> first a new map which is backwards compatible with the old one. for >> proceeding the map still the ResourceConfigurationMap class would be >> responsible. but the implementation of how the entries in >> the map would match something would be moved to some matcher classes. >> >> >> >> > class="org.wyona.yanel.impl.matcher.PaternMatcher"> >> > class="org.custom.yanel.impl.matcher.CrazyMatcher"> >> >> >> > paramter-value="tinymce" rcpath="/tinymce-yanel-rc.xml"/> >> > rcpath="/tinymce-yanel-rc.xml"/> >> >> >> whereas the matcher-classes would have to implement something like >> ResourceTypeMatcherV1. but ResourceTypeMatcherV1 would have to allow >> over give of arbitrary parameters e.g. pattern for the >> wildcard-path-matcher or parameter-name and paramter-value for the >> parameter-matcher. maybe the whole line as a string e.g. '> type="parameter" parameter-name="editor" paramter-value="tinymce" >> rcpath="/tinymce-yanel-rc.xml">' and the matcher knows what to get >> from it. >> >> any opinion is very appreciated. >> >> cheers >> simon > From bugzilla at wyona.com Fri Dec 11 15:10:52 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Fri Dec 11 15:10:53 2009 Subject: [Yanel-dev] [Bug 7205] HTTP request parameters matching for RT selection Message-ID: <20091211141052.4338210CB4A@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7205 ------- Comment #3 from michael.wechner@wyona.org 2009-12-11 15:15 ------- Also see http://lists.wyona.org/pipermail/yanel-development/2009-December/004194.html -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From bugzilla at wyona.com Mon Dec 14 16:01:38 2009 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Mon Dec 14 16:01:41 2009 Subject: [Yanel-dev] [Bug 7342] New: Walk through "from sratch" and identify all improvements needed for 1.0 Message-ID: <20091214150138.AEC0B10C9BA@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7342 Summary: Walk through "from sratch" and identify all improvements needed for 1.0 Product: Yanel Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal (C) Priority: P1 Component: UI Design AssignedTo: michael.wechner@wyona.org ReportedBy: bruno.vonrotz@wyona.com QAContact: yanel-development@wyona.com Yanel 1.0 should come with a nice looking and well working 1.0 "from scratch" realm (potentially be called "quick start realm"). This means: - every page with a template, consistency between the pages - consistent choice of fonts and images, as well as real estate usage - consistent I18n - useful texts and links given on the pages that are there - nice overall template (potentially re-use the Informatica08 template) - other ... (to be identified) This "incident" is about locating where the changes need to be made. -- Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From michael.wechner at wyona.com Tue Dec 15 16:04:53 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 15 16:16:31 2009 Subject: [Yanel-dev] rc matching (e.g. on request parameters) In-Reply-To: <4B225088.2080206@333.ch> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> <4B1C3D75.8060506@333.ch> <4B217F5D.5060703@333.ch> <4B2202E8.8030406@wyona.com> <4B225088.2080206@333.ch> Message-ID: <4B27A595.2070600@wyona.com> simon wrote: > Michael Wechner schrieb: >> Hi >> >> IIRC we wanted to introduce a class called ResourceTypeMatcherV1 (and >> an interface) which has at least the same functionality as now and >> make it the default Matcher > IIUC same functionality means same as ResourceManager, right? yes, kind of, whereas it would use an enhanced ResourceConfigurationMap >> >> (see Guillaume's recent email >> >> http://lists.wyona.org/pipermail/yanel-development/2009-December/004194.html) >> >> >> which can be configurable per realm. >> >> After that we/you can introduce a new version, e.g. >> ResourceTypeMatcherV2 covering your functionality below, whereas >> I need to study it more closely, but having said the above it doesn't >> really matter, because you could also create your own custom matcher >> version. >> >> Makes sense? > maybe i don't understand. as far as i understand guillaume's mail and > the attached patch he wants to replace the ResourceManager and add an > interface for it. which i think make sense in order to clean up. that's what I tried to describe above > but i don't see how this helps to allow parameter (or what ever) > matching. i don't want to replace the current matching mechanism i > want to extend it. actually i mainly want to extend the > ResourceConfigurationMap (chain-of-responsibility) part of it. one can then do his/her own implementation using an enhanced ResourceConfigurationMap, without having to touch the existing stuff. The ResourceConfigurationMap is just one part (maybe the one which *you* are most interested in), but I think it makes sense to refactor "both" classes. Cheers Michael > > maybe you can help me to understand better. > > thanks > simon >> >> Cheers >> >> Michi >> >> >> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7205 >> >> simon wrote: >>> hi all >>> >>> i would like to volunteer on this matching request parameters issue. >>> but i don't understand all of your ideas yet. >>> >>> to become more concrete i would like to naively propose something. >>> >>> first a new map which is backwards compatible with the old one. for >>> proceeding the map still the ResourceConfigurationMap class would be >>> responsible. but the implementation of how the entries in >>> the map would match something would be moved to some matcher classes. >>> >>> >>> >>> >> class="org.wyona.yanel.impl.matcher.PaternMatcher"> >>> >> class="org.custom.yanel.impl.matcher.CrazyMatcher"> >>> >>> >>> >> paramter-value="tinymce" rcpath="/tinymce-yanel-rc.xml"/> >>> >> rcpath="/tinymce-yanel-rc.xml"/> >>> >>> >>> whereas the matcher-classes would have to implement something like >>> ResourceTypeMatcherV1. but ResourceTypeMatcherV1 would have to allow >>> over give of arbitrary parameters e.g. pattern for the >>> wildcard-path-matcher or parameter-name and paramter-value for the >>> parameter-matcher. maybe the whole line as a string e.g. '>> type="parameter" parameter-name="editor" paramter-value="tinymce" >>> rcpath="/tinymce-yanel-rc.xml">' and the matcher knows what to get >>> from it. >>> >>> any opinion is very appreciated. >>> >>> cheers >>> simon >> > From michael.wechner at wyona.com Tue Dec 15 16:36:26 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 15 16:46:16 2009 Subject: [Yanel-dev] SitetreeDOMImpl or rather NodeDOMImpl has an issue re isCollection Message-ID: <4B27ACFA.4030605@wyona.com> Hi I just realized that the Sitetree/Node DOM implementation src/impl/java/org/wyona/yanel/impl/navigation/NodeDOMImpl.java has an issue re the isCollection()/isResource() method. It is based on an XML, e.g. and when creating a new child and one should have to specify the node type (either collection or resource), then it's not clear what node type, because the method appendChild(Node) has no such argument and the methods isCollection() of the DOM implementation is just checking if there children. Of course there is the workaround that if it is supposed to be a collection, then create a child for this node, which will make it implicitely a collection. But that's not very nice :-( Hence I would suggest to change the API by introducing a method appendChild(Node, NodeType) WDYT? Thanks Michi From michael.wechner at wyona.com Tue Dec 15 16:54:43 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 15 17:04:33 2009 Subject: [Yanel-dev] SitetreeDOMImpl or rather NodeDOMImpl has an issue re isCollection In-Reply-To: <4B27ACFA.4030605@wyona.com> References: <4B27ACFA.4030605@wyona.com> Message-ID: <4B27B143.20700@wyona.com> Michael Wechner wrote: > Hi > > I just realized that the Sitetree/Node DOM implementation > > src/impl/java/org/wyona/yanel/impl/navigation/NodeDOMImpl.java > > has an issue re the isCollection()/isResource() method. It is based on > an XML, e.g. > > > > > > > > > > and when creating a new child and one should have to specify the node > type (either collection or resource), then > it's not clear what node type, because the method appendChild(Node) > has no such argument > and the methods isCollection() of the DOM implementation is just > checking if there children. > > Of course there is the workaround that if it is supposed to be a > collection, then create a child for this node, which > will make it implicitely a collection. But that's not very nice :-( > > Hence I would suggest to change the API by introducing a method > appendChild(Node, NodeType) or as an alternative one could have something like Node.setType(int type) WDYT? Thanks Michi > > WDYT? > > Thanks > > Michi From simon at 333.ch Tue Dec 15 17:29:20 2009 From: simon at 333.ch (simon) Date: Tue Dec 15 17:39:17 2009 Subject: [Yanel-dev] rc matching (e.g. on request parameters) In-Reply-To: <4B27A595.2070600@wyona.com> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> <4B1C3D75.8060506@333.ch> <4B217F5D.5060703@333.ch> <4B2202E8.8030406@wyona.com> <4B225088.2080206@333.ch> <4B27A595.2070600@wyona.com> Message-ID: <4B27B960.1010104@333.ch> Michael Wechner schrieb: thanks for your response. > >> but i don't see how this helps to allow parameter (or what ever) >> matching. i don't want to replace the current matching mechanism i >> want to extend it. actually i mainly want to extend the >> ResourceConfigurationMap (chain-of-responsibility) part of it. > > one can then do his/her own implementation using an enhanced > ResourceConfigurationMap, without having to touch the existing stuff. which i think is good too. but i don't consider request parameter matching as a custom enhancement. > > The ResourceConfigurationMap is just one part (maybe the one which > *you* are most interested in), but I think it makes sense to refactor > "both" classes. it's not particular *me*, it's more i would like to fix the tinyMCE lookup problem (http://lists.wyona.org/pipermail/yanel-development/2009-December/004192.html). to solve this i (and guillaume) think request paramter matching would allow to solve this. that's why i made the proposal about extending the map stuff. actually i just want to help but now i don't know how. cheers simon > > Cheers > > Michael >> >> maybe you can help me to understand better. >> >> thanks >> simon >>> >>> Cheers >>> >>> Michi >>> >>> >>> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7205 >>> >>> simon wrote: >>>> hi all >>>> >>>> i would like to volunteer on this matching request parameters >>>> issue. but i don't understand all of your ideas yet. >>>> >>>> to become more concrete i would like to naively propose something. >>>> >>>> first a new map which is backwards compatible with the old one. for >>>> proceeding the map still the ResourceConfigurationMap class would >>>> be responsible. but the implementation of how the entries >>>> in the map would match something would be moved to some matcher >>>> classes. >>>> >>>> >>>> >>>> >>> class="org.wyona.yanel.impl.matcher.PaternMatcher"> >>>> >>> class="org.custom.yanel.impl.matcher.CrazyMatcher"> >>>> >>>> >>>> >>> paramter-value="tinymce" rcpath="/tinymce-yanel-rc.xml"/> >>>> >>> rcpath="/tinymce-yanel-rc.xml"/> >>>> >>>> >>>> whereas the matcher-classes would have to implement something like >>>> ResourceTypeMatcherV1. but ResourceTypeMatcherV1 would have to >>>> allow over give of arbitrary parameters e.g. pattern for the >>>> wildcard-path-matcher or parameter-name and paramter-value for the >>>> parameter-matcher. maybe the whole line as a string e.g. '>>> type="parameter" parameter-name="editor" paramter-value="tinymce" >>>> rcpath="/tinymce-yanel-rc.xml">' and the matcher knows what to get >>>> from it. >>>> >>>> any opinion is very appreciated. >>>> >>>> cheers >>>> simon >>> >> > From guillaume.deflache at wyona.com Tue Dec 15 17:47:33 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Tue Dec 15 17:52:28 2009 Subject: [Yanel-dev] access logging: use logback? Message-ID: <4B27BDA5.9030806@wyona.com> [I know I already pointed at some log4j stuff before but...] Before reinventing the wheel I think we should have a deep (technical) look at logback (the successor of log4j, see ). It provides: - easy way to tag logs with a per-thread context[1] that can contain arbitrary data (username, cookie ID, geolocation or IP address come to mind!): http://logback.qos.ch/manual/mdc.html http://logback.qos.ch/manual/appenders.html#SiftingAppender - special support for access logging, which, if maybe not useful to us because it /seems/ to only be able to operate before the webapp level at the HTTP level, may give use some inspiration: http://logback.qos.ch/access.html http://logback.qos.ch/manual/layouts.html#AccessPatternLayout http://logback.qos.ch/manual/appenders.html#AccessSiftingAppender & end of http://logback.qos.ch/manual/filters.html - runtime configuration (via JMX) almost for free (for the cost of copy-pasting and registering a trivial ServletContextListener): http://logback.qos.ch/manual/jmxConfig.html - faster logging than log4j I think it's also a good way to test logback if we want to replace log4j with it in the longer term because of some new interesting features (as log4j development is more or less stale). it would also be a way to get gently into JMX stuff. WDYT? Cheers, Guillaume [1] granted, log4j have NDCs (cf. http://logging.apache.org/log4j/1.2/faq.html#3.1 and in http://logging.apache.org/log4j/1.2/manual.html look for "Nested Diagnostic Contexts") but they seem trickier to use as AFAICS we would have to manage threads and concurrency ourselves... From michael.wechner at wyona.com Tue Dec 15 23:43:06 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 15 23:52:57 2009 Subject: [Yanel-dev] rc matching (e.g. on request parameters) In-Reply-To: <4B27B960.1010104@333.ch> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> <4B1C3D75.8060506@333.ch> <4B217F5D.5060703@333.ch> <4B2202E8.8030406@wyona.com> <4B225088.2080206@333.ch> <4B27A595.2070600@wyona.com> <4B27B960.1010104@333.ch> Message-ID: <4B2810FA.2020203@wyona.com> simon wrote: > Michael Wechner schrieb: > > thanks for your response. >> >>> but i don't see how this helps to allow parameter (or what ever) >>> matching. i don't want to replace the current matching mechanism i >>> want to extend it. actually i mainly want to extend the >>> ResourceConfigurationMap (chain-of-responsibility) part of it. >> >> one can then do his/her own implementation using an enhanced >> ResourceConfigurationMap, without having to touch the existing stuff. > which i think is good too. but i don't consider request parameter > matching as a custom enhancement. >> >> The ResourceConfigurationMap is just one part (maybe the one which >> *you* are most interested in), but I think it makes sense to refactor >> "both" classes. > it's not particular *me*, it's more i would like to fix the tinyMCE > lookup problem > (http://lists.wyona.org/pipermail/yanel-development/2009-December/004192.html). > to solve this i (and guillaume) think request paramter matching would > allow to solve this. > that's why i made the proposal about extending the map stuff. > > actually i just want to help but now i don't know how. well, give me one or two more days in order to fix the above and you should be all set to continue on the TinyMCE. In the meantime you might want to "hardcode" the parameters within the Map class in order to get the TinyMCE resource type ready. Cheers Michi > > cheers > simon >> >> Cheers >> >> Michael >>> >>> maybe you can help me to understand better. >>> >>> thanks >>> simon >>>> >>>> Cheers >>>> >>>> Michi >>>> >>>> >>>> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7205 >>>> >>>> simon wrote: >>>>> hi all >>>>> >>>>> i would like to volunteer on this matching request parameters >>>>> issue. but i don't understand all of your ideas yet. >>>>> >>>>> to become more concrete i would like to naively propose something. >>>>> >>>>> first a new map which is backwards compatible with the old one. >>>>> for proceeding the map still the ResourceConfigurationMap class >>>>> would be responsible. but the implementation of how the >>>>> entries in the map would match something would be moved to some >>>>> matcher classes. >>>>> >>>>> >>>>> >>>>> >>>> class="org.wyona.yanel.impl.matcher.PaternMatcher"> >>>>> >>>> class="org.custom.yanel.impl.matcher.CrazyMatcher"> >>>>> >>>>> >>>>> >>>> paramter-value="tinymce" rcpath="/tinymce-yanel-rc.xml"/> >>>>> >>>> rcpath="/tinymce-yanel-rc.xml"/> >>>>> >>>>> >>>>> whereas the matcher-classes would have to implement something like >>>>> ResourceTypeMatcherV1. but ResourceTypeMatcherV1 would have to >>>>> allow over give of arbitrary parameters e.g. pattern for the >>>>> wildcard-path-matcher or parameter-name and paramter-value for the >>>>> parameter-matcher. maybe the whole line as a string e.g. '>>>> type="parameter" parameter-name="editor" paramter-value="tinymce" >>>>> rcpath="/tinymce-yanel-rc.xml">' and the matcher knows what to get >>>>> from it. >>>>> >>>>> any opinion is very appreciated. >>>>> >>>>> cheers >>>>> simon >>>> >>> >> > From michael.wechner at wyona.com Wed Dec 16 09:37:52 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Dec 16 09:48:12 2009 Subject: [Yanel-dev] [HEADS UP] ResourceManager and ResourceConfigurationMap class may die soon; resource-types' URL matching (e.g. on request parameters) In-Reply-To: <4B197CFE.5080500@wyona.com> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> Message-ID: <4B289C60.8020109@wyona.com> Dear Guillaume I am currently reviewing your patch in order to commit it. What is the reason that we didn't commit long time ago? Any technical reasons or because a review was lacking? Thanks Michi Guillaume D?flache wrote: > Some progress report as Simon showed some renewed interest in this > lately! ;) > Cf. > http://lists.wyona.org/pipermail/yanel-development/2009-December/004192.html > > > Guillaume D?flache a ?crit : >> Hi! >> >> As discussed with Simon some time ago (unfortunately no one took >> notes :(...) we would like to be able to choose the resource-type to >> use for a request by matching the value or presence of HTTP request >> parameters (ATM one can only match on the request URI). >> >> As far as Michi and I can remember, we then considered at least 2 >> options: >> >> >> *Option 1*: allow a syntax similar to "**?my-param-name=*" in >> map.rc-map files in "matcher" elements for the "pattern" attribute. >> >> Some issues: >> - most probably we want to ignore the order of the request parameters >> as they are written in the pattern, as anyway AFAIK the servlet spec >> does not define it >> - should we also match parameters passed through POST, albeit the >> syntax of the pattern could make use think it would only work for >> GET: Mich and I would say we should, and the servlet API makes that >> choice easier >> - what would "**" mean in the query string part? I'd suggest it >> should either throw some parsing exception, or match any other >> parameter that could also be present (would allow use to distinguish >> between the two cases "only these parameters" and "these parameters >> and some others we do not care about", although that might be >> somewhat counter-intuitive) > > Any opinion about these issues, esp. Simon? On the 3rd I'd personally > go for the "match any other parameter" solution. > > >> *Option 2*: allow full customization of the matching policy by >> introducing a new Java interface for it. >> (1st please note that #1 can readily be implemented independently of >> #2 but of course we'd rather put new functionality in the new places >> if possible.) > > I did some (unfinished) work on this, please review the attachment. > There is still some unfinished stuff, mainly around the TODO and XXX > markers, please ask me as they probably won't make any sense to anyone > else than me. > > >> This interface would be almost identical to the >> org.wyona.yanel.core.ResourceManager class's (minus the deprecated >> parts) and especially provide getResource(Environment environment, >> Realm realm, String path, ResourceConfiguration rc): having access to >> the environment should allow any future kind of matching imaginable >> (see Apache Cocoon for wild ideas! ;) ). >> I'd suggest to use a better name (*Manager is rather uninspiring): >> org.wyona.yanel.core.api.ResourceTypeMatcherV1 maybe? > > The current interface has the same name but provide > getResourceConfiguration(Environment environment, Realm realm, String > path) instead: indeed IMHO what we need to be configurable is only the > RC object selector, not a Resource selector (all Resource objects may > be instantiated in the same way for now, better not expose > classloading guts before we get our runtime-modularity story right). > > >> Then as 1st step we would have to reimplement >> org.wyona.yanel.core.ResourceManager using the new interface and >> still use it as the default for backward-compatibility. >> Then we would have to allow configuration of the concrete matching >> class. ATM this is done in the Yanel class, but Michi would like it to > > That's more or less what is done in the patch. > > >> be configurable per realm, and thanks to the way it's currently >> encapsulated there this is also possible only with some more >> deprecations (namely Yanel.getResourceManager). > > I did not tackle that yet. > > We may not need to change Yanel#getResourceManager or even > ResourceManager to do this, as ResourceManager#getResource has already > the realm as parameter. > Maybe the ResourceManager should/could become a registry of > ResourceTypeMatcherV1 objects for all realms, adn then we would only > need > ResourceManager#setResourceTypeMatcherForRealm(ResourceTypeMatcherV1 > matcher, Realm realm)??? But then maybe we would only need > ResourceTypeMatcherV1#getResourceConfiguration(Environment > environment, String path) without the realm parameter? > > Or maybe we should wait and do that in ResourceTypeMatcherV2? > > >> I'd also suggest we hide functionality actually in >> ResourceConfigurationMap in the concrete matcher implementations: the >> class only has static methods and needlessly expose mechanics. It also > > This still can/should be done once dust has settled on all things above. > >> needs changing because Michi would like to be able to parametrize the >> "map.rc-map" file name. > > > This will probably be left as an exercise to casual contributors! :P > > > Cheers, > Guillaume From guillaume.deflache at wyona.com Wed Dec 16 10:22:30 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Wed Dec 16 10:27:21 2009 Subject: [Yanel-dev] [HEADS UP] ResourceManager and ResourceConfigurationMap class may die soon; resource-types' URL matching (e.g. on request parameters) In-Reply-To: <4B289C60.8020109@wyona.com> References: <4A41DCEB.9000205@wyona.com> <4B197CFE.5080500@wyona.com> <4B289C60.8020109@wyona.com> Message-ID: <4B28A6D6.6080204@wyona.com> Hi! Michael Wechner schrieb: > Dear Guillaume > > I am currently reviewing your patch in order to commit it. > > What is the reason that we didn't commit long time ago? Any technical > reasons or because a review was lacking? As said in http://lists.wyona.org/pipermail/yanel-development/2009-December/004194.html[1] there are still TODO and XXX stuff to address in there. Also we should decide if we go for the interface I suggested and maybe postpone the per-realm interface to ResourceTypeMatcherV2. I am not sure I can find time to implement and play with the per-realm version so I would suggest we do not wait: as we will version the interface and ResourceManager is a class that should be OK. Cheers, Guillaume [1]: Any idea why the archived message is so garbled ATM?!? Maybe because it has a text attachment? From michael.wechner at wyona.com Wed Dec 16 22:41:14 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Dec 16 22:51:11 2009 Subject: [Yanel-dev] SitetreeDOMImpl or rather NodeDOMImpl has an issue re isCollection In-Reply-To: <4B27ACFA.4030605@wyona.com> References: <4B27ACFA.4030605@wyona.com> Message-ID: <4B2953FA.30205@wyona.com> Michael Wechner wrote: > Hi > > I just realized that the Sitetree/Node DOM implementation > > src/impl/java/org/wyona/yanel/impl/navigation/NodeDOMImpl.java > > has an issue re the isCollection()/isResource() method. It is based on > an XML, e.g. > > > > > > > > > > and when creating a new child and one should have to specify the node > type (either collection or resource), then > it's not clear what node type, because the method appendChild(Node) > has no such argument > and the methods isCollection() of the DOM implementation is just > checking if there children. > > Of course there is the workaround that if it is supposed to be a > collection, then create a child for this node, which > will make it implicitely a collection. But that's not very nice :-( > > Hence I would suggest to change the API by introducing a method > appendChild(Node, NodeType) I have fixed this now by changing appendChild(Node) to appendChild(Node, int) whereas int is for example Node.COLLECTION or Node.RESOURCE I have changed all dependencies which I am aware of and at least Hudson seems to be fine with it but strictly speaking I broke backwards compatibility re custom implementations if such existed. Please let me know if you have any problem with it. Thanks Michi > > WDYT? > > Thanks > > Michi From guillaume.deflache at wyona.com Thu Dec 17 10:37:27 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Thu Dec 17 10:53:38 2009 Subject: [Yanel-dev] SitetreeDOMImpl or rather NodeDOMImpl has an issue re isCollection In-Reply-To: <4B2953FA.30205@wyona.com> References: <4B27ACFA.4030605@wyona.com> <4B2953FA.30205@wyona.com> Message-ID: <4B29FBD7.6060203@wyona.com> Hi! Michael Wechner schrieb: > Michael Wechner wrote: >> Hi >> >> I just realized that the Sitetree/Node DOM implementation >> >> src/impl/java/org/wyona/yanel/impl/navigation/NodeDOMImpl.java >> >> has an issue re the isCollection()/isResource() method. It is based on >> an XML, e.g. >> >> >> >> >> >> >> >> >> >> and when creating a new child and one should have to specify the node >> type (either collection or resource), then >> it's not clear what node type, because the method appendChild(Node) >> has no such argument >> and the methods isCollection() of the DOM implementation is just >> checking if there children. >> >> Of course there is the workaround that if it is supposed to be a >> collection, then create a child for this node, which >> will make it implicitely a collection. But that's not very nice :-( >> >> Hence I would suggest to change the API by introducing a method >> appendChild(Node, NodeType) > > I have fixed this now by changing appendChild(Node) to appendChild(Node, > int) > > whereas int is for example Node.COLLECTION or Node.RESOURCE Why use an int instead of an enum? In case you wondered binary backward-compatibility rules of enums and their values are the same as those of classes and their methods, cf. http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#78657 Cheers, Guillaume From michael.wechner at wyona.com Thu Dec 17 10:59:02 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Dec 17 11:09:21 2009 Subject: [Yanel-dev] SitetreeDOMImpl or rather NodeDOMImpl has an issue re isCollection In-Reply-To: <4B29FBD7.6060203@wyona.com> References: <4B27ACFA.4030605@wyona.com> <4B2953FA.30205@wyona.com> <4B29FBD7.6060203@wyona.com> Message-ID: <4B2A00E6.7040702@wyona.com> Guillaume D?flache wrote: > Hi! > > Michael Wechner schrieb: >> Michael Wechner wrote: >>> Hi >>> >>> I just realized that the Sitetree/Node DOM implementation >>> >>> src/impl/java/org/wyona/yanel/impl/navigation/NodeDOMImpl.java >>> >>> has an issue re the isCollection()/isResource() method. It is based >>> on an XML, e.g. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> and when creating a new child and one should have to specify the >>> node type (either collection or resource), then >>> it's not clear what node type, because the method appendChild(Node) >>> has no such argument >>> and the methods isCollection() of the DOM implementation is just >>> checking if there children. >>> >>> Of course there is the workaround that if it is supposed to be a >>> collection, then create a child for this node, which >>> will make it implicitely a collection. But that's not very nice :-( >>> >>> Hence I would suggest to change the API by introducing a method >>> appendChild(Node, NodeType) >> >> I have fixed this now by changing appendChild(Node) to >> appendChild(Node, int) >> >> whereas int is for example Node.COLLECTION or Node.RESOURCE > > Why use an int instead of an enum? because src/core/java/org/wyona/yarep/core/Node.java also uses an int and to be honest I didn't think much about it ;-) What would be the advantage of enum? (Since we broke the backwards compatibility yesterday I would say we can break it once again today if there is a good reason to use enum) > In case you wondered binary backward-compatibility rules of enums and > their values are the same as those of classes and their methods, cf. > http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#78657 > I am not sure I understand. Can you explain this? Thanks Michi > > > Cheers, > Guillaume From guillaume.deflache at wyona.com Thu Dec 17 11:43:54 2009 From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=) Date: Thu Dec 17 11:48:39 2009 Subject: [Yanel-dev] SitetreeDOMImpl or rather NodeDOMImpl has an issue re isCollection In-Reply-To: <4B2A00E6.7040702@wyona.com> References: <4B27ACFA.4030605@wyona.com> <4B2953FA.30205@wyona.com> <4B29FBD7.6060203@wyona.com> <4B2A00E6.7040702@wyona.com> Message-ID: <4B2A0B6A.2040703@wyona.com> Michael Wechner schrieb: > Guillaume D?flache wrote: >> Hi! >> >> Michael Wechner schrieb: >>> [...] >>> I have fixed this now by changing appendChild(Node) to >>> appendChild(Node, int) >>> >>> whereas int is for example Node.COLLECTION or Node.RESOURCE >> >> Why use an int instead of an enum? > > because src/core/java/org/wyona/yarep/core/Node.java also uses an int > and to be honest I didn't think much about it ;-) > > What would be the advantage of enum? (Since we broke the backwards > compatibility yesterday I would say we can break > it once again today if there is a good reason to use enum) Mainly more type safety, hence more guidance for the developer, see : > In prior releases, the standard way to represent an enumerated type was the int Enum pattern: > > // int Enum Pattern - has severe problems! > public static final int SEASON_WINTER = 0; > public static final int SEASON_SPRING = 1; > public static final int SEASON_SUMMER = 2; > public static final int SEASON_FALL = 3; > > This pattern has many problems, such as: > > * Not typesafe - Since a season is just an int you can pass in any other int value where a season is required, or add two seasons together (which makes no sense). > * No namespace - You must prefix constants of an int enum with a string (in this case SEASON_) to avoid collisions with other int enum types. > * Brittleness - Because int enums are compile-time constants, they are compiled into clients that use them. If a new constant is added between two existing constants or the order is changed, clients must be recompiled. If they are not, they will still run, but their behavior will be undefined. > * Printed values are uninformative - Because they are just ints, if you print one out all you get is a number, which tells you nothing about what it represents, or even what type it is. > > So when should you use enums? Any time you need a fixed set of constants. That includes natural enumerated types (like the planets, days of the week, and suits in a card deck) as well as other sets where you know all possible values at compile time, such as choices on a menu, rounding modes, command line flags, and the like. It is not necessary that the set of constants in an enum type stay fixed for all time. The feature was specifically designed to allow for binary compatible evolution of enum types. Also instead of C-style bitmasks to encode capabilities, e.g. if (VERSIONABLEV1 & MODIFIABLEV2) {...} ;) one should likewise use http://java.sun.com/javase/6/docs/api/java/util/EnumSet.html instead. >> In case you wondered binary backward-compatibility rules of enums and >> their values are the same as those of classes and their methods, cf. >> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#78657 >> > > I am not sure I understand. Can you explain this? To sum it up you can add new values, reorder them without breaking backward-compatibility. I also stumbled upon a nice and more summarized reference: http://wiki.eclipse.org/Evolving_Java-based_APIs_2 (non-normative contrary to the Java Language Specification link given above) The rest of the series is IMHO also a nice-to-read about the other aspects of compatibility: Part I: > * 1 API Java Elements > * 2 API Prime Directive > * 3 Achieving API Contract Compatibility > o 3.1 Example 1 - Changing a method postcondition > o 3.2 Example 2 - Changing a method precondition > o 3.3 Example 3 - Changing a field invariant > o 3.4 Example 4 - Adding an API method > o 3.5 General Rules for Contract Compatibility > * 4 Achieving API Binary Compatibility > * 5 Other Notes http://wiki.eclipse.org/Evolving_Java-based_APIs Part III: > * 1.1 Data Compatibility > * 1.2 Standard Workarounds > o 1.2.1 Deprecate and Forward > o 1.2.2 Start over in a New Package > o 1.2.3 Adding an Argument > o 1.2.4 "2" Convention > o 1.2.5 COM Style > o 1.2.6 Making Obsolete Hook Methods Final > * 1.3 Defective API Specifications > * 1.4 A Word about Source Code Incompatibilities > * 1.5 Java Reflection http://wiki.eclipse.org/Evolving_Java-based_APIs_3 HTH From michael.wechner at wyona.com Thu Dec 17 16:20:43 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Dec 17 16:30:36 2009 Subject: [Yanel-dev] SitetreeDOMImpl or rather NodeDOMImpl has an issue re isCollection In-Reply-To: <4B2A0B6A.2040703@wyona.com> References: <4B27ACFA.4030605@wyona.com> <4B2953FA.30205@wyona.com> <4B29FBD7.6060203@wyona.com> <4B2A00E6.7040702@wyona.com> <4B2A0B6A.2040703@wyona.com> Message-ID: <4B2A4C4B.4090708@wyona.com> Guillaume D?flache wrote: > Michael Wechner schrieb: >> Guillaume D?flache wrote: >>> Hi! >>> >>> Michael Wechner schrieb: >>>> [...] >>>> I have fixed this now by changing appendChild(Node) to >>>> appendChild(Node, int) >>>> >>>> whereas int is for example Node.COLLECTION or Node.RESOURCE >>> >>> Why use an int instead of an enum? >> >> because src/core/java/org/wyona/yarep/core/Node.java also uses an int >> and to be honest I didn't think much about it ;-) >> >> What would be the advantage of enum? (Since we broke the backwards >> compatibility yesterday I would say we can break >> it once again today if there is a good reason to use enum) > > Mainly more type safety, hence more guidance for the developer, see > : >> In prior releases, the standard way to represent an enumerated type >> was the int Enum pattern: >> >> // int Enum Pattern - has severe problems! >> public static final int SEASON_WINTER = 0; >> public static final int SEASON_SPRING = 1; >> public static final int SEASON_SUMMER = 2; >> public static final int SEASON_FALL = 3; >> >> This pattern has many problems, such as: >> >> * Not typesafe - Since a season is just an int you can pass in >> any other int value where a season is required, or add two seasons >> together (which makes no sense). >> * No namespace - You must prefix constants of an int enum with a >> string (in this case SEASON_) to avoid collisions with other int enum >> types. >> * Brittleness - Because int enums are compile-time constants, >> they are compiled into clients that use them. If a new constant is >> added between two existing constants or the order is changed, clients >> must be recompiled. If they are not, they will still run, but their >> behavior will be undefined. >> * Printed values are uninformative - Because they are just ints, >> if you print one out all you get is a number, which tells you nothing >> about what it represents, or even what type it is. >> So when should you use enums? Any time you need a fixed set of >> constants. That includes natural enumerated types (like the planets, >> days of the week, and suits in a card deck) as well as other sets >> where you know all possible values at compile time, such as choices >> on a menu, rounding modes, command line flags, and the like. It is >> not necessary that the set of constants in an enum type stay fixed >> for all time. The feature was specifically designed to allow for >> binary compatible evolution of enum types. > > Also instead of C-style bitmasks to encode capabilities, e.g. if > (VERSIONABLEV1 & MODIFIABLEV2) {...} ;) one should likewise use > http://java.sun.com/javase/6/docs/api/java/util/EnumSet.html instead. > > >>> In case you wondered binary backward-compatibility rules of enums >>> and their values are the same as those of classes and their methods, >>> cf. >>> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#78657 >>> >> >> I am not sure I understand. Can you explain this? > > To sum it up you can add new values, reorder them without breaking > backward-compatibility. > > > I also stumbled upon a nice and more summarized reference: > http://wiki.eclipse.org/Evolving_Java-based_APIs_2 (non-normative > contrary to the Java Language Specification link given above) > > The rest of the series is IMHO also a nice-to-read about the other > aspects of compatibility: > Part I: >> * 1 API Java Elements >> * 2 API Prime Directive >> * 3 Achieving API Contract Compatibility >> o 3.1 Example 1 - Changing a method postcondition >> o 3.2 Example 2 - Changing a method precondition >> o 3.3 Example 3 - Changing a field invariant >> o 3.4 Example 4 - Adding an API method >> o 3.5 General Rules for Contract Compatibility >> * 4 Achieving API Binary Compatibility >> * 5 Other Notes > http://wiki.eclipse.org/Evolving_Java-based_APIs > Part III: >> * 1.1 Data Compatibility >> * 1.2 Standard Workarounds >> o 1.2.1 Deprecate and Forward >> o 1.2.2 Start over in a New Package >> o 1.2.3 Adding an Argument >> o 1.2.4 "2" Convention >> o 1.2.5 COM Style >> o 1.2.6 Making Obsolete Hook Methods Final >> * 1.3 Defective API Specifications >> * 1.4 A Word about Source Code Incompatibilities >> * 1.5 Java Reflection > http://wiki.eclipse.org/Evolving_Java-based_APIs_3 > > HTH sounds very reasonable to me. Thanks very much for this information. Will try to improve it shortly. Cheers Michi From michael.wechner at wyona.com Tue Dec 22 22:50:28 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 22 23:00:33 2009 Subject: [Yanel-dev] SendMail utility class Message-ID: <4B313F24.3040601@wyona.com> Hi I have noticed that the class src/java/org/wyona/yanel/impl/resources/contactform/SendMail.java is being used within the forget-password resource type and the SendMail class seems to me very generic and hence it might make sense to move into some more common lib, e.g. the wyona-commons lib. WDYT? Thanks Michi From michael.wechner at wyona.com Mon Dec 28 10:25:12 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Mon Dec 28 10:36:27 2009 Subject: [Yanel-dev] Modifying the Yanel slogan "everything is content" Message-ID: <4B387978.3050300@wyona.com> Hi I would like to slightly modify the slogan from "everything is content" to "everything is related content is everything", and hence I am looking for the source of http://127.0.0.1:8080/yanel/yanel-website/img/everything_is_content.png or rather src/realms/yanel-website/content/img/everthing_is_content.png How was that image generated? Thanks Michi From simon at 333.ch Mon Dec 28 23:29:07 2009 From: simon at 333.ch (simon) Date: Mon Dec 28 23:40:14 2009 Subject: [Yanel-dev] Modifying the Yanel slogan "everything is content" In-Reply-To: <4B387978.3050300@wyona.com> References: <4B387978.3050300@wyona.com> Message-ID: <4B393133.7040305@333.ch> Michael Wechner schrieb: > Hi > > I would like to slightly modify the slogan from "everything is = > content" to "everything is related content is everything", > and hence I am looking for the source of > > http://127.0.0.1:8080/yanel/yanel-website/img/everything_is_content.png > > or rather > > src/realms/yanel-website/content/img/everthing_is_content.png > > How was that image generated? with inkscape. i will attach the svg to the mail. BTW i liked the old slogan more. cheers simon > > Thanks > > Michi -------------- next part -------------- A non-text attachment was scrubbed... Name: yanel_logo.svg Type: image/svg+xml Size: 135837 bytes Desc: not available Url : http://lists.wyona.org/pipermail/yanel-development/attachments/200912= 28/6f320b27/yanel_logo-0001.svg From michael.wechner at wyona.com Tue Dec 29 08:25:56 2009 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Dec 29 08:38:10 2009 Subject: [Yanel-dev] Modifying the Yanel slogan "everything is content" In-Reply-To: <4B393133.7040305@333.ch> References: <4B387978.3050300@wyona.com> <4B393133.7040305@333.ch> Message-ID: <4B39AF04.6010508@wyona.com> simon wrote: > Michael Wechner schrieb: >> Hi >> >> I would like to slightly modify the slogan from "everything is >> content" to "everything is related content is everything", >> and hence I am looking for the source of >> >> http://127.0.0.1:8080/yanel/yanel-website/img/everything_is_content.png >> >> or rather >> >> src/realms/yanel-website/content/img/everthing_is_content.png >> >> How was that image generated? > with inkscape. i will attach the svg to the mail. thanks very much. I will add it to SVN parallel to the png > > BTW i liked the old slogan more. I can hear you, but I think the new slogan puts an emphasis on that not just the content itself, but the relations in between the content are just as important and of course that the relations are content themselves. I think this is very important and hence I don't just consider it as a slogan, but rather as "goal" for Yanel. Also you can read it ("everything is related content is everything") in many ways, e.g. - everything is related - everything it related content - related content is everything - content is everything and visually one can build a loop (or a Moebius strip) with it. And we can make a page explaining this to people ;-) Because of the above said I hope you will also start to like it :-) Thanks Michi > > cheers simon >> >> Thanks >> >> Michi >