xwiki-devs September 2011

xwiki-devs@xwiki.org

23 participants
65 discussions

[xwiki-devs] Determine the sheet on create

by Marius Dumitru Florea

Hi devs, I'm working on a sheet management module (see https://github.com/xwiki/xwiki-platform/compare/feature-sheets ) and I have an issue. My component returns the list of sheets "registered" for a document or a class. The component methods take document references as input. The consequence is that my component always "queries" the saved document (taken from the database/cache). I have modified the edit.vm template to check if there is a sheet available for the current document. It works great with one exception: when you create a document (e.g. when you create a blog post). The problem is this: although the information required to detect the sheet is present on the current/context document (e.g. it has an object of type BlogPostClass) my component fails to access this information because the document wasn't saved, it doesn't even exist. The reason I used document references on my component interface is obvious: I didn't want to depend on the core (at least not the interface, because the implementation does right now). The solution to keep the current component interface is to explicitly specify the sheet on the edit URL (only) for the create form. For instance, replace: /edit/Blog/MyNewBlogPost?template=Blog.BlogPostTemplate with: /edit/Blog/MyNewBlogPost?template=Blog.BlogPostTemplate&sheet=Blog.BlogPostSheet but I think it's a bit too much to ask from the application developers. Another solution, suggested by Thomas Mortagne, is to: * change the component interface to use DocumentModelBridge (which is implemented by XWikiDocument) instead of DocumentReference (=> keep the interface independent of old core) * change the script service to use api.Document instead of DocumentReference, and to extract the XWikiDocument from it through reflection, to avoid programming rights issues. It's not a clean solution but it is better from the application developers' point of view. WDYT? Any alternatives? Thanks, Marius

13 years, 3 months

[xwiki-devs] [VOTE] Add hasWikiAdminRights() method to XWikiRightService and api.Api to avoid confusion and security issues

by Eduard Moraru

Hi Devs, The current hasAdminRights(XWikiContext) method checks if the current user has admin rights on the current wiki or on the current space. However, the javadoc currently available (and also general knowledge) did not include the "or current space" part and the method ended up being used in places where admin right for the current space was not enough to allow performing certain actions (ex. wiki manager plugin, etc.) While it is still useful to check for admin right on wiki or space, it is more useful to have a method that checks admin right only for the wiki (stronger admin). Using the current api, it's cumbersome to have to specify "XWiki.XWikiPreferences" each time so I propose adding a new method to handle this: /** * Checks that the current user in the context (the currently authenticated user) has administration rights on the * current wiki, regardless of any space admin rights that might also be available. * * @param context the xwiki context of this request * @return {@code true} if the current user in the context has the {@code admin} right, {@code false} otherwise */ public boolean hasWikiAdminRights(XWikiContext context); And, obviously, the fixed javadoc for hasAdminRights(XWikiContext). You can check out the pull request at https://github.com/xwiki/xwiki-platform/pull/22 Here's my +1 Thanks, Eduard P.S.: Existing code using the hasAdminRights(XWikiContext) method will have to be adjusted accordingly.

13 years, 3 months

[xwiki-devs] Performance of synchronization in XWiki.

by Caleb James DeLisle

