From guillaume.deflache at wyona.com Tue Jun 1 13:48:55 2010 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Tue Jun 1 14:02:23 2010 Subject: [Yanel-dev] serialization & RC problems Message-ID: <4C04F3A7.60605@wyona.com> Hi! I am trying to serialize a page in XHTML Strict in Yanel using only RC configuration like in: > > yes > html > UTF-8 > > The exact doctype I need is: So far I only had been able to get: This confuses Firefox and the page display gets all messed up. Yanel's custom serializer implementation wrongly uses the 'method' serializer output property as the root element name in the doctype declaration. cf. http://svn.wyona.com/repos/public/yanel/trunk/src/core/java/org/wyona/yanel/core/serialization/XMLSerializer.java and look for'"method"' there. Because of that, I tried to set the 'method' serializer output property by hand using the RC file (see above): it didn't work because it is not read in ConfigurableViewDescriptor#configure (cf. ), and probably rightly so because the serializer key implies which method should be used. So ATM there is no way to set the XHTML doctype correctly using only RC configuration. (Note: it can be done by doing some method overloading in Java though, but that's a lot more work). I think the doctype declaration should really only be written when the root element is known so that it is always correct regardless of the required output method. WDYT? Also previously I tried to set public and system doctype identifiers manually in the RC, and it did not work for the system one: I now know why: there is a typo in , look for "doctype-sytem" there! HTH, Guillaume From michael.wechner at wyona.com Tue Jun 1 14:03:51 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 1 14:20:39 2010 Subject: [Yanel-dev] Fixed the usage of source-mime-type property Message-ID: <4C04F727.3060008@wyona.com> Hi I have noticed the create method of the XML resource does not use the source-mime-type property src/realms/from-scratch-realm-template/res-configs/create-new-page.html.yanel-rc whereas I have fixed this now within src/resources/xml/src/java/org/wyona/yanel/impl/resources/XMLResource.java and hence if this property is set, then such new nodes will also be indexed according to their mime types. Cheers Michi From bugzilla at wyona.com Tue Jun 1 15:33:40 2010 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Tue Jun 1 15:33:42 2010 Subject: [Yanel-dev] [Bug 6573] (vfs) when deleting a node it will not remove the node from the search index. Message-ID: <20100601133340.73B6F10CA2E@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6573 ------- Comment #3 from michael.wechner@wyona.org 2010-06-01 14:25 ------- Index: src/impl/java/org/wyona/yarep/impl/repo/vfs/VirtualFileSystemNode.java =================================================================== --- src/impl/java/org/wyona/yarep/impl/repo/vfs/VirtualFileSystemNode.java (revision 50053) +++ src/impl/java/org/wyona/yarep/impl/repo/vfs/VirtualFileSystemNode.java (working copy) @@ -514,7 +514,10 @@ public void delete() throws RepositoryException { deleteRec(this); } - + + /** + * Delete node recursively + */ protected void deleteRec(Node node) throws RepositoryException { Node[] children = node.getNodes(); for (int i=0; i < children.length; i++) { @@ -532,6 +535,13 @@ throw new RepositoryException("Could not delete node: " + node.getPath() + ": " + e.toString(), e); } + + // INFO: Delete node from fulltext search index + try { + getRepository().getIndexer().removeFromIndex(this); + } catch(Exception e) { + log.error(e, e); + } } /** -- 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 Tue Jun 1 15:35:21 2010 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Tue Jun 1 15:35:25 2010 Subject: [Yanel-dev] [Bug 6573] (vfs) when deleting a node it will not remove the node from the search index. Message-ID: <20100601133521.C2F1310CA3F@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6573 michael.wechner@wyona.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED -- 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 Jun 1 16:00:47 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 1 16:20:59 2010 Subject: [Yanel-dev] Registration form Message-ID: <4C05128F.6090201@wyona.com> Hi A friend of mine recently pointed me to the following "registration form" http://www.lukew.com/ff/entry.asp?1007 which I think is a nice way of doing it differently and may really increases the chances that people are filling out forms with less hassle. Cheers Michael From guillaume.deflache at wyona.com Tue Jun 1 17:30:14 2010 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Tue Jun 1 17:43:53 2010 Subject: [Yanel-dev] XMLResource is not (quite) substituable to BasicXMLResource Message-ID: <4C052786.30605@wyona.com> Hi! On my current project I started to extend BasicXMLResource for my own needs, and I later realized XMLResource would also need the same extensions. XMLResource (XMLR) inherits from BasicXMLResource (BXMLR) but is not quite compatible with the latter's initial contract: Thanks to Eclipse's warnings I can see that only 3 methods from BXMLR are overridden in XMLR: #getView(String viewId), #getSize(), #getMimeType(String viewId) and the other code "only" implements other Yanel capability interfaces: ModifiableV2, VersionableV2, CreatableV2, IntrospectableV1, TranslatableV1, WorkflowableV1. So AFAICU it seems I should also be able to use XMLResource instead of BasicXMLResource when I do not need the additional interfaces' capabilities, as long as the overridden methods have compatible semantics. #getSize() is OK: the code is the same apart from comments #getMimeType(String viewId) *looks* OK, the code of XMLR looks like a duplicate of BXMLR's with more features added afterwards, so it's probably compatible too #getView(String viewId) is spreaded out in more methods in XMLR than in BXMLR, it could be fully compatible but sadly it never calls super.getContentXML(String viewId), it directly calls some code equivalent to BXMLR's getRealm().getRepository().getNode(getPath()).getInputStream() code. Summing up, if one wants to override getContentXML(String viewId) as is often done to implement views, one must refrain from using XMLR's other useful stuff, like versioning, workflow support, translation support, editing support, etc. which is a shame IMHO. I think XMLResource can easily be refactored to correct this. Any opinion on that? Cheers, Guillaume From guillaume.deflache at wyona.com Tue Jun 1 17:53:41 2010 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Tue Jun 1 18:07:09 2010 Subject: [Yanel-dev] customizing Yanel serialization formats: XHTML Strict Transitional, HTML Strict, (X)HTML 5, JSON, ... Message-ID: <4C052D05.3000701@wyona.com> Hi! Michi asked me to document the ways to customize serialization serialization in Yanel, so here it is. This can be done at two levels: - in the RC files - in Java code First the following formats already exist in Yanel, so no need for customization to use them: XHTML Strict, HTML Transitional, XML, text. To implement the following formats the following output properties must be set: *HTML Strict*: set serializer key to HTML_TRANSITIONAL to get the base HTML properties right, then force the public doctype to the standard HTML Strict value: "-//W3C//DTD HTML 4.01//EN", the system doctype may be left alone as AFAIK mainstream browsers do not care and anyway Yanel still has a bug on that, see comment example below) Example: ---8<--- [...] [...] text/html

-//W3C//DTD HTML 4.01//EN

http://www.w3.org/TR/html4/strict.dtd

