- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [API BREAK] Fixing the directory structure of xwiki-store-filesystem-attachments.
by Caleb James DeLisle 01 Oct '11

01 Oct '11

When I made xwiki-store-filesystem-attachments, I made a mistake, I put the files which directly interface with the old core into the com.xpn.xwiki package. I realize it was a mistake not to ask about it and now I would like to correct it. This is an API break because these classes not under an /internal/ dir and are considered by clirr to be API. Since this implements interfaces which are defined in the old core, bridging is obviously impossible I would like to indicate somehow that those classes deal directly with old core and thus will be removed with it when the time comes. A) replace com.xpn.xwiki with org.xwiki.store.internal.legacy this will show that they are essentially with legacy code. B) replace com.xpn.xwiki with org.xwiki.store.filesystem.internal this will mix all of the implementations of oldcore interfaces with classes which provide services to them. Any other ideas? Caleb user@debo8:~/wrk/xwiki.git/xwiki-trunks/xwiki-platform/xwiki-platform-core/xwiki-platform-store/xwiki-platform-store-filesystem-attachments$ find

1 0

[xwiki-devs] [Proposal] XEclipse Release
by Vincent Massol 30 Sep '11

30 Sep '11

Hi devs, Fabio and Eddy are working on merging Jun's GSOC code in master for XEclipse and are preparing for a release (could you send us a proposal guys?). It seems that the last release of XEclipse was 1.2RC1 so it's a bit of a shitty situation since normally so much change would have warranted a 1.3 release. However I'm proposing that the next release be 1.2RC2 and when we've tested it enough we then quickly release 1.2 final to get it over with. The alternative is to: - get the 1.2RC1 tag - release it again as 1.2 final - consider all Jun's changes to be 1.3M1 However that solution has 2 issues: - it's more time consuming - we're not 100% sure that the last 1.2RC1's quality was good enough to be named 1.2 final WDYT? My preferences goes to having Jun's code be in a 1.2RC2 release. Thanks -Vincent

4 6

[xwiki-devs] [VOTE] Generalize concept of legacy module to XWiki Commons and even more generally
by Vincent Massol 30 Sep '11

30 Sep '11

Hi devs, I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise). The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module. My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module. Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step. It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it). Here's my +1 to follow this practice across our code base and to document it on xwiki.org Thanks -Vincent

5 10

[xwiki-devs] [VOTE] Release XWiki Enterprise+Manager 3.1.1
by Sergiu Dumitriu 29 Sep '11

29 Sep '11

Hi devs, Since the 3.2 release is approaching, I'd like to close the stable 3.1.x branch as well with a final 3.1.1 release, probably on October 3rd. If you have any important bugfixes you want to see in this release, please push them ASAP. -- Sergiu Dumitriu http://purl.org/net/sergiu/

5 4

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 Milestone 3 released
by Sergiu Dumitriu 28 Sep '11