I ran some testing by injecting printline statements after the beginning of each synchronization block in all of the xwiki codebase and then ran some tests. xwiki webstandards test: pages loaded: 925 synchronization blocks entered: 2,512,524 synchronizations per page: 2,716 Excluding the first page load on start-up, these are the total synchronizations from running the webstandards tests. Note that they don't add up to exactly 2,512,524 because some were spoiled when 2 threads tried to write to stdout simultaneously. Total Percent Location 1651401 65.73% XWikiCacheStore.java:115 316411 12.59% EmbeddableComponentManager.java:352 142094 5.66% XWikiContext.java:260 103028 4.10% XWiki.java:5380 58151 2.31% XWikiContext.java:282 54891 2.18% XWiki.java:5455 46324 1.84% DefaultVelocityFactory.java:72 46320 1.84% DefaultVelocityFactory.java:82 29447 1.17% EmbeddableComponentManager.java:138 15010 0.60% DefaultBeanManager.java:204 14595 0.58% DefaultXWikiRenderingEngine.java:239 10933 0.44% URIClassLoader.java:438 3812 0.15% XWiki.java:5406 3262 0.13% DefaultVelocityEngine.java:227 3262 0.13% DefaultVelocityEngine.java:245 2867 0.11% XWikiNotificationManager.java:130 1941 0.08% XWikiGroupServiceImpl.java:798 958 0.04% XWikiConfigurationService.java:50 958 0.04% XWikiNotificationManager.java:254 958 0.04% XWikiNotificationManager.java:265 957 0.04% XWikiCacheStore.java:704 951 0.04% XWikiNotificationManager.java:230 949 0.04% XWikiNotificationManager.java:241 917 0.04% XWikiNotificationManager.java:219 852 0.03% XWikiStatsServiceImpl.java:182 371 0.01% XWikiDocumentQueue.java:88 351 0.01% XWikiDocumentQueue.java:55 142 0.01% XWikiDocumentQueue.java:69 112 0.00% XWikiDocumentQueue.java:98 66 0.00% AdminAction.java:57 24 0.00% RightsManager.java:164 15 0.00% EditAction.java:59 UI tests were also run to give a more well rounded view of what real traffic might look like: 1666727 57.98% XWikiCacheStore.java:115 463369 16.12% EmbeddableComponentManager.java:352 234027 8.14% XWiki.java:5380 175972 6.12% XWikiContext.java:260 70156 2.44% XWikiContext.java:282 65952 2.29% XWiki.java:5455 43553 1.52% DefaultVelocityFactory.java:72 43552 1.52% DefaultVelocityFactory.java:82 33512 1.17% EmbeddableComponentManager.java:138 13451 0.47% DefaultBeanManager.java:204 9650 0.34% DefaultXWikiRenderingEngine.java:239 9450 0.33% XWikiNotificationManager.java:130 5176 0.18% XWikiGroupServiceImpl.java:798 5019 0.17% URIClassLoader.java:438 3965 0.14% XWiki.java:5406 2850 0.10% DefaultVelocityEngine.java:227 2850 0.10% DefaultVelocityEngine.java:245 2717 0.09% XWikiConfigurationService.java:50 2694 0.09% XWikiCacheStore.java:704 2624 0.09% XWikiNotificationManager.java:219 2624 0.09% XWikiNotificationManager.java:230 2624 0.09% XWikiNotificationManager.java:241 2590 0.09% XWikiNotificationManager.java:254 2590 0.09% XWikiNotificationManager.java:265 749 0.03% XWikiDocumentQueue.java:69 718 0.02% XWikiStatsServiceImpl.java:182 554 0.02% XWikiDocumentQueue.java:88 550 0.02% EmbeddableComponentManager.java:201 476 0.02% XWikiDocumentQueue.java:55 406 0.01% XWikiHibernateVersioningStore.java:142 403 0.01% XWikiNotificationManager.java:140 403 0.01% XWikiNotificationManager.java:155 403 0.01% XWikiNotificationManager.java:167 403 0.01% XWikiNotificationManager.java:181 403 0.01% XWikiNotificationManager.java:194 403 0.01% XWikiNotificationManager.java:206 282 0.01% XWikiDocumentQueue.java:98 209 0.01% EditAction.java:59 101 0.00% RightsManager.java:164 81 0.00% AdminAction.java:57 61 0.00% EmbeddableComponentManager.java:289 52 0.00% EmbeddableComponentManager.java:256 44 0.00% LucenePlugin.java:656 35 0.00% InlineAction.java:39 23 0.00% DefaultCSRFToken.java:130 19 0.00% MutableHttpServletRequestFactory.java:43 15 0.00% AbstractGenericComponentManager.java:93 13 0.00% LucenePlugin.java:450 5 0.00% XWikiNotificationManager.java:56 2 0.00% MacroRepository.java:65 2 0.00% XWiki.java:408 1 0.00% ActivityStreamCleaner.java:89 1 0.00% EmbeddableComponentManager.java:163 1 0.00% EmbeddableComponentManager.java:269 1 0.00% RightsManagerListener.java:85 1 0.00% SchedulerPlugin.java:561 1 0.00% StackingComponentEventManager.java:69 1 0.00% XWikiGroupServiceImpl.java:150 1 0.00% XWikiGroupServiceImpl.java:162 1 0.00% XWikiGroupServiceImpl.java:180 1 0.00% XWikiHibernateBaseStore.java:142 1 0.00% XWikiHibernateBaseStore.java:265 1 0.00% XWikiHibernateBaseStore.java:557 1 0.00% XWiki.java:5493 1 0.00% XWiki.java:5515 These numbers seem to be quite conclusive that XWikiCacheStore.java:115 is the lowest hanging fruit in the synchronization field. An examination of XWikiCacheStore reveals that the "per load" synchronization should be avoidable if it is not lazy initialized and is flushed differently. Is synchronization the best place to attack for performance gains? Synchronization cost is difficult to measure because it varies based on number of processor cores and processor sockets. In the worst case, the caches in multiple cores on multiple processor sockets all need to be flushed and this would be the case with high contention mutexes. As a matter of good practice, I think we should reduce the amount of synchronization as much as is reasonable. Caleb

13 years, 3 months

[xwiki-devs] [Discussion] Generate and publish sources for snapshot builds in the CI

by Eduard Moraru

Hi devs, I was wondering why we don`t generate source artefacts for snapshots, just like we do for final versions? While I do agree that final versions are the important ones, it's often very annoying to have to manually add sources from the filesystem (assuming you have cloned locally the git repo) for all the maven modules that you want to see the code or even the javadoc or method parameter names. For final releases we don`t have that problem because Eclipse and the Maven plugin (for example) can automatically download the sources in the background providing an effortless process. However, while working with snapshots, you are nagged continuously that the sources can not be found automatically and you experience a bit of unneeded frustration :). Not only that Would it be that much of a storage penalty for the extra sources jars to accompany the snapshot builds? Would it be that much of a build time penalty for actually generating source builds for each artefact? WDYT? Thanks, Eduard

13 years, 3 months

[xwiki-devs] Small widget possibly of interest : ajaxify forms in popups

by Jerome Velociter

Hi all, I've written a small Ajax widget for XWiki that magically ajaxifies a form in a modal popup. Right now I have no use for it directly in XWiki, but I though it would worth advertising it here as this might come handy at some point for the platform. It even works with multipart forms. The widget is here : https://gist.github.com/1184560 Regards, -- Jérôme Velociter Winesquare http://www.winesquare.net/

13 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2011