[...] ---8<--- *XHTML Transitional*: set serializer key to XHTML_STRICT to get the base XML properties right, then force the public doctype to the standard XHTML Transitional value: "-//W3C//DTD XHTML 1.0 Transitional//EN", the system doctype may remain wrong (same as above). Sadly this alone does not quite work yet because of one Yanel bug and one missing workaround, see http://lists.wyona.org/pipermail/yanel-development/2010-June/004840.html This can however been done in Java code by overriding #getViewDescriptor(String viewId) in every resource-type that needs the right format, using the following helper code example: ---8<--- /** * Reconfigure the view to use XHTML 1.0 strict. */ private static final void reconfigureViewDescriptor(ConfigurableViewDescriptor cvd) { cvd.setMimeType("text/html"); cvd.setSerializerKey(SerializerFactory.XHTML_STRICT_KEY); Properties serializerProperties = new Properties(); serializerProperties.setProperty(OutputKeys.INDENT, "no"); serializerProperties.setProperty(OutputKeys.OMIT_XML_DECLARATION, "yes"); serializerProperties.setProperty(OutputKeys.ENCODING, "UTF-8"); serializerProperties.setProperty(OutputKeys.DOCTYPE_PUBLIC, "-//W3C//DTD XHTML 1.0 Transitional//EN"); serializerProperties.setProperty(OutputKeys.DOCTYPE_SYSTEM, "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"); serializerProperties.setProperty(OutputKeys.METHOD, "html"); //XXX HACK: needed to force root element name in doctype declaration, see http://lists.wyona.org/pipermail/yanel-development/2010-June/004840.html cvd.setSerializerProperties(serializerProperties); } ---8<--- Other interesting format may be: JSON, HTML 5, XHTML 5, etc. HTH, Guillaume From mehmet.birgi at wyona.com Wed Jun 2 11:16:22 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Wed Jun 2 11:31:42 2010 Subject: [Yanel-dev] Tika library Message-ID: Hi I have just realized that in the Tika library in our maven repository (.m2/repository/org/apache/tika), there are 2 versions of Tika: [11:09] ~/.m2/repository/org/apache/tika $ find . -name *.jar ./tika/0.1-incubating/tika-0.1-incubating.jar ./tika-core/0.4/tika-core-0.4.jar ./tika-parsers/0.4/tika-parsers-0.4.jar I guess that this could cause some problems, as those different jar file versions contain the same classes, e.g. org/apache/tika/metadata/Metadata.class org/apache/tika/parser/Parser.class which are used within Yarep/Yanel. I am not sure how to remedy this, though, any help? Cheers, memo -- Mehmet Birgi www.wyona.com From michael.wechner at wyona.com Wed Jun 2 11:28:20 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 2 11:43:20 2010 Subject: [Yanel-dev] Tika library In-Reply-To: References: Message-ID: <4C062434.9040803@wyona.com> Mehmet Birgi wrote: > Hi > > I have just realized that in the Tika library in our maven repository > (.m2/repository/org/apache/tika), there are 2 versions of Tika: > > [11:09] ~/.m2/repository/org/apache/tika $ find . -name *.jar > ./tika/0.1-incubating/tika-0.1-incubating.jar > ./tika-core/0.4/tika-core-0.4.jar > ./tika-parsers/0.4/tika-parsers-0.4.jar > that's not a problem. Have a look at the Yanel libs dir, e.g. ls local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/lib/tika- tika-core-0.4.jar tika-parsers-0.4.jar Cheers Michi > I guess that this could cause some problems, as those different jar > file versions contain the same classes, e.g. > > org/apache/tika/metadata/Metadata.class > org/apache/tika/parser/Parser.class > > which are used within Yarep/Yanel. I am not sure how to remedy this, > though, any help? > > Cheers, > > memo > > > From mehmet.birgi at wyona.com Wed Jun 2 11:33:30 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Wed Jun 2 11:49:01 2010 Subject: [Yanel-dev] Tika library In-Reply-To: <4C062434.9040803@wyona.com> References: <4C062434.9040803@wyona.com> Message-ID: On Wed, Jun 2, 2010 at 11:28 AM, Michael Wechner wrote: > Mehmet Birgi wrote: >> >> Hi >> >> I have just realized that in the Tika library in our maven repository >> (.m2/repository/org/apache/tika), there are 2 versions of Tika: >> >> [11:09] ~/.m2/repository/org/apache/tika $ find . -name *.jar >> ./tika/0.1-incubating/tika-0.1-incubating.jar >> ./tika-core/0.4/tika-core-0.4.jar >> ./tika-parsers/0.4/tika-parsers-0.4.jar >> > > that's not a problem. Have a look at the Yanel libs dir, e.g. > > ls local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/lib/tika- > tika-core-0.4.jar ? ? tika-parsers-0.4.jar oh, OK, sorry thanks, memo From bruno.vonrotz at wyona.com Wed Jun 2 14:58:35 2010 From: bruno.vonrotz at wyona.com (Bruno von Rotz) Date: Wed Jun 2 15:13:35 2010 Subject: [Yanel-dev] Search requirements Message-ID: <4C06557B.5080909@wyona.com> An HTML attachment was scrubbed... URL: http://lists.wyona.org/pipermail/yanel-development/attachments/20100602/79e3dfb0/attachment.htm From michael.wechner at wyona.com Wed Jun 2 15:50:37 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 2 16:05:35 2010 Subject: [Yanel-dev] Search requirements In-Reply-To: <4C06557B.5080909@wyona.com> References: <4C06557B.5080909@wyona.com> Message-ID: <4C0661AD.403@wyona.com> Bruno von Rotz wrote: > While doing the implementation of a new website we have encountered > some use cases that are not optimally supported by the "on board" > search of Yanel. > Here an example: > Metadata1: Date, e.g. 2001/01/01 or 2010/06/02 > Metadata2: Countries, e.g. France, Germany, UK, Australia, Chile, > Switzerland, Austria > Search example: > Find all content that contains "Prince of Persia" and has > metadata1<2010/06/01 and metadata2 Switzerland, Germany or Austria. > > The current implementation allows either to search in the fulltext > with a query string or to search for one specific attribute, or to > scope down to a specific attribute. > Any combination is not really supported. > > The ideal would be that either some type of SQL syntax maybe we could re-use http://code.google.com/p/lucene-sql/ Cheers Michi > or XQuery syntax is supported and allows to address specific > attribute/metadata and fulltext. > > My 5 cents. > > Bruno > From michael.wechner at wyona.com Wed Jun 2 16:08:52 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 2 16:23:51 2010 Subject: [Yanel-dev] Search requirements In-Reply-To: <4C0661AD.403@wyona.com> References: <4C06557B.5080909@wyona.com> <4C0661AD.403@wyona.com> Message-ID: <4C0665F4.4090401@wyona.com> Michael Wechner wrote: > Bruno von Rotz wrote: >> While doing the implementation of a new website we have encountered >> some use cases that are not optimally supported by the "on board" >> search of Yanel. >> Here an example: >> Metadata1: Date, e.g. 2001/01/01 or 2010/06/02 >> Metadata2: Countries, e.g. France, Germany, UK, Australia, Chile, >> Switzerland, Austria >> Search example: >> Find all content that contains "Prince of Persia" and has >> metadata1<2010/06/01 and metadata2 Switzerland, Germany or Austria. >> >> The current implementation allows either to search in the fulltext >> with a query string or to search for one specific attribute, or to >> scope down to a specific attribute. >> Any combination is not really supported. >> >> The ideal would be that either some type of SQL syntax > > maybe we could re-use > > http://code.google.com/p/lucene-sql/ also see JCR query object model http://www.day.com/maven/jdiff-jcr1-jcr2/jcr-2.0/javax/jcr/query/qom/package-summary.html Cheers Michi > > > Cheers > > Michi >> or XQuery syntax is supported and allows to address specific >> attribute/metadata and fulltext. >> >> My 5 cents. >> >> Bruno >> > From bruno.vonrotz at wyona.com Wed Jun 2 17:06:17 2010 From: bruno.vonrotz at wyona.com (Bruno von Rotz) Date: Wed Jun 2 17:21:16 2010 Subject: [Yanel-dev] Search requirements In-Reply-To: <4C0665F4.4090401@wyona.com> References: <4C06557B.5080909@wyona.com> <4C0661AD.403@wyona.com> <4C0665F4.4090401@wyona.com> Message-ID: <4C067369.70309@wyona.com> here's an example done in pseudo SQL: Select * where "prince of persia" IN FULLTEXT and METADATA1 < "2010/06/01" and ( METADATA2 equals "Switzerland", or METADATA2 equals "Germany" or METADATA2 equals "Austria" ) Is this understandable. Bruno Michael Wechner schrieb: > Michael Wechner wrote: >> Bruno von Rotz wrote: >>> While doing the implementation of a new website we have encountered >>> some use cases that are not optimally supported by the "on board" >>> search of Yanel. >>> Here an example: >>> Metadata1: Date, e.g. 2001/01/01 or 2010/06/02 >>> Metadata2: Countries, e.g. France, Germany, UK, Australia, Chile, >>> Switzerland, Austria >>> Search example: >>> Find all content that contains "Prince of Persia" and has >>> metadata1<2010/06/01 and metadata2 Switzerland, Germany or Austria. >>> >>> The current implementation allows either to search in the fulltext >>> with a query string or to search for one specific attribute, or to >>> scope down to a specific attribute. >>> Any combination is not really supported. >>> >>> The ideal would be that either some type of SQL syntax >> >> maybe we could re-use >> >> http://code.google.com/p/lucene-sql/ > > also see JCR query object model > > http://www.day.com/maven/jdiff-jcr1-jcr2/jcr-2.0/javax/jcr/query/qom/package-summary.html > > > Cheers > > Michi >> >> >> Cheers >> >> Michi >>> or XQuery syntax is supported and allows to address specific >>> attribute/metadata and fulltext. >>> >>> My 5 cents. >>> >>> Bruno >>> >> > -- ______________________________ Bruno von Rotz WYONA Hardstrasse 219 CH-8005 Z?rich Switzerland P: +41 44 272 91 61 F: +41 44 272 91 62 skype: wyona-switzerland email: bruno.vonrotz@wyona.com www.wyona.com From michael.wechner at wyona.com Thu Jun 3 00:55:46 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Jun 3 01:10:51 2010 Subject: [Yanel-dev] Upgrading to Lucene 2.9.2 or 3.0.1 Message-ID: <4C06E172.3090403@wyona.com> Hi We are currently using Lucene 2.2.0 which is rather "old" and I think we should at least upgrade to Lucene 2.9.2, whereas my tests so far show that this should be possible without a problem. Upgrading to 3.0.1 is rather an issues, because it does not seem to be backwards compatible on an API level, whereas index wise I am not sure. But anyway we need to think how to upgrade at some later stage ... Thanks Michi From michael.wechner at wyona.com Thu Jun 3 01:15:58 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Jun 3 01:34:36 2010 Subject: [Yanel-dev] Upgrading to Lucene 2.9.2 or 3.0.1 In-Reply-To: <4C06E172.3090403@wyona.com> References: <4C06E172.3090403@wyona.com> Message-ID: <4C06E62E.6060007@wyona.com> Michael Wechner wrote: > Hi > > We are currently using Lucene 2.2.0 which is rather "old" and I think > we should at least upgrade to Lucene 2.9.2, > whereas my tests so far show that this should be possible without a > problem. > > Upgrading to 3.0.1 is rather an issues, because it does not seem to be > backwards compatible on an API level, > whereas index wise I am not sure. also see http://lucene.apache.org/java/3_0_0/changes/Changes.html Cheers Michi > > But anyway we need to think how to upgrade at some later stage ... > > Thanks > > Michi From michael.wechner at wyona.com Thu Jun 3 09:10:03 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Jun 3 09:26:46 2010 Subject: [Yanel-dev] Upgrading to Lucene 2.9.2 or 3.0.1 In-Reply-To: <4C06E62E.6060007@wyona.com> References: <4C06E172.3090403@wyona.com> <4C06E62E.6060007@wyona.com> Message-ID: <4C07554B.9030503@wyona.com> Michael Wechner wrote: > Michael Wechner wrote: >> Hi >> >> We are currently using Lucene 2.2.0 which is rather "old" and I think >> we should at least upgrade to Lucene 2.9.2, >> whereas my tests so far show that this should be possible without a >> problem. btw, beside Yarep the Yanel nutch resource also has pointer to 2.2.0 src/contributions/resources/nutch/src/build/dependencies.xml I will document this, but in the long run we should try to get rid of this "redundant" dependency. Cheers Michi >> >> Upgrading to 3.0.1 is rather an issues, because it does not seem to >> be backwards compatible on an API level, >> whereas index wise I am not sure. > > also see > > http://lucene.apache.org/java/3_0_0/changes/Changes.html > > Cheers > > Michi >> >> But anyway we need to think how to upgrade at some later stage ... >> >> Thanks >> >> Michi > From michael.wechner at wyona.com Thu Jun 3 23:21:18 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Jun 3 23:36:40 2010 Subject: [Yanel-dev] Replacing SVN with Mecurial Message-ID: <4C081CCE.9080808@wyona.com> Hi We had recently some internal discussions in order to replace Subversion with Mecurial, whereas we would of course still offer Subversion access, but just "read-only". The reason to use Mecurial is that we believe that this will allow us to better collaborate with "YOU" :-) We are currently setting up some test environments to get our hands dirty and nothing is carved in stone yet. But anyhow we would very much appreciate your feedback and if you think this is a good or bad idea. Thanks Michi From michael.wechner at wyona.com Mon Jun 7 14:34:54 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Mon Jun 7 14:50:01 2010 Subject: [Yanel-dev] Yanel user resource refactored Message-ID: <4C0CE76E.9000605@wyona.com> Hi I have refactored (or rather replaced) the yanel user resource src/contributions/resources/yanel-user/src/java/org/wyona/yanel/impl/resources/YanelUserResource.java by src/contributions/resources/yanel-user/src/java/org/wyona/yanel/impl/resources/yaneluser/EditYanelUserProfileResource.java by using the BasicXMLResource. So far all my tests are fine, but I have noticed that the YanelUserResource.java also implemented functionality such as - deleting a user - adding user to a group - etc. which is missing from the new version, but I don't see any code which this has been used, because actually this is already covered by the resource src/resources/user-mgmt/ Please let me know in case you notice any strange behaviour and if so we can switch back very quickly within src/contributions/resources/yanel-user/resource.xml Thanks Michi From michael.wechner at wyona.com Mon Jun 7 15:48:53 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Mon Jun 7 16:04:01 2010 Subject: [Yanel-dev] Unset the user language Message-ID: <4C0CF8C5.8020906@wyona.com> Hi The user interface currently has the two methods: User.getLanguage() User.setLanguage(String) but I am now dealing with a usecase where one wants to unset the language, such that again the browser rules. One possibility would be to do this implicitely, e.g. User.setLanguage(null) but I am concerned that this could also happen in case of an error or to introduce a new method, e.g. User.unsetLanguage() WDYT? Thanks Michi From guillaume.deflache at wyona.com Wed Jun 9 10:19:07 2010 From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=) Date: Wed Jun 9 10:32:23 2010 Subject: [Yanel-dev] [FYI] 'image/pjpeg' & 'image/x-png' pseudo MIME-types and how to work around them Message-ID: <4C0F4E7B.5010201@wyona.com> Hi! When uploading JPEGs using Internet Explorer, one often comes across the following problem: some images are sent by the browser with the Content-Type set to 'image/pjpeg' which is not an official (i.e. IANA-registered) MIME-type. As usually one only rightfully tests for 'image/jpeg', these JPEGs usually get rejected as being in an unkonwn format. The workaround is to test for this abnormal MIME-type and when possible reset it to 'image/jpeg' ASAP, or at least handle it as a regular JPEG. This MIME-type was hacked as a kind of weak copyright protection measure, and only occurs when the image has embedded copyright and/or author metadata, cf. http://www.evolve.co.nz/how-to-fix-a-pjpeg-image-upload-error.html for the details. Along the same lines old versions of Internet Explorer still uses the non-standard 'image/x-png' instead of the standard 'image/x-png'. It may make sense to try to filter both of these in the Yanel servlet filter, as we already decorate some methods related to upload there IIRC, to solve these problems once and for all for all Yanel-based applications. Microsoft kind of acknowledges these problems in . HTH, Guillaume From michael.wechner at wyona.com Sun Jun 13 17:49:22 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Sun Jun 13 18:06:20 2010 Subject: [Yanel-dev] Two versions of JTidy Message-ID: <4C14FE02.4050000@wyona.com> Hi I just noticed that we have two versions of jtidy local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/lib/jtidy-8.0-20060801.131059-3.jar local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/lib/jtidy-r8-20060801.jar Any idea which one is the prefered one? Thanks Michi From michael.wechner at wyona.com Sun Jun 13 21:43:27 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Sun Jun 13 22:02:04 2010 Subject: [Yanel-dev] Using the XML Resource as "reverse proxy" Message-ID: <4C1534DF.80902@wyona.com> Hi I have implemented/enhanced by various protocols and in particular http into the XML resource, for example: whereas the resource is doing a well-formedness check and if not well-formed then it uses JTidy. It seems to work very fine so far and is one step into the direction of a reverse proxy, whereas the following items definitely need to be implemented first: - session handling - URL rewriting Btw, it might be interesting to have a look at http://www.sitemesh.org/ http://www.kuligowski.pl/java/decorating-php-content-with-sitemesh,6A and also http://j2ep.sourceforge.net/ Cheers Michi From michael.wechner at wyona.com Tue Jun 15 16:18:42 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 15 16:34:12 2010 Subject: [Yanel-dev] Hudson fails because of new YanelUser resource implementation Message-ID: <4C178BC2.2010805@wyona.com> Hi Something does not work anymore within src/contributions/resources/yanel-user/src/test/htmlunit/org/wyona/yanel/impl/resources/YanelUserResourceWebTest.java#testAuthenticationInPasswordUpdate() whereas otherwise I have resolved all issues. I have commented this method for the moment such that the build should work again, but I am currently trying to fix this method as well. Cheers Michi From michael.wechner at wyona.com Wed Jun 16 10:00:52 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 16 10:16:13 2010 Subject: [Yanel-dev] Hudson fails because of new YanelUser resource implementation In-Reply-To: <4C178BC2.2010805@wyona.com> References: <4C178BC2.2010805@wyona.com> Message-ID: <4C1884B4.4050301@wyona.com> Michael Wechner wrote: > Hi > > Something does not work anymore within > > src/contributions/resources/yanel-user/src/test/htmlunit/org/wyona/yanel/impl/resources/YanelUserResourceWebTest.java#testAuthenticationInPasswordUpdate() > > > whereas otherwise I have resolved all issues. I have commented this > method for the moment such that the build should work again, but I am > currently trying to fix this method as well. I have noticed that also some webtests needed to be enhanced, because I have slight changed the wording. This should work now again. Thanks Michi > > Cheers > > Michi From michael.wechner at wyona.com Wed Jun 16 22:16:07 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 16 22:31:34 2010 Subject: [Yanel-dev] Response status issue within GWT Message-ID: <4C193107.4090204@wyona.com> Hi I have noticed an issue re HTTP response status within GWT, whereas it seems that others are also experiencing this http://code.google.com/p/google-web-toolkit/issues/detail?id=2858 It seems like the method response.getStatusCode() returns "0" sometimes instead "200" although the server returned "200" (use ngrep to prove this). I have done a workaround by also checking on "0" instead "200" which is not that nice, but at least it is working. Thanks Michi From Wayne.Bunting at gurit.com Wed Jun 16 23:26:30 2010 From: Wayne.Bunting at gurit.com (Wayne.Bunting@gurit.com) Date: Wed Jun 16 23:41:54 2010 Subject: [Yanel-dev] AUTO: Wayne Bunting is out of the office. (returning 22/06/2010) Message-ID: I am out of the office until 22/06/2010. I will respond to your message when I return. Note: This is an automated response to your message "[Yanel-dev] Response status issue within GWT" sent on 16/06/2010 21:16:07. This is the only notification you will receive while this person is away. ********************************************************************* All sales of goods are subject to the terms and conditions of sale (the Conditions) of Gurit (UK) Limited (the Company) which are available on request from the Company or may be viewed on the Gurit Website http://www.gurit.com Any advice given by the Company in connection with the sale of goods or the provision of technical, engineering or other services is given in good faith but the company only warrants that advice in writing and in relation to specific services or a specific project is given with reasonable skill and care. All advice is otherwise given subject to the Conditions. The contents of this message and any attachments are confidential and are intended solely for the attention and use of the addressee only. Information contained in this message may be subject to legal, professional or other privilege or may otherwise be protected by other legal rules. This message should not be copied or forwarded to any other person without the express permission of the sender. If you are not the intended recipient you are not authorised to disclose, copy, distribute or retain this message or any part of it. Gurit (UK) Limited registered offices are: St. Cross Business Park, Newport, Isle of Wight, PO30 5WU, UK The Company is registered in England and Wales. Reg No. 1368806 ********************************************************************* From michael.wechner at wyona.com Wed Jun 16 23:26:56 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 16 23:43:57 2010 Subject: [Yanel-dev] Managing policies Message-ID: <4C1941A0.7040708@wyona.com> Hi It would be nice to be able to delete policies recursively, e.g. PolicyManager.removePolicy(PATH, true) whereas this would be mean to break/enhance the API of the policy manager. Now instead doing this one could browser through the repository somehow, but it would mean to introduce new methods such as Policy.getChildren() and PolicyManager.existsPolicy(PATH). (btw, the exists seems to be done with PolicyManager.getPolicy(path, false) != null) I am not sure either what steps should be done, hence consider the above as food for thought ;-) Thanks Michi From michael.wechner at wyona.com Wed Jun 16 23:49:33 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Jun 17 00:05:13 2010 Subject: [Yanel-dev] Managing policies In-Reply-To: <4C1941A0.7040708@wyona.com> References: <4C1941A0.7040708@wyona.com> Message-ID: <4C1946ED.5070400@wyona.com> Michael Wechner wrote: > Hi > > It would be nice to be able to delete policies recursively, e.g. > > PolicyManager.removePolicy(PATH, true) > > whereas this would be mean to break/enhance the API of the policy > manager. > > Now instead doing this one could browser through the repository > somehow, but it would mean to > introduce new methods such as > > Policy.getChildren() > > and > > PolicyManager.existsPolicy(PATH). As a workaround I have used the Policies Repository within src/contributions/resources/security-api/src/java/org/wyona/yanel/impl/resources/securityapi/UserManagerResource.java (} else if (path.endsWith(".policy")) { // WARNING/TODO: This check violates the API!) but this is really not nice and should be changed as soon as possible. Cheers Michi > > (btw, the exists seems to be done with PolicyManager.getPolicy(path, > false) != null) > > I am not sure either what steps should be done, hence consider the > above as food for thought ;-) > > Thanks > > Michi From bruno.vonrotz at wyona.com Thu Jun 17 08:39:41 2010 From: bruno.vonrotz at wyona.com (Bruno von Rotz) Date: Thu Jun 17 08:55:04 2010 Subject: [Yanel-dev] User login - prevent the same user from logging on twice Message-ID: <4C19C32D.20104@wyona.com> For some implementations it's important that the same user can't log on to the system twice. For example if there's a subscription based revenue model you don't want to have the same user create two sessions using different computers (cookies). I see different ways to prevent this or to monitor this: a) through the login we can detect whether the same credentials have been used by different computers (cookies) at the same time. Then we can manually or automatically decide to lock the user or to not allow him to log on again b) we can detect at log on time whether the same user is already logged on. I am not sure whether we actually know whether a specific user is already logged on. But we could store additional information to make sure we CAN know c) we could also have a "flag" per user to say whether multi-login is allowed, as for some purposes, i.e. testing, it's practical to be able to use the same user many times There may be more possibilities. What is the best way to go depends on what and how it is already implemented in Yanel. Bruno - From mehmet.birgi at wyona.com Thu Jun 17 08:41:32 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Thu Jun 17 08:57:17 2010 Subject: [Yanel-dev] Use of ImageMagick with Yanel/Yarep Message-ID: Hi all We recently had to implement some image scaling for a client project where image quality is very important. After first trying the standard tools that come with java.awt, since the results were not satisfactory, we switched to the ImageMagick tool. We implemented IM through the java interface im4java, and in the end, it worked just fine. The main difficulty was that the straightforward use of im4java needs absolute file paths as input and output, as im4java is basically a wrapper for the IM command line tool. Of course, this is not possible to do through Yarep, as it breaks the decoupling of the repository implementation. Luckily, we found out that im4java has an interface that allows piping of input and output streams, that can be used as follows: // create the operation, add images and operators/options IMOperation op = new IMOperation(); op.addImage("-"); op.resize(newWidth,newHeight); op.addImage("-"); // create the pipes InputStream is = getRepoNodeInputStream(sourceImageRepoPath); Pipe pipeIn = new Pipe(is, null); OutputStream os = getRepoNodeOutputStream(targetImageRepoPath); Pipe pipeOut = new Pipe(null, os); // execute the operation ConvertCmd cmd = new ConvertCmd(); cmd.setInputProvider(pipeIn); cmd.setOutputConsumer(pipeOut); cmd.run(op); is.close(); os.close(); I hope that this might be helpful if anybody else has the same problem. Cheers, Memo -- Mehmet Birgi www.wyona.com From michael.wechner at wyona.com Thu Jun 17 10:23:26 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Jun 17 10:38:55 2010 Subject: [Yanel-dev] User login - prevent the same user from logging on twice In-Reply-To: <4C19C32D.20104@wyona.com> References: <4C19C32D.20104@wyona.com> Message-ID: <4C19DB7E.3050406@wyona.com> Bruno von Rotz wrote: > For some implementations it's important that the same user can't log > on to the system twice. ok > For example if there's a subscription based revenue model you don't > want to have the same user create two sessions using different > computers (cookies). you mean because of possible fraud? I don't think you can really prevent this kind of fraud, because people will use the same login at different times, but yes, it will be less convenient for them > I see different ways to prevent this or to monitor this: > a) through the login we can detect whether the same credentials have > been used by different computers (cookies) at the same time. Then we > can manually or automatically decide to lock the user or to not allow > him to log on again I think this could be through the session, because Yanel knows that such a user (per realm) is already signed in (via the session) and hence could block another session for the same credentials > b) we can detect at log on time whether the same user is already > logged on. I am not sure whether we actually know whether a specific > user is already logged on. But we could store additional information > to make sure we CAN know How is (b) different from (a)? > c) we could also have a "flag" per user to say whether multi-login is > allowed, as for some purposes, i.e. testing, it's practical to be able > to use the same user many times generally speaking it would be - per user - per realm - per Yanel instance > There may be more possibilities. > What is the best way to go depends on what and how it is already > implemented in Yanel. to start with I would suggest to implement this per Yanel instance, which means within yanel.xml it has a flag to enable this functionality, but to be sure I need to analyze it and size the effort. Cheers Michi > Bruno > > - > From bugzilla at wyona.com Sat Jun 19 16:11:39 2010 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Sat Jun 19 16:14:40 2010 Subject: [Yanel-dev] [Bug 7665] New: it should be possible to control the continue-path within tinyMCE resource Message-ID: <20100619141139.6C53410CADB@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7665 Summary: it should be possible to control the continue-path within tinyMCE resource Product: Yanel Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: General AssignedTo: michael.wechner@wyona.org ReportedBy: simon@333.ch QAContact: yanel-development@wyona.com at the moment the path where the uscase should go after finish is callculated from the referer or edit path. but maybe someone likes it different. in this cas it should be possible to override the continue-path vi request parameter. -- 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 Sat Jun 19 16:12:34 2010 From: bugzilla at wyona.com (bugzilla@wyona.com) Date: Sat Jun 19 16:14:41 2010 Subject: [Yanel-dev] [Bug 7665] it should be possible to control the continue-path within tinyMCE resource Message-ID: <20100619141234.9C8F410CAFF@server1.example.com> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7665 ------- Comment #1 from simon@333.ch 2010-06-19 15:03 ------- Created an attachment (id=1310) --> (http://bugzilla.wyona.com/cgi-bin/bugzilla/attachment.cgi?id=1310&action=view) allows seting of the continue-path paramter -- 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 mehmet.birgi at wyona.com Mon Jun 21 13:28:22 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Mon Jun 21 13:46:08 2010 Subject: [Yanel-dev] Creating new resource Message-ID: Hi When a new resource is created via the Yanel build system as described on the page http://yanel.wyona.org/en/documentation/create-new-resource.html, compiling only the resource (again, as described on that page) does not seem to be enough to register the resource. Only after a complete build of Yanel is the new resource visible in the list of registered resources. Is this correct? If someone can confirm this, I will update the docs to make it clear that the first time a complete build is needed. Thanks, Memo -- Mehmet Birgi www.wyona.com From mehmet.birgi at wyona.com Tue Jun 22 19:20:29 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Tue Jun 22 19:36:31 2010 Subject: [Yanel-dev] Potential pitfall on Mac OS X with case sensitivity Message-ID: Hi all Mac users I have just learned (the hard way) that the HFS+ (aka Mac OS Extended) filesystem used by most Mac OS X installations might or might not be case sensitive (though it is always case preserving). This depends on the option chosen when creating the partition. Apparently this is for backwards compatibility reasons, but it might cause unexpected problems when deploying to case sensitive systems. I also haven't found a proper way to check this property, except by trial. So check yours and be aware! Cheers Memo -- Mehmet Birgi www.wyona.com From michael.wechner at wyona.com Tue Jun 22 22:01:12 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 22 22:22:23 2010 Subject: [Yanel-dev] Potential pitfall on Mac OS X with case sensitivity In-Reply-To: References: Message-ID: <4C211688.7090200@wyona.com> Please be aware that Yanel is supposed to be case-sensitive, whereas nevertheless never use the "same" name twice, e.g. yanel.xml and Yanel.xml because AFAIK Windows will have problems with this, because AFAIK Windows is not case-sensitive. Thanks Michi Mehmet Birgi wrote: > Hi all Mac users > > I have just learned (the hard way) that the HFS+ (aka Mac OS Extended) > filesystem used by most Mac OS X installations might or might not be > case sensitive (though it is always case preserving). This depends on > the option chosen when creating the partition. Apparently this is for > backwards compatibility reasons, but it might cause unexpected > problems when deploying to case sensitive systems. I also haven't > found a proper way to check this property, except by trial. So check > yours and be aware! > > Cheers > > Memo > > > > From michael.wechner at wyona.com Tue Jun 22 22:14:10 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 22 22:29:48 2010 Subject: [Yanel-dev] Creating new resource In-Reply-To: References: Message-ID: <4C211992.3070505@wyona.com> Mehmet Birgi wrote: > Hi > > When a new resource is created via the Yanel build system as described > on the page http://yanel.wyona.org/en/documentation/create-new-resource.html, > compiling only the resource (again, as described on that page) does > not seem to be enough to register the resource. you need to register it first (see "Register New Resource" of http://yanel.wyona.org/en/documentation/create-new-resource.html) > Only after a complete > build of Yanel is the new resource visible in the list of registered > resources. Is this correct? this is only correct if you register it first within $YANELHOME/conf/local/local.resource-type.xml (as described within the documentation) If you register it directly within the deployed version, e.g. local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/resource-types.xml then you only need to build the new resource and restart Yanel. Is it clearer now? Thanks Michi > If someone can confirm this, I will update > the docs to make it clear that the first time a complete build is > needed. > > Thanks, > > Memo > > > From mehmet.birgi at wyona.com Wed Jun 23 08:36:06 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Wed Jun 23 08:53:35 2010 Subject: [Yanel-dev] Creating new resource In-Reply-To: <4C211992.3070505@wyona.com> References: <4C211992.3070505@wyona.com> Message-ID: On Tue, Jun 22, 2010 at 10:14 PM, Michael Wechner wrote: > Mehmet Birgi wrote: >> >> Hi >> >> When a new resource is created via the Yanel build system as described >> on the page >> http://yanel.wyona.org/en/documentation/create-new-resource.html, >> compiling only the resource (again, as described on that page) does >> not seem to be enough to register the resource. > > you need to register it first (see "Register New Resource" of > http://yanel.wyona.org/en/documentation/create-new-resource.html) >> >> ?Only after a complete >> build of Yanel is the new resource visible in the list of registered >> resources. Is this correct? > > this is only correct if you register it first within > > $YANELHOME/conf/local/local.resource-type.xml > > (as described within the documentation) > > If you register it directly within the deployed version, e.g. > > local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/resource-types.xml > > then you only need to build the new resource and restart Yanel. > > Is it clearer now? yes, thank you. cheers, memo -- Mehmet Birgi www.wyona.com From mehmet.birgi at wyona.com Thu Jun 24 13:47:02 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Thu Jun 24 14:02:58 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: References: Message-ID: Hi Here is some more important information about the use of im4java: additionally to im4java.jar, also a conventional installation of ImageMagick is needed on every computer where the application will be used, especially on the server machine. On Unix/Linux systems, ImageMagick can be installed with "sudo aptitude install imagemagick" (on Macs try MacPorts, i.e. "sudo port install imagemagick). Question: is there a platform independent way to integrate this into the Yanel build system? Cheers, Memo On Thu, Jun 17, 2010 at 8:41 AM, Mehmet Birgi wrote: > Hi all > > We recently had to implement some image scaling for a client project > where image quality is very important. After first trying the standard > tools that come with java.awt, since the results were not > satisfactory, we switched to the ImageMagick tool. We implemented IM > through the java interface im4java, and in the end, it worked just > fine. > > The main difficulty was that the straightforward use of im4java needs > absolute file paths as input and output, as im4java is basically a > wrapper for the IM command line tool. Of course, this is not possible > to do through Yarep, as it breaks the decoupling of the repository > implementation. Luckily, we found out that im4java has an interface > that allows piping of input and output streams, that can be used as > follows: > > ? ? ? ?// create the operation, add images and operators/options > ? ? ? ?IMOperation op = new IMOperation(); > ? ? ? ?op.addImage("-"); > ? ? ? ?op.resize(newWidth,newHeight); > ? ? ? ?op.addImage("-"); > > ? ? ? ?// create the pipes > ? ? ? ?InputStream is = getRepoNodeInputStream(sourceImageRepoPath); > ? ? ? ?Pipe pipeIn ?= new Pipe(is, null); > ? ? ? ?OutputStream os = getRepoNodeOutputStream(targetImageRepoPath); > ? ? ? ?Pipe pipeOut = new Pipe(null, os); > > ? ? ? ?// execute the operation > ? ? ? ?ConvertCmd cmd = new ConvertCmd(); > ? ? ? ?cmd.setInputProvider(pipeIn); > ? ? ? ?cmd.setOutputConsumer(pipeOut); > ? ? ? ?cmd.run(op); > ? ? ? ?is.close(); > ? ? ? ?os.close(); > > I hope that this might be helpful if anybody else has the same problem. > > Cheers, > > Memo > > > > -- > Mehmet Birgi > www.wyona.com > -- Mehmet Birgi www.wyona.com From cedric.staub at wyona.com Thu Jun 24 13:59:50 2010 From: cedric.staub at wyona.com (Cedric Staub) Date: Thu Jun 24 14:15:32 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: References:

Message-ID: <20100624135950.0a61f385.cedric.staub@wyona.com> On Thu, 24 Jun 2010 13:47:02 +0200 Mehmet Birgi wrote: > Question: is there a platform independent way to integrate this into > the Yanel build system? I don't think there would be an easy way to do so, considering all the diffrent flavors of Linux/Unix that are out there and the various package managers that they use (for example, aptitude only works on Debian/Ubuntu systems). What you could probably do is check if ImageMagick is installed and if not print a warning message; that way the system administrator knows what he needs to do in order to fix it (figuring out how to install it should be the lesser problem). Of course, I'm no expert on the Yanel build system, so please correct me if I'm wrong ;-). Cheers, Cedric From mehmet.birgi at wyona.com Thu Jun 24 17:13:28 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Thu Jun 24 17:29:30 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: <20100624135950.0a61f385.cedric.staub@wyona.com> References:

<20100624135950.0a61f385.cedric.staub@wyona.com> Message-ID: On Thu, Jun 24, 2010 at 1:59 PM, Cedric Staub wrote: > On Thu, 24 Jun 2010 13:47:02 +0200 > Mehmet Birgi wrote: > >> Question: is there a platform independent way to integrate this into >> the Yanel build system? > > I don't think there would be an easy way to do so, considering all the diffrent flavors of Linux/Unix that are out there and the various package managers that they use (for example, aptitude only works on Debian/Ubuntu systems). What you could probably do is check if ImageMagick is installed and if not print a warning message; that way the system administrator knows what he needs to do in order to fix it (figuring out how to install it should be the lesser problem). Yes, that's what I thought, too :-) > > Of course, I'm no expert on the Yanel build system, so please correct me if I'm wrong ;-). > > Cheers, > Cedric > -- > Yanel-development mailing list Yanel-development@wyona.com > http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development > -- Mehmet Birgi www.wyona.com From michael.wechner at wyona.com Thu Jun 24 23:10:18 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Thu Jun 24 23:29:29 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: <20100624135950.0a61f385.cedric.staub@wyona.com> References:

<20100624135950.0a61f385.cedric.staub@wyona.com> Message-ID: <4C23C9BA.60006@wyona.com> Cedric Staub wrote: > On Thu, 24 Jun 2010 13:47:02 +0200 > Mehmet Birgi wrote: > > >> Question: is there a platform independent way to integrate this into >> the Yanel build system? >> > > I don't think there would be an easy way to do so, considering all the diffrent flavors of Linux/Unix that are out there and the various package managers that they use (for example, aptitude only works on Debian/Ubuntu systems). What you could probably do is check if ImageMagick is installed and if not print a warning message; well, I would assume that im4java throws an exception @Memo: What does the log-file say if ImageMagick is not installed? > that way the system administrator knows what he needs to do in order to fix it (figuring out how to install it should be the lesser problem). > > Of course, I'm no expert on the Yanel build system, so please correct me if I'm wrong ;-). > I don't think this has much to do with the Yanel build process generally speaking. Especially if you are going to deploy binaries, which you should on a productive system! I think to improve the situation you have two options: 1) Improve the "exception handling" of your resource type if ImageMagik is not installed 2) Customize/enhance the build.xml of your resource type using im4java/ImageMagik to output a warning that ImageMagik could not be found, whereas this warning should be ignorable, because the environment on which you build your binaries might not have ImageMagik installed. and of course documentation, documentation, documentation ;-) Cheers Michi > Cheers, > Cedric > From mehmet.birgi at wyona.com Fri Jun 25 14:59:19 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Fri Jun 25 15:16:04 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: <4C23C9BA.60006@wyona.com> References:

