December 2008 - xwiki-devs@xwiki.org

[xwiki-devs] [WebDAV] Issues on MacOSX (Temporary Files Not Supported)
by Asiri Rathnayake 10 Dec '08

10 Dec '08

Hi Devs, I've looked into the issues with webdav on MacOSX and following is the diagnosis: Finder(Mac) and other text editors on Mac relies a lot on temporary files / directories created just for the duration of their operation. These files usually start with a "." and can be easily distinguished from others. But ignoring these files does not help at all because they are needed for the proper operation of those applications. There for, we need to support them somehow. Approach 1: Store all of those temporary files inside user's session object - This doesn't work always because some clients (Nautilus, Redirector, Davfs) creates a new session for each and every request they make, so the information will not be persistent across different requests. Although some clients (Konqurer, NetDrive, DAVExplorer) keeps a single session open throughout their operation and they can support temporary files with this approach. Approach 2: Store the temporary objects (resources) inside a database table or file system - This can be complex to implement and will slow down the operations. Approach 3: Use an in-memory storage in a per-user basis and store temporary files there (Ex HashMap<User,Object>). This is quite easy to implement but we need to manage the temporary storage carefully. I have implemented and tested Approach 1 and I will convert this to Approach 3 asap. In the mean time, if you think there is a better way to do this, please let me know. Thanks. - Asiri PS: Some clients are aware of webdav protocol and they workaround temporary files themselves, these clients work fine oob. Note: Temporary files that need to be supported: .* (Unix like OSs) Desktop.ini (XP) Thumbs.db (XP) *~ (gEdit) *.swp (Vim)

3 2

[xwiki-devs] New Blog Application - How do we integrate it?
by Vincent Massol 09 Dec '08

09 Dec '08

Hi, Here's a proposal: * We don't bundle it in XE 1.7 since its integration is not finished (missing integration with old Articles + Dashboard + Panel). * We release it as an independent application on code.xwiki.org and we update http://code.xwiki.org/xwiki/bin/view/Applications/BlogApplication * We send Announcement email on users/devs lists asking for feedback * We work on its integration so that it can replace the old blog application * If ready we bundle it in 1.7.1 as the main blog application. If not then we bundle it in 1.7.2 or 1.7.3, i.e. as soon as it's ready. I really think it's an important app for XE and thus we shouldn't wait for 1.8 to release it. WDYT? For those who haven't tried it: http://incubator.myxwiki.org/xwiki/bin/view/Blog/ Thanks -Vincent

1 0

[xwiki-devs] XWIKI-2938 and XWIKI-2899
by Fabio Mancinelli 08 Dec '08

08 Dec '08

Hi all, I would like to draw attention to those two bugs: http://jira.xwiki.org/jira/browse/XWIKI-2899 http://jira.xwiki.org/jira/browse/XWIKI-2938 They are very relevant and they could be easily fixed (patches are already there). I've been using the patch proposed for XWIKI-2899 in my local XWiki for a while and I haven't noticed any side effects. For the patch concerning XWIKI-2938, I talked again to Ludovic and it seems that it's ok. So I would like to ask to other committers if they could have a quick look at these bug fixes so that they can be applied. Thanks, Fabio

2 2

[xwiki-devs] [PROPOSAL] Add bridge to a access user rights on a document
by Thomas Mortagne 08 Dec '08

08 Dec '08

HI devs, For http://jira.xwiki.org/jira/browse/XWIKI-2880 I need to know if the current user has view right on a specified document. For this there is many solutions, lets proposes some: 1) just add a isDocumentViewable(String documentName) in DocumentAccessBridge and see later if we need more 2) add a more generic hasAccessRights(String documentName, String rightLevel) in DocumentAccessBridge 3) or even more generic hasAccessRights(String user, String documentName, String rightLevel) in DocumentAccessBridge 4) all of this ... Since it's a bridge, I prefer 1) for now, that way component does not need to know exactly what means that a document is readable/viewable and that it needs to use the right level identifier "view". At some point we will need to define a real rights component api and I think we should wait for it before refactoring in component anything that need a lots more that isDocumentViewable. WDYT ? Thanks, -- Thomas Mortagne

5 5

Re: [xwiki-devs] xwiki database -> ldap
by Thomas Mortagne 08 Dec '08

08 Dec '08

