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

[xwiki-devs] [Vote] Release XEM 1.2 RC 1
by Thomas Mortagne 13 May '08

13 May '08

Hi, Now that XE 1.4RC1 is release I would like to follow with XEM 1.2RC1 on next Tuesday. It add the wiki name ajax based validation to the wiki creation page and XE 1.4M2 -> XE 1.4RC1 dependency upgrade. See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM12RC1 Here is my +1 -- Thomas Mortagne

4 5

[xwiki-devs] New cache component
by Thomas Mortagne 13 May '08

13 May '08

Hi devs, I'm working on a new cache component (http://jira.xwiki.org/jira/browse/XWIKI-2359) to replace the current cache service. For this I'm refactoring a little the API to improve extensibility. I will explain what I modified and I would like to have your point of views, suggestions and corrections on all this. First of all, how the current service works : You ask for cache service (which is more a factory than a service in fact) containing two major type of factory methods : - get a cache : create and return a new local or distributed (depends of the implementation) cache where you can put and retrieve object to cache with eventually a refresh period - get a local cache : force to get a cache store in the local computer All these methods return the same XWikiOSCache interface. I did not made lots of big modifications (as I want to be sure to correctly support all current service support), the main difference with the cache service (except the fact it now a factory component) is that I separate "normal" cache factory and "local" cache factory in two separate plexus roles. That way it could have different implementations configured in the xwiki.cfg like xwiki.cache.cachefactory.hint=memcache xwiki.cache.localcachefactory.hint=oscache And XWiki now contains getCacheFactory and getLocalCacheFactory methods in place of getCacheService. As a first example I moved the oscache cache service implementation as component : I attached a patch for it in http://jira.xwiki.org/jira/browse/XWIKI-2359 Thanks, -- Thomas Mortagne

1 0

Re: [xwiki-devs] [xwiki-notifications] r9649 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki
by Vincent Massol 13 May '08

13 May '08

Hi Sergiu, On May 5, 2008, at 7:59 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-05-05 19:59:18 +0200 (Mon, 05 May 2008) > New Revision: 9649 > > Modified: > xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java > Log: > [misc] Fix NPE during tests > > > Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/ > xwiki/XWiki.java > =================================================================== > --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-05-05 16:57:49 UTC (rev 9648) > +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-05-05 17:59:18 UTC (rev 9649) > @@ -3580,7 +3580,9 @@ > // doc.getOriginalDocument() > ObservationManager om = > (ObservationManager) > Utils.getComponent(ObservationManager.ROLE, null, context); > - om.notify(new DocumentDeleteEvent(doc.getFullName()), > doc, context); > + if (om != null) { > + om.notify(new > DocumentDeleteEvent(doc.getFullName()), doc, context); > + } Question: Utils.getComponents throws a RuntimeException when a component cannot be found. Thus I'm not sure why you're testing for null? Am I missing something? In addition I think that if we really wanted to test for null then we should also have an else and display a warning if a notification cannot be sent. However I don't think it's normal that such a component cannot be lookup and we can safely assume it is found. The test should probably be modified to use AbstractXWikiComponentTestCase. WDYT? Thanks -Vincent

2 1

[xwiki-devs] XE 1.4RC1 release and outstanding issues
by Vincent Massol 13 May '08

13 May '08

Hi devs, Since JV and I are at Javaone, Thomas Mortagne has kindly accepted to become the release manager for XE 1.4RC1. I've quickly reviewed the jira list of outstanding issues and I think the following should be fixed before the RC1 release: http://jira.xwiki.org/jira/browse/XWIKI-2274 http://jira.xwiki.org/jira/browse/XWIKI-1809 Also we need to verify that the Lucene plugin works fine and doesn't throw any error when we start XE and leave it running for a few minutes as it used to do (I think Sergiu fixed this). Anyone knows of any crucial outstanding issue for 1.4RC1? Note that RC1 means that it's a release candidate for being promoted to 1.4 final in a few days if its stable enough. The release was planned for last Friday so we need to set a new release date (tomorrow would be great). I'll let Thomas propose a date. Thanks -Vincent

5 8

Re: [xwiki-devs] Proposal for the new Administration
by Sergiu Dumitriu 13 May '08

13 May '08

Evelina Slatineanu wrote: > Hi Guys, > > > > I am working on XE-14 (the new Administration UI) > http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration . > > Since the admin templates will be deleted and replaced by an AdminSheet > which will be included by default in XwikiPreferences (wiki level) and > WebPreferences (space level), I need to create the WebPreferences document > for each space, attach an Xwiki.XwikiPreferences object to it and include > the AdminSheet. > > > > To do that, I need to write some java code in the core . So , here's my > proposal: > > > > - At xwiki intitialization create all the WebPreferences for the > currently existing spaces in the wiki (this should be done for all the > wikis, if in a multi-wiki). > > - Then, use a notification system to create the WebPreferences for > any new space in the wiki in one of two ways: > > a) When calling the "view" action on AnySpace.WebPreferences, check if > it exists, if not create it, attach the obj. and include the sheet > > b) When calling the "save" action on AnySpace.AnyDoc, check if > AnySpace.WebPreferences exists, if not, create it etc. > a) should be used, as there will probably be more save calls on ALL documents in a space, than view on one administration document. Plus, I can view the administration page before saving any document in that space, right? And anyway, the check is not that expensive. > > I am for the second one, since the 'view' is much more often performed than > 'save'. > > So, my questions: what should I use for the notifications? I found this > function in the Stats notification system: > > > > // Adding the rule which will allow this module to be called on each page > view > > context.getWiki().getNotificationManager().addGeneralRule( > > new XWikiActionRule(this, true, true)); > > > > But Thomas said the method above registers all types of notifs, not only on > page view. > > There is also: > > > > notify(XWikiNotificationRule rule, XWikiDocument doc, String action, > > XWikiContext context) > > > > and I can perform an if(action == "save") to use the notif system for the > "save" action. > > > > Thomas Mortagne also told me that this notif system is a little bit outdated > and would be replaced by the observation component, but I have no idea which > I should use. > Use the new observation component. The code is in trunks/xwiki-platform-core/xwiki-observation, but there's no example yet on how to register a new listener. I can help you with that, if you want. > > Also, according to the specifs in the draft above, so far I created the > Xwiki.AdminSheet, that will display the main categories (General, > Presentation, Rights, Users, Groups, Import/Export etc). For each section of > this menu I created a sheet (General - > Xwiki.GeneralSheet etc.) in which I > can personalize the display. I also created Xwiki.AdminSectionSheet which > contains the common code to display the fields necessary from the > Xwiki.XwikiPreferences object and this sheet will be included in the > sections where is needed (Genera, Presentation etc.) The reason I created > separated sheets for each section of the menu (which are fixed as number) is > to keep the code clean and allow the possibility to display something else > than fields from the xwiki prefs. object (for example for rights, users, > groups, import/export). > +1 for several distinct sheets. More extensible and modular. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] Deprecating all the APIs in favor of a Velocity uberspecting chain
by Sergiu Dumitriu 13 May '08

13 May '08

Hi devs, As suggested by Vincent, it would be cool not to have a distinct API for usage from velocity scripts, but pseudo-wrap the Java classes into a scriptable API using some uberspectors/introspectors. I like this idea a lot, as it is a bit hard to maintain two APIs (as the internal core is an API, just that it isn't directly scriptable), and with the new component architecture, the scriptable API would be completely unneeded. To remind, introspectors are used for finding the right methods to be called, given the target object, the method name, and the parameters; uberspectors must use introspector's results to construct velocity-specific objects for direct method calls ($something.methodCall()), getters (#set something = $object.getter), setters (#set $object.setter = something) and iterators (#foreach $iterator in something). During the last few days I wrote a chaining uberspector, that allows chaining several uberspectors, and a introspector chaining uberspector, that allows chaining several introspectors (not committed yet). The idea would be to have something like: [(introspector <- ... <- introspector)>- IntrospectorChainingUberspector <- Uberspector <- ... <- uberspector]>- ChainingUberspector Introspectors are chained in order to find or to filter out requested methods, then uberspectors use these methods to further enhance or restrict the method retrieving & calling process. So, a possible chain would be: BaseIntropector - finds methods using reflection. SecureIntrospector - filters out restricted objects/methods, like reflection, classloaders, threads/synchronization and the System class. ScriptableCheckIntrospector - blocks all direct calls to methods in the org.xwiki package that don't have an @Scriptable annotation. Note that it is possible to have calls to non-scriptable methods inside scriptable methods, as that is java code already, outside scripting. RightsCheckingIntrospector - uses the @Authorisation("accessright") annotations placed on our methods to perform rights checking. ProgrammingWrapIntrospector - not sure about this one, as I don't know how it could be implemented, but it would be nice to mimic all *WithProgrammingRights methods (like saveWithProgrammingRights), instead of literally having them in the java classes. ContextInjectionIntrospector - if no method was found, tries to find a method with an extra XWikiContext parameter. I must find a way to pass the request-specific XWikiContext (Vincent, any ideas?). This one is needed because all current API methods hide a non-scriptable method with almost the same signature, just an extra XWikiContext parameter at the end. This might not be needed if we completely get rid of the XWikiContext from the code before starting to use this chain. DeprecatedCheckIntrospector - logs deprecated method calls. IntrospectorChainingUberspector - calls the introspector chain and wraps the resulting methods into velocity objects (VelMethod, VelPropertyGet, VelPropertySet). ExceptionCatchingUberspector - catches all exceptions and puts them in the context (and logs them, too). ChainingUberspector - just allows having the uberspectors chain. I'm not sure if all those should be introspectors, or would be better as uberspectors instead. I didn't include the SecureUberspector in the chain, as besides the filtering done by the SecureIntrospector, it only checks if the returned iterator is restricted or not, and I don't think the iterators should ever be restricted. I don't know if the rights check should be left only to the introspector or not. Currently, this check is done mostly in the API classes only, suggesting that anything that happens in the java world is safe to execute, regardless of the access rights. Groovy doesn't need access rights check, as it requires programming rights from the start. XmlRpc should be a little more secure, but right now it doesn't use rights checks from the core classes anyway. So, any method we would like to be callable from Velocity should have an @Scriptable annotation. Rights checking could be performed entirely from an introspector. Any thoughts on this? -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] CalendarEvent - Failed to create diff
by Glenn Everitt 12 May '08

12 May '08

I attempted to edit the CalendarEvent Class by changing the Start Date and End Date format from: dd/MM/yyyy to: MM/dd/yyyy when I clicked Save & View I got this exception - I get the same exception if I attempt to rollback to a previous version? Any idea what causes this problem or how to fix it. Error number 3201 in 3: Exception while saving document XWiki.CalendarEvent Wrapped Exception: Error number 3211 in 3: Exception while updating archive XWiki.CalendarEvent Wrapped Exception: Error number 13027 in 13: Failed to create diff for doc XWiki.CalendarEvent Wrapped Exception: null com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document XWiki.CalendarEvent Wrapped Exception: Error number 3211 in 3: Exception while updating archive XWiki.CalendarEvent Wrapped Exception: Error number 13027 in 13: Failed to create diff for doc XWiki.CalendarEvent Wrapped Exception: null at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:457) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:97) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:91) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1078) at com.xpn.xwiki.web.PropUpdateAction.propUpdate(PropUpdateAction.java:79) at com.xpn.xwiki.web.SaveAndContinueAction.action(SaveAndContinueAction.java:59) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:188) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Wrapped Exception: com.xpn.xwiki.XWikiException: Error number 3211 in 3: Exception while updating archive XWiki.CalendarEvent Wrapped Exception: Error number 13027 in 13: Failed to create diff for doc XWiki.CalendarEvent Wrapped Exception: null at com.xpn.xwiki.store.XWikiHibernateVersioningStore.updateXWikiDocArchive(XWikiHibernateVersioningStore.java:203) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:332) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:97) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:91) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1078) at com.xpn.xwiki.web.PropUpdateAction.propUpdate(PropUpdateAction.java:79) at com.xpn.xwiki.web.SaveAndContinueAction.action(SaveAndContinueAction.java:59) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:188) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Wrapped Exception: com.xpn.xwiki.XWikiException: Error number 13027 in 13: Failed to create diff for doc XWiki.CalendarEvent Wrapped Exception: null at com.xpn.xwiki.doc.rcs.XWikiPatch.setDiffVersion(XWikiPatch.java:176) at com.xpn.xwiki.doc.rcs.XWikiPatch.setDiffVersion(XWikiPatch.java:153) at com.xpn.xwiki.doc.XWikiDocumentArchive.makePatch(XWikiDocumentArchive.java:140) at com.xpn.xwiki.doc.XWikiDocumentArchive.updateArchive(XWikiDocumentArchive.java:255) at com.xpn.xwiki.store.XWikiHibernateVersioningStore.updateXWikiDocArchive(XWikiHibernateVersioningStore.java:198) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:332) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:97) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:91) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1078) at com.xpn.xwiki.web.PropUpdateAction.propUpdate(PropUpdateAction.java:79) at com.xpn.xwiki.web.SaveAndContinueAction.action(SaveAndContinueAction.java:59) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:188) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Wrapped Exception: java.lang.NullPointerException -- View this message in context: http://www.nabble.com/CalendarEvent----Failed-to-create-diff-tp17190022p171… Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 0

[xwiki-devs] Adnotatio
by Stéphane Laurière 12 May '08

12 May '08

Hi everyone, With Mikhail we created this generic GWT annotation tool that we may consider integrating into XWiki since it's bringing handy annotation features. The tool works fine only on static documents though for now. Annotation on evolving documents will require additional work. Project: http://code.google.com/p/adnotatio/ Demo: checkout the following folder and open "HtmlAnnotatorClient.html" in a browser: http://adnotatio.googlecode.com/svn/trunk/adnotatio/demo/adnotatio.HtmlAnno… Cheers Stéphane (sorry if the message reaches the list twice, I had an issue with Gmane) -- Stéphane Laurière slauriere(a)xwiki.com XWiki http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org http://scribo.ws

1 0

[xwiki-devs] Adnotatio
by slauriere 12 May '08

12 May '08

Hi everyone, With Mikhail we created this generic GWT annotation tool that we may consider integrating into XWiki since it's bringing handy annotation features. The tool works fine only on static documents though for now. Annotation on evolving documents will require additional work. Project: http://code.google.com/p/adnotatio/ Demo: checkout the following folder and open "HtmlAnnotatorClient.html" in a browser: http://adnotatio.googlecode.com/svn/trunk/adnotatio/demo/adnotatio.HtmlAnno… Cheers Stéphane

1 0

[xwiki-devs] Removing Comments and Attachments Option
by Prathap Pandian 12 May '08

12 May '08

Hi all, How to remove comments and attachments option from the page. Please help... -- Thanks, Prathap Pandian M

2 1