<20100624135950.0a61f385.cedric.staub@wyona.com> <4C23C9BA.60006@wyona.com> Message-ID: On Thu, Jun 24, 2010 at 11:10 PM, Michael Wechner wrote: > Cedric Staub wrote: >> >> On Thu, 24 Jun 2010 13:47:02 +0200 >> Mehmet Birgi wrote: >> >> >>> >>> Question: is there a platform independent way to integrate this into >>> the Yanel build system? >>> >> >> I don't think there would be an easy way to do so, considering all the >> diffrent flavors of Linux/Unix that are out there and the various package >> managers that they use (for example, aptitude only works on Debian/Ubuntu >> systems). What you could probably do is check if ImageMagick is installed >> and if not print a warning message; > > well, I would assume that im4java throws an exception > > @Memo: What does the log-file say if ImageMagick is not installed? This is the error message Bruno had forwarded. In the log, there was nothing special/different, as far as I can remember, only longer,, and it was possible to see that the error originated in the method resize() of ImageScaler, but I would have to reproduce the error to get the whole thing, if you think it would help. The first line here is all there was really: java.lang.Exception: Due to an exception the request has been canceled. Exception message: Cannot run program "convert": java.io.IOException: error=2, No such file or directory java.lang.Exception: Due to an exception the request has been canceled. Exception message: Cannot run program "convert": java.io.IOException: error=2, No such file or directory at org.wyona.yanel.impl.resources.jellyadapterofcmdv3.JellyAdapterForCUDResource.getView(JellyAdapterForCUDResource.java:148) at org.wyona.yanel.servlet.YanelServlet.getContent(YanelServlet.java:536) at org.wyona.yanel.servlet.YanelServlet.doPost(YanelServlet.java:740) at org.wyona.yanel.servlet.YanelServlet.service(YanelServlet.java:280) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.wyona.yanel.servlet.communication.YanelFilter.doFilter(YanelFilter.java:37) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardC > > >> ?that way the system administrator knows what he needs to do in order to >> fix it (figuring out how to install it should be the lesser problem). >> >> Of course, I'm no expert on the Yanel build system, so please correct me >> if I'm wrong ;-). >> > > I don't think this has much to do with the Yanel build process generally > speaking. Especially if you are going > to deploy binaries, which you should on a productive system! > > I think to improve the situation you have two options: > > 1) ?Improve the "exception handling" of your resource type if ImageMagik is > not installed > > 2) Customize/enhance the build.xml of your resource type using > im4java/ImageMagik to output a warning > that ImageMagik could not be found, whereas this warning should be > ignorable, because the environment > on which you build your binaries might not have ImageMagik installed. > > and of course documentation, documentation, documentation ;-) > > Cheers > > Michi >> >> Cheers, >> Cedric >> > > -- > Yanel-development mailing list Yanel-development@wyona.com > http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development > -- Mehmet Birgi www.wyona.com From michael.wechner at wyona.com Fri Jun 25 23:20:26 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Fri Jun 25 23:42:08 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: References:

