xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] Reduce risk of duplicated document id (XWIKI-4396)

by Denis Gervalle

Hi Devs, Since I fall on this well-know XWiki caveat recently, I would like to improve this. Currently, XWikiDocument.getId() is almost equivalent to String.hashcode(fullName:lang). Since this is a really poor hashing method for small changes, the risk that two documents with similar names of same length are colliding is really high. This Id is used by the Hibernate store for document unicity and really needs to be unique, and at most a 64bit-numeric at the same time. Currently we use only 32bits since java hashcode are limited to 32bits integers. The ideal would be not to have this link between ids and documents fullName:lang, but converting the current implementation is not really easy. This is probably why XWIKI-4396 has never been fixed. Therefore, my current goal is to reduce the likeliness of a collision by choosing a better hashing method and taking into account the fact that document fullname are short string and the number of unique ids required are very limited (since the unicity is only expected for a given XWiki database) compared to the 64bits integrer range. So we need to choose a better algorithm, and here are IMHO the potential options: A) use a simple but more efficient non-cryptographic hashing function that runs on 64bits, I was thinking about using the algorithm produced by Professor Daniel J. Bernstein (DJB) since it is well-know, wildly used, easy to implement algorithm with a good distribution on small strings. Pro: no dependency; fast; 64bits better than hashcode Cons: probably more risk of collision compare to MD5 or SHA, but far less than now; require db migration of all document keys B) use an MD5 or even stronger SHA1 or SHA256 algorithm from JCA, truncating to the lower 64bits. Note that oldcore already use MDA5 for hashcoding a whole XWikiDocument to provide the API with a getVersionHashcode(), and for the validation hash used by the persistent login manager. The first use Object.hashcode() as a fallback, which is really bad and defeat the purpose. The second does not provide any fallback and may fail unexpectedly. For our case, if we really want a fallback, we needs to store the hashing algorithm used in the database at creation time, and anyway, fail when it was not available. Pro: already used in oldcore, probably less collision; with fallback, really flexible since it would be possible to choose the algorithm at creation time and does not require full migration for existing database. Cons: require at least a DB schema change to add the hashing algorithm, probably as a column of xwikidbversion; if this config value is broken, the whole DB is broken C) use our own MD5 implementation when the JCA provider is missing it. I was thinking about integrating something like http://twmacinta.com/myjava/fast_md5.php (non-native version) which is LGPL. This will ensure availability of the hashing algorythm while having a rather strong one. Pro: no dependency, could also provide MD5 to getVersionHashcode and the persistent manager Cons: require db migration of all document keys A) is really quick to implement, simple, and the less risky, but some may found it insufficient. Caleb ? Obviously, B) with fallback is really nice, but I wonder if it is not overkill ? I am worried about the B) without fallback, but maybe I want it too flawless C) is rather solid, while staying simple, but maybe overkill too. I am really undecided. WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 4 months

[xwiki-devs] Integrating the workspaces feature into XE/XEM

by Eduard Moraru

Hi devs, As part for the 3.2 Roadmap, the plan for the workspaces feature was to add some hooks into the platform that could accept a workspaces extension if an admin decided to install it. Without adding these hooks, there currently isn`t any mechanism (like Interface Extensions, but not limited to that) that allows a simple application to modify whatever it wishes (like user profile sections, administration sections, top menu, etc.) so I went ahead and added some code into the platform that executes only when the workspaces extension (wiki pages and component/service) is installed. I`ve created http://jira.xwiki.org/browse/XWIKI-6991 with some details about what I have done and made a pull request at https://github.com/xwiki/xwiki-platform/pull/24 since I did not want to rush at applying the changes without running them by you guys. I`ve broken the issue down to subtasks with separate commits to make the review easier. There currently is a demo server for the workspaces feature at http://wiki30-demo.xwiki.com but I will have to update it tomorrow with the latest version. Not much changed, you can see the visible changes in the specific jira subtasks (screenshots). The goal would be for this to make it into 3.2 so that people could then install (the soon to be released) workspaces extension and try it out. Please take some time, if possible, to look over the proposed changes and spot any problems. Thanks, Eduard

13 years, 4 months

[xwiki-devs] Activity Stream not display activity

by interopen

Hello, Using XEM 3.1 only in one of the wikis (others are fine) i not get the Activity stream working, in log it shows this error everytime i go to the webhome page: ERROR o.x.v.i.DefaultVelocityEngine - Left side ($events.size()) of '>' operation has null value at unknown namespace[line 820, column 22] If i remove the the Activity stream gadget it stop to show this error. I try to reinstall Activity and the XE 3.1.xar but the same result. Best Regards, Ivan -- View this message in context: http://xwiki.475771.n2.nabble.com/Activity-Stream-not-display-activity-tp68… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 4 months

Re: [xwiki-devs] [VOTE] Stop packaging oscache implementation of the cache API by default with XE (summary)

by Thomas Mortagne

3 +1 and one 0, done. On Tue, Sep 20, 2011 at 2:32 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi devs, > > We never use it AFAIK so I propose to remove it from default XE distribution. > > XE is pretty big right now so would be cool to reduce its size when possible. > > WDYT ? > > -- > Thomas Mortagne > -- Thomas Mortagne

13 years, 4 months

[xwiki-devs] [VOTE] Change work/persistent directory name set in XE/XEM build from "work" to "data"

by Thomas Mortagne

The idea is that work is not clean enough is about persistent datas. WDYT ? -- Thomas Mortagne

13 years, 4 months

[xwiki-devs] [VOTE] Stop packaging oscache implementation of the cache API by default with XE