28 Sep '11

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.2 Milestone 3, the last milestone of the XWiki Enterprise 3.2 version (see the roadmap at http://enterprise.xwiki.org/xwiki/bin/Main/Roadmap ). Main new features include: * improved Lucene scoring * new implementation of the sheet system * support for OpenOffice 3.3 as the backend of the office importer * better support for IE9 in the WYSIWYG editor * many improvements in the extension manager and extension repository * the removal of the Albatross skin from the distribution * ... and quite a lot of dependency upgrades and bug fixes See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32M3 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] What happens when you do a permissions check and how it can happen faster.
by Caleb James DeLisle 27 Sep '11

27 Sep '11

Hi folks, I decided to do an analysis of how exactly how permissions are checked so we might be able to brainstorm about where there is low hanging fruit in the optimization field. 0. Check that the user is authenticated 1. If user is attempting write operation on read-only wiki, return false. 2. If user is a guest, get XWikiPreferences for the wiki and do 4 checks on the XWikiPreferences object to see if the action requires authentication. 3. If action is "delete", get current document and check if current user created that document. 4. Determine if user is superadmin 5. Load DocumentReferenceResolver from ComponentManager and normalize username then compare to superadmin name. 6. Check for admin status on main wiki 7. Get XWikiPreferences document for main wiki 8. scan for rights objects which allow the user "admin" permission, return if found 9. get list of all groups which user is a member of, repeat check for each, returning if found 10. If checking permission for "programming" then repeat from step 7 with "programming" as permission. 11. If the permission being checked is programming, return the result even if false. 12. If in a subwiki, get the XWikiServer<subwiki> document and return if the current user is the owner. 13. If checking for register permission then get the XWikiPreferences document for the wiki. 14. scan for rights objects which allow the user, return if found 15. get list of all groups which user is a member of, repeat check for each, returning if found 16. if no match is found, check for deny rights on the user, return if found 17. get list of all groups which user is a member of, repeat check for each, returning if found 18. Get XWikiPreferences from wiki 19. scan for rights objects which allow the user "admin" permission, return if found. 20. get list of all groups which user is a member of, repeat check for each, returning if found 21. Get WebPreferences for space where document to check permissions resides. 22. scan for rights objects which allow the user "admin" permission, return if found. 23. get list of all groups which user is a member of, repeat check for each, returning if found 24. if the WebPreferences document specifies another Space as it's "parent" then change to that space and return to step 21. 25. Get the document to check permission on 26. scan for rights objects which deny the user, return if found 27. get list of all groups which user is a member of, repeat check for each, returning if found 28. scan for rights objects which allow the user, return if found 29. get list of all groups which user is a member of, repeat check for each, returning if found 30. Get the WebPreferences document for the space where document to check permission on resides. 31. scan for rights objects which deny the user, return if found 32. get list of all groups which user is a member of, repeat check for each, returning if found. 33. scan for rights objects which allow the user, return if found 34. get list of all groups which user is a member of, repeat check for each, returning if found. 35. Check if the WebPreferences document specifies a "parent space" if so, change to that space and go to step 30. 36. Get the XWikiPreferences document for the wiki 37. scan for rights objects which deny the user, return if found 38. get list of all groups which user is a member of, repeat check for each, returning if found 39. scan for rights objects which allow the user, return if found 40. get list of all groups which user is a member of, repeat check for each, returning if found Getting the list of groups which a user is a member of is relatively quick after the first run since it is cached. After being loaded it is stored in the context but the implementation doesn't trust the version in the context and gets it again. It could be a little bit faster by just assuming that anything in the context is still valid. If a group is a member of another group then the checks will be repeated twice each time. One thought that comes to mind is that we could check permissions on a user and all of the groups of which he is a member, simultaneously. This would reduce the number of scans over the list of objects in a given document and since this is such a hotspot, I think optimizations like this might pay off. Documents which need to be loaded include: The XWikiPreferences for the main wiki XWikiPreferences for the subwiki (if applicable) WebPreferences for the space (and any space listed as a parent) The document which we are checking If in a subwiki, the XWikiServer<subwiki> document This means that for any level of performance, all documents other than the document we are checking need to remain in the cache perpetually. Since the vast majority of checks are for things like view and edit with users who don't have programming or admin permission, it makes sense to rearrange the checks so that the most common path executes the fastest. This would be a major project though. Any other thoughts and ideas about it? Caleb

2 1

[xwiki-devs] Fresh install of XWiki Enterprise Manager required
by David Henry 26 Sep '11

26 Sep '11

Hi Guys, I need a fresh install of XWiki Enterprise Manager. Drop me a line if you're interested. David Henry** *Modus* * * 18 Exchange Street Upper, Temple Bar, Dublin 2, Ireland. e: david(a)modus.ie | p: +353 1 677 9745 | m: +353 86 8300943

1 0

[xwiki-devs] [VOTE] Workspaces extension as part of the platform in 3.2
by Eduard Moraru 25 Sep '11

25 Sep '11

Hi devs, I`m asking for your vote to include Workspaces [1] as an extension that would be part of the platform for the 3.2 release. It would not be bundled by default just yet, but it will be available to install as an extension using the Extension Manager. This vote is related to the previous mail [2] I`ve sent about adding some hooks in the platform specifically for the workspaces feature. The difference now is that the feature would no longer be an "external" extension but it would be supported and maintained by XWiki devs (me). This means accepting the technical debt introduced by the proposed hooks [2] and making it my responsibility to maintain the application and ensure the hooks are gradually removed from the platform when cleaner alternatives are introduced. An overview of the workspaces feature is available in the project preview mail [3] (or even [4]) I`ve sent some time ago that included the live demo [5]. Thanks, Eduard References: ----------------- [1] https://github.com/xwiki-contrib/wiki30/tree/master/wiki30-social [2] http://xwiki.markmail.org/thread/qgjcehgmqpkbwbvw [3] http://xwiki.markmail.org/thread/223ensce4tikygmz [4] http://xwiki.markmail.org/thread/3cbms22ctbqi4yqp

7 6

Re: [xwiki-devs] [VOTE] (Result) New database version numbering
by Denis Gervalle 23 Sep '11

23 Sep '11

On Fri, Sep 16, 2011 at 18:04, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > On 09/16/2011 10:04 AM, Denis Gervalle wrote: > > Hi Devs, > > > > Last database migrator is very old now, it was on revision 15428 of our > SVN > > repository. > > The rules at that time was to use the revision number of the SVN commit > for > > the database version. > > So our database is currently in version 15428. > > > > Since we have no more revision number in Git, and that the database > version > > should be an integer, we need to vote a new convention: > > > > A) continue from where we are, incrementing by one, so next version > will be > > 15428 > > > > B) use 16000, or another round number for next revision and increments > by > > one for next version > > > > C) use a mix with the current XWiki version, so next will be 32000, and > we > > have room for 1000 versions during the 3.2 releases. > > D) Count the number of git commits on the trunk, with: > > git log --oneline | wc -l > > This would give a number equivalent to the SVN revision number. > Well, not really, it only follow a single branch of commits, while SVN revision are global to a repository > > Personally, since database changes are really rare, since we were already > > jumping, and since there is plenty of room for number, I prefer meaning > > full number and I prefer C. The major advantage is that the number is in > the > > database, so if you have a db dump, you may quickly know what is the > oldest > > version this dump is compatible with without needing some reference list. > > > > So my +1 for C. > > I prefer to use something more stable, and C) looks like the better > option for me as well. > So we agree on C) with four +1, no 0, no -1 > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

1 0

[xwiki-devs] [Proposal] Fix many inconsistencies in schema updates and database migrations
by Denis Gervalle 23 Sep '11

23 Sep '11

Hi devs, After some analysis of XWiki startup, there is many issues in the way DB schema is updated and migrators are executed (see XWIKI-1859, XWIKI-2075 and XWIKI-2066). There is no consistency between them, which really seems not appropriate. The schema is updated in many different places (unless disabled by config): - when UpdateDatabase is called for the first time; this one being called anytime we access a sub-wiki in a farm - when CheckHibernate is called and no session factory exists, this one being called in many places and before any transaction based requests - before a migration of a sub-wiki db The update schema function itself as some issue as well: - it is a synchronized function and the config check is done after synchronization - a part from the schema update done by the generated hibernate script, it does some updates on data in the database like a migrator, but it does so even when there is no need for an updated oppposed to a migrator - these updates are written in plain SQL, not HQL, and partly MySQL oriented. - it use a different parameter than migrator in xwiki.cfg to be disabled, so it is possible to have migration without having the correct schema On the other hand, migrator are launch only on initial startup opposed to the lazy updating of schema. Since we use struts, it was no easy to have them launch before the first request, but I do see this as an issue since any admin will at least do such a request, and a request would not be accepted earlier anyway. The issue with migrators are: - migrators are executed on new XWiki database. In particular, when you create a new wiki in a farm, no version are set in the DB, and the next time the servlet container is restart, all migrator are executed on this new wiki database. - migrators may fail and the wiki start anyway (I have already a patch for that) - migrators could be disabled, but there is no guarantee that a database is at the correct version for the running core. This is particularly annoying for my migration, since old id could be kept, and document loading will fails for mandatory document, so these will be recreated, producing many duplicated document in the database, and therefore corrupting all accessed wikis that have not been migrated. So, I proposed: 1) to join together schema update and migration, using xwiki.store.migration (default to 0) && xwiki.store.hibernate.updateschema (deprecated, default to true already) && xwiki.store.migration.databases (default to main wiki only) for enabling them 2) convert migration like requests done in schema update into an very old migrator (before first one) 3) While still allowing migrators (and therefore schema update) to be disabled, keep a lazy check on the database version required by the running core. a) fails to return a given wiki if its database is outdated b) OR do a lazy update if migration is enabled 4) store the current DB version of the core in the database when creating new wikis 5) consider a DB without version and without xwikidoc table to be empty and at the current version For this to be implemented, I need to know the current core DB version at startup. I see some ways to do that: A) store it in a constant in a static in XWiki class, putting the responsibility on migration developer to update it B) compute this value by instantiating all migrators to know there resulting DB version a) and store it in the XWiki singleton b) and cache this in the migration manager, keeping it available from the current XWiki singleton, for potential lazy migration I am +1 for most of these, except 3)b) for which I am not sure it is fully safe, and which implies B)b). I am undecided regard A) or B)a), with a preference for the second, but wondering if it should consider xwiki.store.migration.ignored or not (probably not). WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

1 0