On Mon, Dec 8, 2008 at 12:20 PM, Bartłomiej Radziszewski <br(a)debian.linux.pl> wrote: > Hi Thomas, > > Thx for replay. > > Yep I know about synchronization ldap to xwiki database. > I want to use xwiki like central managment system for other services like > for example SVN (For authentication to the SVN i'm using htaccess with > ldap). You mean synchronize the other way ? When something change in XWiki, it has to modify LDAP entry ? XWiki does not support this by default. But you can do that with a script or a plugin if know JAVA and a little LDAP apis. In your plugin you can register for receive notifications of user modifications and then connect to LDAP and modify the LDAP user entry. See http://platform.xwiki.org/xwiki/bin/view/DevGuide/Notifications In the meantime you can add an "idea" or "improvement" entry on http://jira.xwiki.org/jira/browse/XWIKI about "Synchronizing any XWiki user modification back to LDAP server" or something like that but I think you will have to wait quite a long time to see it unless someone provide a good patch/contrib for it ;) > > So.. after user registration i need to have the same user in ldap. > > It is posible in xwiki? > > Thx and Greetings! > Bart >> >> Hi Bart, >> >> 2008/12/6 Bartłomiej Radziszewski <br(a)debian.linux.pl>: >> >>> >>> hello Thomas, >>> >>> If i good know You are developing all ldap staff in xwiki. >>> I'm searching simple way how to synchronize xwiki users to ldap >>> posixAccount.. i need only login, pass and mail attributes.. do You have >>> idea how to make it? >>> >> >> You don't need to synchronize LDAP login or pass, the LDAP >> authenticator validate login/pass directly on LDAP server then the >> informations like name, mail etc... are synchronized with XWiki. >> >> To define which information to synchronize between LDAP and XWiki user >> profile you can use xwiki.authentication.ldap.fields_mapping. >> >> For example : xwiki.authentication.ldap.fields_mapping=email=mail if >> you want only email. >> >> See >> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HGeneric… >> for more details on LDAP authentication configuration. >> >> >>> >>> Thanks and Greetings, >>> Bart >>> >>> -- >>> Bartłomiej Radziszewski >>> mobile: +48 509 561 540 >>> e-mail: br(a)debian.linux.pl >>> JID: br(a)debian.linux.pl >>> ICQ: #305569725 >>> >>> >>> >>> >> >> >> >> > > > -- > Bartłomiej Radziszewski > mobile: +48 509 561 540 > e-mail: br(a)debian.linux.pl > JID: br(a)debian.linux.pl > ICQ: #305569725 > > > -- Thomas Mortagne

1 0

Re: [xwiki-devs] xwiki database -> ldap
by Thomas Mortagne 08 Dec '08

08 Dec '08

Hi Bart, 2008/12/6 Bartłomiej Radziszewski <br(a)debian.linux.pl>: > hello Thomas, > > If i good know You are developing all ldap staff in xwiki. > I'm searching simple way how to synchronize xwiki users to ldap > posixAccount.. i need only login, pass and mail attributes.. do You have > idea how to make it? You don't need to synchronize LDAP login or pass, the LDAP authenticator validate login/pass directly on LDAP server then the informations like name, mail etc... are synchronized with XWiki. To define which information to synchronize between LDAP and XWiki user profile you can use xwiki.authentication.ldap.fields_mapping. For example : xwiki.authentication.ldap.fields_mapping=email=mail if you want only email. See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HGeneric… for more details on LDAP authentication configuration. > > > Thanks and Greetings, > Bart > > -- > Bartłomiej Radziszewski > mobile: +48 509 561 540 > e-mail: br(a)debian.linux.pl > JID: br(a)debian.linux.pl > ICQ: #305569725 > > > -- Thomas Mortagne

1 0

[xwiki-devs] [VOTE] XMLRPC API Extension
by Fabio Mancinelli 07 Dec '08

07 Dec '08

Dear all, since the 1.7 release has been delayed I would like to propose to add 3 methods to the XMLRPC API. These methods are the following: /* Returns a list of all the changed pages starting from a given date */ public List<XWikiPageHistorySummary> getModifiedPagesHistory( Date date, Integer numberOfResults, Integer start, Boolean fromLatest) /* These are basically equivalent to original store functions, but if checkVersion is true then a check of the current page version is done before storing the page/object. This check handles the case in which a page has been modified by somebody else after the last getPage or getObject */ public XWikiPage storePage(XWikiPage page, Boolean checkVersion) public XWikiObject storeObject(XWikiObject object, Boolean checkVersion) Besides their usefulness there is also a rationale: these are actually a need for the Concerto project and it would be great to have them already available in 1.7. >From the implementation point of view, these methods have almost no impact on the current code base and they are purely an extension (i.e., no pre-existing critical code has been touched) Here it is my +1 -Fabio

7 11

[xwiki-devs] users registration problem
by antoine Seilles 06 Dec '08

06 Dec '08

Hi My xwiki works fine. But when users try to register, they have the following error. The registry is allright but it seems that mail can't be send. A problem occured while trying to service your request. Please contact the support if this happens again. Detailed information: Error number 10003 in 10: Exception while sending email from antoineseilles(a)gmail.com to [Ljava.lang.String;@b5d71 Wrapped Exception: Connection refused com.xpn.xwiki.XWikiException: Error number 10003 in 10: Exception while sending email from antoineseilles(a)gmail.com to [Ljava.lang.String;@b5d71 Wrapped Exception: Connection refused at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3347) at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3370) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3284) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3249) at com.xpn.xwiki.XWiki.createUser(XWiki.java:3203) at com.xpn.xwiki.web.RegisterAction.action(RegisterAction.java:41) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) 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:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) 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:172) 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:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) Wrapped Exception: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at java.net.Socket.connect(Socket.java:469) at java.net.Socket.(Socket.java:366) at java.net.Socket.(Socket.java:180) at org.apache.commons.net.DefaultSocketFactory.createSocket(DefaultSocketFactory.java:53) at org.apache.commons.net.SocketClient.connect(SocketClient.java:162) at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3320) at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3370) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3284) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3249) at com.xpn.xwiki.XWiki.createUser(XWiki.java:3203) at com.xpn.xwiki.web.RegisterAction.action(RegisterAction.java:41) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) 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:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) 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:172) 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:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619)

3 5

[xwiki-devs] [VOTE] Make DocumentAccessBridge#getDocumentContent(String documentName) use the current language in place of the default one
by Thomas Mortagne 06 Dec '08

06 Dec '08

Hi devs, I was looking for issue http://jira.xwiki.org/jira/browse/XWIKI-2892 (Include Macro should support including pages matching the current language) and i'm thinking it's not the include macro work to take care of the language. Include macro use the DocumentAccessBridge to acces document content and I think unless you don't explicitly specify that you want the default language content DocumentAccessBridge#getDocumentContent(String documentName) should return the content for the current language. It's more consistent with DocumentAccessBridge#etDocumentContent(String documentName, String language) IMO and anyway except for very specific needs I don't see the point of manipulating the content of the document's default language for components. WDYT ? Here is my +1 Thanks, -- Thomas Mortagne

4 4

[xwiki-devs] [Proposal] New Line behavior in the new WYSIWYG editor
by Guillaume Lerouge 06 Dec '08

06 Dec '08

Hi, In the current implementation of the WYSIWYG editor, when adding content, pressing the return key creates a new paragraph () and pressing shift-return creates a new line ( ). In the wiki editor, the following behavior was discussed and implemented ( http://www.mail-archive.com/[email protected]/msg04436.html ) : *>> So typing a new line in the wiki editor will result in a br tag in the >> corresponding HTML? And two consecutive new lines in wiki editor will >> result in a new paragraph? >> >> yep exactly.* After talking with our project managers and gathering their feedback from the way customers use our tool, I think that implementing a similar behavior in the WYSIWYG editor would be more intuitive for users : - Pressing return once generates a new line - - Pressing return twice generates a new paragraph - In order for this behavior to be transparent for the user, the CSS setting the height of blank space between 2 paragraphs should set it a one line's height. In order to respect user intentions on the screen, we would also need to handle the case where the user inputs, say, 4 return keypresses in a row. We could handle it by inputting tags and having the last tag be a paragraph : Some text some other text Another option would be to go the way of recent editors such as Google Docs and ditch in favor of tags only. So there are 3 options: 1. Keep the current implementation (*pros:* it's working this way already, *cons:* it's not what our project managers say our users expect) 2. Use 1 return keypress for and 2 return keypresses for (*pros: * it's more intuitive for users, it keeps the semantic meaning of , * cons:* it takes time to implement and we're already lacking time) 3. Input only everywhere, all the time (*pros:* that's what modern editors do, *cons:* additional work, we lose the semantic meaning of ) I'm +1 for option 2. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

5 4