by Thomas Mortagne

Hi devs, We never use it AFAIK so I propose to remove it from default XE distribution. XE is pretty big right now so would be cool to reduce its size when possible. WDYT ? -- Thomas Mortagne

13 years, 4 months

[xwiki-devs] [Proposal] Postpone XE 3.2M3 release and RC1

by Vincent Massol

Hi devs, We're doing bad with our release schedule for 3.2 ATM. We're already late by 1 week and we're still lagging. Outstanding blockers: - recent discussions with new Sheet module strategy for page naming conventions. (Owner: Marius) - default permanent storage directory location to finish (Owner: Thomas?) - lucene improvements not committed yet (Owner: Sergiu) - failing functional tests to fix (Owner: everyone) Thus I propose that: - we don't add new stuff to master except bug fixes and commits related to the issues above - we push the 3.2M3 release to Monday 26 Sep. This means being ready to release this Thursday 22nd so that we can be sure we'll release on Monday 26. - we push the 3.2RC1 release to Monday 3rd of October (one week after M3 only) - 3.2Final stays on the 10th of October. WDYT? Thanks -Vincent

13 years, 4 months

[xwiki-devs] [Proposal] Default directory for Extension Manager

by Vincent Massol

Hi devs, Thomas just told me that he's made a change for Extension Manager (apparently there was a vote for it and I missed it - I can't find it so if anyone has the link please point me to it) and that by default now the Extension Manager uses the temporary directory to store installed extensions (Before it was using ~/.xwiki). I thus want to throw my -1 to release 3.2 final with this (I'd also much prefer if 3.2M3 doesn't have it as much as possible). The reason is that the tmp/ directory can get wiped anytime and the user can thus suddenly loose all its installed extensions. I believe we need a permanent location for that. We have 2 general options IMO: 1) Don't start xwiki if the work directory is not explicitly configured 2) Make the default EM work directory be the same as before (ie ~/.xwiki), when the work dir config property is not defined I also want to propose that for the standalone distribution of XE (the jetty/hsqldb package) we use work/ as the work directory. We already create this directory and we should use it (it's already used by our lucene indexing BTW). WDYT? Thanks -Vincent

13 years, 4 months

[xwiki-devs] [VOTE] Sheet resolution algorithm

by Marius Dumitru Florea

Hi devs, Here's the sheet resolution algorithm I have implemented in https://github.com/xwiki/xwiki-platform/blob/cbad868094b9cc9d811621670e3205… . getSheets(document, action) : List<DocumentReference> (1) If there is a "sheet" request parameter that points to a sheet that supports the passed action, return a reference to that sheet. (2) For each object of type XWiki.DocumentSheetBinding attached to the passed document check if the "sheet" property points to a sheet that supports the passed action. Return the computed list, if not empty. (3) For each type of object attached to the passed document: (3.1) For each object of type XWiki.ClassSheetBinding attached to the document defining the class check if the "sheet" property points to a sheet that supports the passed action. (3.2) If the class doesn't have any XWiki.ClassSheetBinding object then check if <ClassName><ActionName>Sheet exists (3.3) If not, then check if <ClassName>Sheet exists and supports the passed action (3.4) If not, then check if "sheet.defaultClassSheetBinding" configuration property specifies a sheet for the class we're looking at Return the computed list if not empty. (4) If the passed document is a class (holds a class definition) then return a reference to the default class sheet (XWiki.ClassSheet) if it supports the passed action. Otherwise return an empty list. I'd like you to vote on each of the steps of the algorithm. Are there steps you think I should drop? I'm obviously +1 for each of the steps. Thanks, Marius

13 years, 4 months

[xwiki-devs] New sheet system and backward compatibility

by Marius Dumitru Florea

Hi devs, One of the features of the new sheet system is that it can automatically detect and apply sheets. For instance, if you have: Space.YourClass (no objects) Space.YourClassSheet (no objects) Space.YourDocument (with an object of type YourClass and no include macro call to YourSheet in the content) YourDocument will be automatically displayed with YourSheet. This introduces a backward compatibility problem because the new sheet system will be triggered for existing XWiki applications that haven't been updated to use the new system. One way to prevent this is to trigger the new system only if XWikDocumenti#getDefaultEditMode() returns "edit" (it should return "inline" for current XWiki applications). XWikiDocument#getDefaultEditMode() uses two classes, EditModeClass and SheetClass, to determine the default edit mode. EditModeClass was recently introduced so most of the current XWiki applications are still using the deprecated SheetClass. In the new sheet system I needed a class to describe a sheet and I opted for reusing the name of an existing class, SheetClass, because IMO it is the best name for a class describing a sheet. As a consequence the current implementation of XWikiDocument#getDefaultEditMode() will return "inline" if you try to include a sheet in the content of a document. This limits the new sheet system because you should be able to do anything with the document content, even including another sheet. I talked with Vincent about this and we found three solutions: (1) Change XWikiDocument#getDefaultEditMode() to use only the EditModeClass. The breaks backward compatibility because current applications have to update their sheets to use EditModeClass instead of SheetClass (if they want to keep the old behavior) (2) Use XWikiDocument#getDefaultEditMode() only if a backward compatibility configuration flag is set. This means that the limitation I mentioned above (can't include a sheet in the document content) will be true only if you want backward compatibility. (3) Use a different name for the class describing the sheet, e.g. SheetDescriptorClass. This way XWikiDocument#getDefaultEditMode() will keep returning "inline" for applications that are still using the deprecated SheetClass. I'm going to implement (3) if no one is against it. Thanks, Marius

13 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs