xwiki-devs May 2008

xwiki-devs@xwiki.org

53 participants
158 discussions

[xwiki-devs] XE 1.4RC1 release and outstanding issues

by Vincent Massol

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

16 years, 7 months

Re: [xwiki-devs] Proposal for the new Administration

by Sergiu Dumitriu

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/

16 years, 7 months

[xwiki-devs] Deprecating all the APIs in favor of a Velocity uberspecting chain

by Sergiu Dumitriu

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/

16 years, 7 months

[xwiki-devs] CalendarEvent - Failed to create diff

by Glenn Everitt

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.

16 years, 7 months

[xwiki-devs] Adnotatio

by Stéphane Laurière

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

16 years, 7 months

[xwiki-devs] Adnotatio

by slauriere

16 years, 7 months

[xwiki-devs] Removing Comments and Attachments Option

by Prathap Pandian

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

16 years, 7 months

[xwiki-devs] Boston and/or New York Meetup this week

by Ludovic Dubost

Hello XWiki users and developers, I'm in Boston today and tomorrow and could be available for a quick meetup with users of XWiki if there are some in the area. I will also be in New York wednesday to saturday. Anybody interested in an informal Meetup ? I would love to hear what we could improve in XWiki and show the latest things we are working on. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 7 months

[xwiki-devs] Hashmap vs. Objects (theoretical question about a data model)

by Kamna Jain

Hi All, This question "might" be related to the thread that has been active in the past couple of days about the data model. We have a similar situation with the only difference being that we want to create lists or collections (like Groups) of certain pre- created Objects. The Object as a whole may/will belong to more than one such collection - which means that if we were to use a Document to link a Collection and its contents, then every document will have a COPY of the same object and this is definitely not desirable for good performance - Right? So, in that case, we have 2 alternatives: 1) Use the techiniques used in XWiki to create Groups: each group has objects of class XWikiGroup with just one field that refers to the Member name. OR 2) Use XWiki.getHashmap() and add the Collection and its members to the hashmap (as the Key and Value resp.) The XWiki API indicates that the option #2 must be used in xwiki when Objects can not be created. My Question is: -> Even though I could use option #1 and create objects and add them to the document that would represent the Collection, can I still use option #2 because I think that it will provide better performance. Am I right in my assumption? What should I do? Thanks a lot for all help!

16 years, 7 months

[xwiki-devs] reading a single property

by [Ricardo Rodriguez] Your EPEC Network ICT Team

Hi, Sorry if this question is too basic, but I am not able to find the answer. I am able to read all the properties of an instance of Species.SpeciesClass class in a document with this code: #set($obj = $doc.getObject("Species.SpeciesClass").xWikiClass) #foreach($prop in $obj.properties) *${prop.prettyName}:* $doc.display($prop.getName())<br/> #end But, please, how could I read a single, let's say, Genrus property of this object? Thanks! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

16 years, 7 months

← Newer
1
...
9
10
11
12
13
14
15
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2008