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

[xwiki-devs] [VOTE] Use SmartGWT for WYSIWYG widgets and SmartClient for JS needs
by Vincent Massol 12 Dec '08

12 Dec '08

Hi, I'd like to propose using smartGWT/smartClient for all our widget needs both in GWT and in JS: * Their set is pretty impressive and has all we need. * It's under LGPL * Sanjiv has moved from Ext GWT to SmartGWT and since he's had a bad history with Ext GWT we can assume he has received enough reassurance from smartClient to remain open source and under the LGPL license. * It's both GWT and JS and we need both * The little of the source I have seen look very clean. Some links: * http://www.jroller.com/sjivan/entry/smartgwt_1_0_released * http://code.google.com/p/smartgwt/ * http://www.ongwt.com/post/2008/11/27/SmartGWT-%3A-A- QampA-with-Sanjiv-Jivan2 * http://www.smartclient.com/product/smartLGPL.jsp Here's my +1 (barring any issue we see when we start using it of course) Thanks -Vincent

7 11

[xwiki-devs] [VOTE] Move XWiki GWT modules from web to platform
by Jean-Vincent Drean 11 Dec '08

11 Dec '08

Hi devs, I'd like to suggest to move our current xwiki-web-gwt and xwiki-web-wysiwyg modules from platform/web to platform/. Rationale : - Generic GWT modules to come (wiki-explorer, color picker, etc). - xwiki-web would hold only fully functional WARs. - WYSIWYG release cycle should be different from the one of web. This would allow to benefit from WYSIWYG improvements in branch releases (ex: XE 1.7.2, 1.7.3, etc) without requiring devs to commit on multiple branches. - A lot of issues regarding the wysiwyg editor are created in the XWiki Core project in jira, I think having a dedicated project makes sense. Current organization : |- platform/ |- web/ (xwiki-web) |- exo/ (xwiki-web-exo) |- gwt/ (xwiki-web-gwt) |- standard/ (xwiki-web-standard) |- wysiwyg/ (xwiki-web-wysiwyg) New organization proposal : |- platform/ |- gwt/ (xwiki-gwt) |- commons/ (xwiki-gwt-commons) |- wysiwyg/ (xwiki--gwt-wysiwyg) |- web/ (xwiki-web) |- exo/ (xwiki-web-exo) |- standard/ (xwiki-web-standard) This would also mean that we'd need 2 new projects in JIRA : XWiki GWT Commons (XGCOMMONS) and XWiki GWT WYSIWYG (XGWYSIWYG). Here's my +1. Thanks, JV.

5 4

[xwiki-devs] Problem debugging 1.7
by Juergen Lorenz Simon 10 Dec '08

10 Dec '08

Hi, I'm experiencing a problem trying to debug XWiki from Eclipse when using version 1.7. I replaced the xwiki.cfg file with the version from the xwiki-enterprise-web.war file. I get the following exception: java.lang.RuntimeException: Failed to load component [org.xwiki.cache.CacheManager] for hint [default] at com.xpn.xwiki.web.Utils.getComponent(Utils.java:547) at com.xpn.xwiki.XWiki.getCacheFactory(XWiki.java:5270) at com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java: 90) at com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java: 84) at com.xpn.xwiki.store.XWikiCacheStore.<init>(XWikiCacheStore.java:64) I noticed that there is no pom.xml file for version 1.7 yet in the tutorial page on xwiki and Eclipse. Do I have to make some changes to the pom.xml in xe-debug-web other than changing xwiki version to 1.7? Cheers, J.L.Simon

2 3

[xwiki-devs] Problems deploying custom Authentication
by Juergen Lorenz Simon 10 Dec '08

10 Dec '08