<20100624135950.0a61f385.cedric.staub@wyona.com> <4C23C9BA.60006@wyona.com> Message-ID: <4C251D9A.2050601@wyona.com> Mehmet Birgi wrote: > On Thu, Jun 24, 2010 at 11:10 PM, Michael Wechner > wrote: > >> Cedric Staub wrote: >> >>> On Thu, 24 Jun 2010 13:47:02 +0200 >>> Mehmet Birgi wrote: >>> >>> >>> >>>> Question: is there a platform independent way to integrate this into >>>> the Yanel build system? >>>> >>>> >>> I don't think there would be an easy way to do so, considering all the >>> diffrent flavors of Linux/Unix that are out there and the various package >>> managers that they use (for example, aptitude only works on Debian/Ubuntu >>> systems). What you could probably do is check if ImageMagick is installed >>> and if not print a warning message; >>> >> well, I would assume that im4java throws an exception >> >> @Memo: What does the log-file say if ImageMagick is not installed? >> > > This is the error message Bruno had forwarded. In the log, there was > nothing special/different, as far as I can remember, only longer,, and > it was possible to see that the error originated in the method > resize() of ImageScaler, but I would have to reproduce the error to > get the whole thing, if you think it would help. yes, I think it would help to reproduce this exception and check whether there is a possibility to catch this somehow nicely. Also you might want to consider sending an email to the im4java community and ask there how to deal with such a situation. And last but not least I assume you are aware of src/contributions/resources/image/resource.xml right? This resource type allows scaling of jpg images and AFAIK it works quite well. Cheers Michi > The first line here > is all there was really: > > > java.lang.Exception: Due to an exception the request has been > canceled. Exception message: Cannot run program "convert": java.io.IOException: > error=2, No such file or directory > > java.lang.Exception: Due to an exception the request has been > canceled. Exception message: Cannot run program "convert": java.io.IOException: > error=2, No such file or directory > at > org.wyona.yanel.impl.resources.jellyadapterofcmdv3.JellyAdapterForCUDResource.getView(JellyAdapterForCUDResource.java:148) > at > org.wyona.yanel.servlet.YanelServlet.getContent(YanelServlet.java:536) > at > org.wyona.yanel.servlet.YanelServlet.doPost(YanelServlet.java:740) > at > org.wyona.yanel.servlet.YanelServlet.service(YanelServlet.java:280) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.wyona.yanel.servlet.communication.YanelFilter.doFilter(YanelFilter.java:37) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardC > > > >> >>> that way the system administrator knows what he needs to do in order to >>> fix it (figuring out how to install it should be the lesser problem). >>> >>> Of course, I'm no expert on the Yanel build system, so please correct me >>> if I'm wrong ;-). >>> >>> >> I don't think this has much to do with the Yanel build process generally >> speaking. Especially if you are going >> to deploy binaries, which you should on a productive system! >> >> I think to improve the situation you have two options: >> >> 1) Improve the "exception handling" of your resource type if ImageMagik is >> not installed >> >> 2) Customize/enhance the build.xml of your resource type using >> im4java/ImageMagik to output a warning >> that ImageMagik could not be found, whereas this warning should be >> ignorable, because the environment >> on which you build your binaries might not have ImageMagik installed. >> >> and of course documentation, documentation, documentation ;-) >> >> Cheers >> >> Michi >> >>> Cheers, >>> Cedric >>> >>> >> -- >> Yanel-development mailing list Yanel-development@wyona.com >> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development >> >> > > > > From michael.wechner at wyona.com Mon Jun 28 17:11:26 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Mon Jun 28 17:29:54 2010 Subject: [Yanel-dev] Boost access log file format Message-ID: <4C28BB9E.1000105@wyona.com> Hi Cedric pointed out to me that it might make sense to have a different format for the boost access log. It currently reads Date, log-level, URL, realm-id, boost-cookie, user (if available), Referer, User-Agent, E-Mail (if available) whereas the relevant code re email is at src/contributions/resources/contact-form/src/java/org/wyona/yanel/impl/resources/contactform/ContactResource.java logAccess.info(org.wyona.yanel.servlet.AccessLog.getLogMessage(request, getRealm().getID()) + " e-mail:" + request.getParameter("email")); or rather src/webapp/src/java/org/wyona/yanel/servlet/AccessLog.java Any suggestions how to improve this format are very welcome ;-) Thanks Michi From michael.wechner at wyona.com Mon Jun 28 17:42:18 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Mon Jun 28 17:58:01 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <4C28BB9E.1000105@wyona.com> References: <4C28BB9E.1000105@wyona.com> Message-ID: <4C28C2DA.5080901@wyona.com> Michael Wechner wrote: > Hi > > Cedric pointed out to me that it might make sense to have a different > format for the boost access log. It currently reads > > Date, log-level, URL, realm-id, boost-cookie, user (if available), > Referer, User-Agent, E-Mail (if available) > > whereas the relevant code re email is at > > src/contributions/resources/contact-form/src/java/org/wyona/yanel/impl/resources/contactform/ContactResource.java > > logAccess.info(org.wyona.yanel.servlet.AccessLog.getLogMessage(request, > getRealm().getID()) + " e-mail:" + request.getParameter("email")); btw, you can configure the email within src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc conf/local/local.yanel.xml and test it with http://127.0.0.1:8080/yanel/yanel-website/en/contact.html Cheers Michi > > or rather > > src/webapp/src/java/org/wyona/yanel/servlet/AccessLog.java > > Any suggestions how to improve this format are very welcome ;-) > > Thanks > > Michi > > From cedric.staub at wyona.com Tue Jun 29 09:28:13 2010 From: cedric.staub at wyona.com (Cedric Staub) Date: Tue Jun 29 09:49:05 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <4C28BB9E.1000105@wyona.com> References: <4C28BB9E.1000105@wyona.com> Message-ID: <20100629092813.9a6cd0ef.cedric.staub@wyona.com> Hello there > Cedric pointed out to me that it might make sense to have a different > format for the boost access log. It currently reads > > Date, log-level, URL, realm-id, boost-cookie, user (if available), > Referer, User-Agent, E-Mail (if available) A single log entry currently looks like this: --- http://www.example.org/index.html r:example c:YA-1 ref:null ua:Mozilla/4.0 (example) --- While the field:value pairs are actually quite useful and make parsing a log entry easier, the problem is that the values in the fields (e.g. the user agent) can also contain colons/spaces, making it in certain cases impossible to tell where a field starts or ends. I suggest we escape the colons and spaces, e.g. by using url encoding. This can easily be done using java.net.URLEncoder on the logging side and java.net.URLDecoder and the parsing side. I would also suggest that we add "url:" to the front of the url in order to make parsing more robust, right now the parser just assumes that the url is the first field. Then we could change the format later (e.g. moving the url to another position) without breaking the parser. Then we'd just have to make sure any module that appends data actually uses url encoding and doesn't just print it verbatim. Maybe we can add a convenciance function somewhere to make this easier? Anyway, I will try to reply with a patch implementing this shortly. Greetings Cedric From michael.wechner at wyona.com Tue Jun 29 10:09:36 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 29 10:25:19 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <20100629092813.9a6cd0ef.cedric.staub@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> Message-ID: <4C29AA40.7050003@wyona.com> Cedric Staub wrote: > Hello there > > >> Cedric pointed out to me that it might make sense to have a different >> format for the boost access log. It currently reads >> >> Date, log-level, URL, realm-id, boost-cookie, user (if available), >> Referer, User-Agent, E-Mail (if available) >> > > A single log entry currently looks like this: > --- > http://www.example.org/index.html r:example c:YA-1 ref:null > ua:Mozilla/4.0 (example) > --- > > While the field:value pairs are actually quite useful and make parsing > a log entry easier, the problem is that the values in the fields (e.g. > the user agent) can also contain colons/spaces, making it in certain > cases impossible to tell where a field starts or ends. > > I suggest we escape the colons and spaces, e.g. by using url encoding. > This can easily be done using java.net.URLEncoder on the logging side > and java.net.URLDecoder and the parsing side. > > I would also suggest that we add "url:" to the front of the url in > order to make parsing more robust, right now the parser just assumes > that the url is the first field. Then we could change the format later > (e.g. moving the url to another position) without breaking the parser. > sounds good > Then we'd just have to make sure any module that appends data actually > uses url encoding and doesn't just print it verbatim. Maybe we can add > a convenciance function somewhere to make this easier? > you mean for something like email:michi@wyona.org added by the contact form resource? > Anyway, I will try to reply with a patch implementing this shortly. > Looking forward to your patch :-) Btw, you might want to consider encryption and decryption of the log file. The reason I am saying this is because of privacy, etc. Thanks MIchi > Greetings > Cedric > From cedric.staub at wyona.com Tue Jun 29 10:10:16 2010 From: cedric.staub at wyona.com (Cedric Staub) Date: Tue Jun 29 10:26:11 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <20100629092813.9a6cd0ef.cedric.staub@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> Message-ID: <20100629101016.ee7c0372.cedric.staub@wyona.com> On Tue, 29 Jun 2010 09:28:13 +0200 Cedric Staub wrote: > Anyway, I will try to reply with a patch implementing this shortly. Here's the patch, I verified that it compiles and works as expected on my machine (latest revision). Greetings Cedric -------------- next part -------------- A non-text attachment was scrubbed... Name: BoostLogging.patch Type: text/x-patch Size: 3485 bytes Desc: not available Url : http://lists.wyona.org/pipermail/yanel-development/attachments/20100629/077a2c15/BoostLogging.bin From cedric.staub at wyona.com Tue Jun 29 10:20:13 2010 From: cedric.staub at wyona.com (Cedric Staub) Date: Tue Jun 29 10:38:03 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <4C29AA40.7050003@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> <4C29AA40.7050003@wyona.com> Message-ID: <20100629102013.c9360071.cedric.staub@wyona.com> > Btw, you might want to consider encryption and decryption of the log > file. The reason I am saying this > is because of privacy, etc. Do you mean encryption of the access log as we write it (e.g. Yanel encrypts the output)? I wouldn't know where to store the encryption keys, but anyone who would have access to the (physical) machine with the access logs on them would have access to the encryption keys as well unless the log is on a diffrent machine than Yanel (because we need to be able to decrypt the access logs when we need them). Greetings Cedric From michael.wechner at wyona.com Tue Jun 29 10:48:41 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 29 11:04:24 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <20100629102013.c9360071.cedric.staub@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> <4C29AA40.7050003@wyona.com> <20100629102013.c9360071.cedric.staub@wyona.com> Message-ID: <4C29B369.9040002@wyona.com> Cedric Staub wrote: >> Btw, you might want to consider encryption and decryption of the log >> file. The reason I am saying this >> is because of privacy, etc. >> > > Do you mean encryption of the access log as we write it (e.g. Yanel > encrypts the output)? yes > I wouldn't know where to store the encryption > keys, but anyone who would have access to the (physical) machine with > the access logs on them would have access to the encryption keys as > well unless the log is on a diffrent machine than Yanel (because we > need to be able to decrypt the access logs when we need them). > I guess we could do it like with the public key method, which means we encrypt it on one machine and decrypt it on another (with different keys of course ;-) I am not saying we have to do this right now, we need to keep it in the back of our minds, because it is important to consider privacy. Cheers Michi > Greetings > Cedric > > From michael.wechner at wyona.com Tue Jun 29 10:50:57 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 29 11:06:39 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <20100629101016.ee7c0372.cedric.staub@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> <20100629101016.ee7c0372.cedric.staub@wyona.com> Message-ID: <4C29B3F1.2060202@wyona.com> Cedric Staub wrote: > On Tue, 29 Jun 2010 09:28:13 +0200 > Cedric Staub wrote: > > >> Anyway, I will try to reply with a patch implementing this shortly. >> > > Here's the patch, I verified that it compiles and works as expected on > my machine (latest revision). > thanks very much. I will try to eview it later today otherwise please feel free to remind me or even create a bug entry http://www.yanel.org/en/task-bug-tracker.html Cheers Michi > Greetings > Cedric > From cedric.staub at wyona.com Tue Jun 29 11:14:32 2010 From: cedric.staub at wyona.com (Cedric Staub) Date: Tue Jun 29 11:30:45 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <4C29B369.9040002@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> <4C29AA40.7050003@wyona.com> <20100629102013.c9360071.cedric.staub@wyona.com> <4C29B369.9040002@wyona.com> Message-ID: <20100629111432.6aa36385.cedric.staub@wyona.com> On Tue, 29 Jun 2010 10:48:41 +0200 Michael Wechner wrote: > I am not saying we have to do this right now, we need to keep it in the > back of our minds, because > it is important to consider privacy. You're right, I agree. The log parser implementation I wrote could already be easily replaced by another one, so I think it should fairly simple to implement this when the time comes. Greetings Cedric From michael.wechner at wyona.com Tue Jun 29 11:23:49 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Tue Jun 29 11:39:32 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <20100629111432.6aa36385.cedric.staub@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> <4C29AA40.7050003@wyona.com> <20100629102013.c9360071.cedric.staub@wyona.com> <4C29B369.9040002@wyona.com> <20100629111432.6aa36385.cedric.staub@wyona.com> Message-ID: <4C29BBA5.8060606@wyona.com> Cedric Staub wrote: > On Tue, 29 Jun 2010 10:48:41 +0200 > Michael Wechner wrote: > > >> I am not saying we have to do this right now, we need to keep it in the >> back of our minds, because >> it is important to consider privacy. >> > > You're right, I agree. The log parser implementation I wrote could > already be easily replaced by another one, so I think it should fairly > simple to implement this when the time comes. > Maybe you can add some TODO/NOTE within the parser implementation. Thanks Michi > Greetings > Cedric > From mehmet.birgi at wyona.com Wed Jun 30 14:01:29 2010 From: mehmet.birgi at wyona.com (Mehmet Birgi) Date: Wed Jun 30 14:17:33 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: <4C251D9A.2050601@wyona.com> References:

<20100624135950.0a61f385.cedric.staub@wyona.com> <4C23C9BA.60006@wyona.com> <4C251D9A.2050601@wyona.com> Message-ID: On Fri, Jun 25, 2010 at 11:20 PM, Michael Wechner wrote: > Mehmet Birgi wrote: >> >> On Thu, Jun 24, 2010 at 11:10 PM, Michael Wechner >> wrote: >> >>> >>> Cedric Staub wrote: >>> >>>> >>>> On Thu, 24 Jun 2010 13:47:02 +0200 >>>> Mehmet Birgi wrote: >>>> >>>> >>>> >>>>> >>>>> Question: is there a platform independent way to integrate this into >>>>> the Yanel build system? >>>>> >>>>> >>>> >>>> I don't think there would be an easy way to do so, considering all the >>>> diffrent flavors of Linux/Unix that are out there and the various >>>> package >>>> managers that they use (for example, aptitude only works on >>>> Debian/Ubuntu >>>> systems). What you could probably do is check if ImageMagick is >>>> installed >>>> and if not print a warning message; >>>> >>> >>> well, I would assume that im4java throws an exception >>> >>> @Memo: What does the log-file say if ImageMagick is not installed? >>> >> >> This is the error message Bruno had forwarded. In the log, there was >> nothing special/different, as far as I can remember, only longer,, and >> it was possible to see that the error originated in the method >> resize() of ImageScaler, but I would have to reproduce the error to >> get the whole thing, if you think it would help. > > yes, I think it would help to reproduce this exception and check whether > there is a possibility > to catch this somehow nicely. OK, I will look into this. > > Also you might want to consider sending an email to the im4java community > and ask there > how to deal with such a situation. > > And last but not least I assume you are aware of > > src/contributions/resources/image/resource.xml > > right? This resource type allows scaling of jpg images and AFAIK it works > quite well. No. I wasn't aware. Frankly. I didn't check, as the custom implementation was already done, and I just replaced the actual resizing part. I will make a bugzilla entry in the customer project to come back and check what there is, and maybe replace/use the existing one. But only when we have a little more time, as for now the code is working, and I would like to continue with other priorities ;-) But many thanks for pointing this out. Cheers, Memo From bruno.vonrotz at wyona.com Wed Jun 30 14:16:49 2010 From: bruno.vonrotz at wyona.com (Bruno von Rotz) Date: Wed Jun 30 14:37:58 2010 Subject: [Yanel-dev] Re: Use of ImageMagick with Yanel/Yarep In-Reply-To: References:

<20100624135950.0a61f385.cedric.staub@wyona.com> <4C23C9BA.60006@wyona.com> <4C251D9A.2050601@wyona.com> Message-ID: <4C2B35B1.7060209@wyona.com> An HTML attachment was scrubbed... URL: http://lists.wyona.org/pipermail/yanel-development/attachments/20100630/5d83d570/attachment.htm From michael.wechner at wyona.com Wed Jun 30 16:14:22 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 30 16:32:14 2010 Subject: knime.org [WAS: Re: [Yanel-dev] Boost access log file format In-Reply-To: <20100629101016.ee7c0372.cedric.staub@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> <20100629101016.ee7c0372.cedric.staub@wyona.com> Message-ID: <4C2B513E.1040409@wyona.com> btw, you might want to have a look at http://www.knime.org/ Cheers Michi Cedric Staub wrote: > On Tue, 29 Jun 2010 09:28:13 +0200 > Cedric Staub wrote: > > >> Anyway, I will try to reply with a patch implementing this shortly. >> > > Here's the patch, I verified that it compiles and works as expected on > my machine (latest revision). > > Greetings > Cedric > From michael.wechner at wyona.com Wed Jun 30 16:55:03 2010 From: michael.wechner at wyona.com (Michael Wechner) Date: Wed Jun 30 17:11:26 2010 Subject: [Yanel-dev] Boost access log file format In-Reply-To: <20100629101016.ee7c0372.cedric.staub@wyona.com> References: <4C28BB9E.1000105@wyona.com> <20100629092813.9a6cd0ef.cedric.staub@wyona.com> <20100629101016.ee7c0372.cedric.staub@wyona.com> Message-ID: <4C2B5AC7.4000308@wyona.com> Cedric Staub wrote: > On Tue, 29 Jun 2010 09:28:13 +0200 > Cedric Staub wrote: > > >> Anyway, I will try to reply with a patch implementing this shortly. >> > > Here's the patch, I verified that it compiles and works as expected on > my machine (latest revision). > It's applied now. Transmitting file data .. Committed revision 50820. Thanks very much Michi > Greetings > Cedric >