Hi, i've been writing a custom authentication plugin for xwiki. The implementation was pretty straightforward, however I'm having trouble deploying the plugin. I bundled it with other plugins for the same purpose in a jar file. The jar file is deployed to my local repository. It's pulled in when I build the xe-debug-web in Eclipse and it's present in the xe-debug-web/WEB-INF/ lib directory of the deployed app (in .metadata/.plugins/org.eclipse.wst.server.core/ tmp0 ...). I altered the xwiki.cfg, adding the following line: xwiki .authentication .authclass=com.kontrast.vodafone.portal.xwiki.PortalAuthenticationPlugin However, when starting the application, I get the following problem: - Initializing AuthService... - Failed to initialize AuthService com.kontrast.vodafone.portal.xwiki.PortalAuthenticationPlugin using Reflection, trying default implementations using 'new'. java.lang.ClassNotFoundException: com.kontrast.vodafone.portal.xwiki.PortalAuthenticationPlugin at org .apache .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 1387) at org .apache .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 1233) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at com.xpn.xwiki.XWiki.getAuthService(XWiki.java:4630) at com.xpn.xwiki.XWiki.checkAuth(XWiki.java:3566) at com .xpn .xwiki .user .impl .xwiki.XWikiRightServiceImpl.checkAccess(XWikiRightServiceImpl.java:170) at com.xpn.xwiki.XWiki.checkAccess(XWiki.java:3574) at com.xpn.xwiki.XWiki.prepareDocuments(XWiki.java:4480) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:190) 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.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org .apache .catalina .core .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 290) at org .apache .catalina .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com .xpn .xwiki .wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java: 94) at org .apache .catalina .core .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 235) at org .apache .catalina .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com .xpn .xwiki .web .SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java: 287) at org .apache .catalina .core .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 235) at org .apache .catalina .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com .xpn .xwiki .web .SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java: 112) at org .apache .catalina .core .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 235) at org .apache .catalina .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org .apache .catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: 233) at org .apache .catalina.core.StandardContextValve.invoke(StandardContextValve.java: 191) at org .apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 128) at org .apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 102) at org .apache .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java: 845) at org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java: 447) at java.lang.Thread.run(Thread.java:637) Any idea what I've missed? Thanks in advance, J.L.Simon

3 8

[xwiki-devs] [ANN] XWiki Enterprise 1.7 Released
by Jean-Vincent Drean 10 Dec '08

10 Dec '08

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.7. This is the final 1.7 version. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Changes from 1.6: ------------------------- - New XWiki Syntax 2.0 (xwiki/2.0) - New WYSIWYG 2.0 (Alpha version) - New script macro (xwiki/2.0) - New Box macro (xwiki/2.0) - Multiwiki (a.k.a farm mode or virtual mode) is now available using special URLs for wikis (and not only subdomains). Note that this option is available from xwiki.cfg and not enabled by default. - Webdav support : XWiki now expose a webdav server interface. This means you can now access/edit/delete page sources and attachments from any webdav client. - Groovy upgrade : The groovy engine has been upgraded to the last 1.6 beta version. You can now use all the new features of groovy as well as speed improvements and bugfixes from groovy 1.0 to 1.6 beta 2. - New Attachment view in the Index : you can now see all the attachments of the wiki in the wiki index, under the "Attachment" tab. - Reorganized, documented and enhanced xwiki.cfg configuration file. - Added a ROOT webapp to the standalone distribution. Important bug fixes: -------------------------- - Saving a blank wiki page throws exception in Oracle - Registration is still possible when right to register for Unregistered user is explicit set to deny - Documents with name with spaces or other special chars can't properly save added image in WYSIWYG editor - Support of dots in ldap login has introduce a security hole - SMTP server address is not re-read when it's changed in global preferences - Watchlist update sent by email does not contain the full path to a changed attachment - Wrong user name is inserted in group during LDAP membership synchronisation For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise17 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Postpone XE 1.7 final release
by Vincent Massol 10 Dec '08

10 Dec '08

Hi there, Since there are still some wysiwyg bugs that can't be finished for today we're proposing to move the XE 1.7 release to Monday or even Tuesday (deadline is that it needs to be released for Tuesday night so that we have it for Devoxx 2008 as planned). I've done a status call with Anca/Marius and the outcome is that for 1.7 our wysiwyg will not work well enough to be called "usable" so I'm proposing to call it alpha and to only call it "usable" for 1.7.1 which is planned for the 17th. Let me know what you think. Thanks -Vincent

2 1

[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