xwiki-devs February 2007

xwiki-devs@xwiki.org

29 participants
70 discussions

by Vincent Massol

Hi, I've created a XWIKI_1_0_BETA_4 branch for the b4 release. Work can now start for beta 5 on the 1.0 branch. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 1 month

XWA-22 possible SQL injection with search

by Pablo Oliveira

As Paul, I've stumbled upon this when using a tick (') in the search box at xwiki.org. It appears to be resolved on the dev version, but you really should backport the fix to xwiki.org as it is a serious security threat. Pablo

18 years, 1 month

Compiler compilance level

by Christian Gmeiner

Hi all, as i begun start hacking xwiki, i have a very important question. What Compiler compilance level does xwiki use? * 1.3 * 1.4 * 5.0 * 6.0 Thanks, Christian

18 years, 1 month

Recognizing XWiki contributors

by Vincent Massol

Hi everyone, I'd really like that everyone who's ever contributed to XWiki (whether at the code level, whether at the documentation, whether at answering the mailing list level, etc) is recognized for the work they've done. Right now we're doing this very badly and we need to change. For committers, I think the solution is relatively easy as there are SCM logs and once we have Fisheye set up we'll be able to easily make that visible. Also there are site like http://www.ohloh.net/projects/ 68 (even though the stats are wrong but that's another story ;-)) that make this information visible. This is not the case for contributors. For another project I'm working on (Cargo) we have a Credits page: http://cargo.codehaus.org/Credits. However even that is not perfect as sometimes I forget to add someone and it's hard to ensure it's done consistently. For XWiki, I had started this page http://www.xwiki.org/xwiki/bin/ view/Community/HallOfFame However, the contributors section is currently empty even though we have had lots of contributors and even today we have people like Brandon, Melv, Catalin, Pablo, Gilles, Marc and lots of others. That's bad, very bad as we need to make it as rewarding as possible for people to contribute to XWiki. Naturally some contributors can become committers but that's not always happening of course as contributors may not have the bandwidth to commit more. So I'm asking here to everyone: What should we do? What would contributors find nice to have? I thought if everyone helped filled http://www.xwiki.org/xwiki/bin/ view/Community/HallOfFame it could work but that remains to be proved... BTW, just after typing this email I'll start adding contributors on that page and please everyone help me. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 1 month

[Proposal] New Architecture for XWiki 2.0

by Vincent Massol

Hi XWiki developers, I'd like to start a discussion on the XWiki 2.0 Architecture. I've put my thoughts on http://www.xwiki.org/xwiki/bin/view/Idea/ ArchitectureV2 (sorry I haven't explained a lot yet so I guess you'll have to be familiar with component-oriented development to understand fully what it means - Do not hesitate to ask questions if there's something not clear :-)). I'm listing down here the content of that page so that we can discuss it here more easily. I'd also like to start working and experimenting with it. Actually my goal is to do a POC to see what level of changes would need to be brought to the core and more importantly whether or not we can keep the backward compatibility and thus start refactoring in the 1.x code base rather than start a complete new 2.x branch. In any case I'd like to create a XWIKI_2_0 branch tomorrow for starting the experimentation. In addition Jason Van Zyl (whom I'm cc- ing and who's the creator of Maven, Velocity, Turbine, Plexus and other OSS projects ;-)) is keen to work with us on this and would also like experimenting ASAP. I'm thus proposing to give him write access to that XWIKI_2_0 branch. Let me know what you think Thanks -Vincent ----------- 1.1 Ideas * Component-oriented architecture using a Component Manager * Each component group (set of component for implementing a concept) is separated in its own build module and generates a JAR * Make the component 100% independent of the Component Manager used * Register the Component Manager using a Servlet Context Listener * Question: Should we use existing components from the Component Manager implementation? If so the question is whether it'll work with other Component Managers? 1.1 Implementation Details * Use Plexus as the Component Manager (each component JAR has a META- INF/components.xml file that configures Plexus) * Future: Make the components OSGi-compliant (each component JAR has a META-INF/Manifest with OSGi configuration in there) * Start creating a branch in XWiki (xwiki/xwiki/branches/XWIKI_2_0) for working on this. * Idea: It would be nice to merge back the work progressively (if possible) on the trunk. It might be possible as we have a public API which we could keep and only change the underlying implementation for now, thus preserving backward compatibility (except possibly for plugin writers but that's less of an issue IMO). 1.1.1 List of Components Required * Rendering and Renderers * URL Management (Portlet, Servlet, XMLRPC, etc) * Storage + Query/Search (JCR, DB/Hibernate, Subversion, etc) * Authorization (JAAS, DB, etc) * Authentication (JAAS, DB, LDAP, etc) * User/Groups Services * Document Services * Configuration Services (dynamic configs in DB for example) * Remote Calls Services (XMLRPC, SOAP, Email, etc) * Attachment Services * Statistics Services * Cache Services * Logging * Wiki Services (like getWikis() for a farm, etc) * Container Services (adaptation layer for Servlet, Portlet, etc) * I18N Services * Notifier Services (SMTP, IRC, SMS, etc) Lots of these services should offer extension points so that it's possible to write extensions against them. The idea is to remove the need for a Plugin interface that would list all the possible extension points. Instead it should be each component offering those extension points. Alternatively the extension would completely replace or wrap an existing component. 1.1 Todos * Create Architecture diagram listing all components required * Define the interface for each component * Idea: Start with the Rendering component and the Renderers (Velocity, Radeox, Doxia, etc). Note: We need ordering as a page is going to be rendered in sequence by all the renderers (unless a renderer says not to continue the chaining) ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 1 month

Important remaining work for 1.0 final: PDF + Page rename

by Vincent Massol

Hi, We have 2 important tasks to finish for the 1.0 final: * Fixing all the PDF issues (there are at least 5 unassigned in Beta 5) * Implementing the Page rename Is there someone interested in working on this? Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 1 month

Beta 4 release date

by Vincent Massol

Hi, We had planned to release beta 4 on Monday (today). We still have some important issues to finish (the ones currently in JIRA). Thus I'm proposing to do the release Tuesday afternoon. All developers have till Monday EOD to commit stuff and till tuesday noon to do functional tests. Then I'll cut the release. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 1 month

Duplicate content-type in html code

by Gilles Serasset

Hi all, The source of served pages contains a duplicate content type (just use view source on any page of xwiki...) <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title> XWiki.org - Community - WebHome </title> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <meta name="revisit-after" content="7 days" /> <meta name="description" content="Free Wiki on XWiki.com" /> <meta name="keywords" content="wiki" /> <meta name="distribution" content="GLOBAL" /> <meta name="rating" content="General" /> <meta name="author" content="" /> <meta http-equiv="reply-to" content="" /> <meta name="language" content="en" /> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> ... The first one is generated by XWiki, the second comes from the HTTP Meta Inofrmation of the presentation preferences, as given by the xwiki-1.0-beta-3.xar This may usually not be a problem, but in a UTF-8 environment, it gives 2 different contents (the first one being (correctly) UTF-8, the second being ISO-8859-1. This meta information should be removed from the xwiki xar at it is now obsolete. If, for reason I do not know it is to be kept, then the document presenting settings of an UTF-8 xwiki should be updated. Regards, Gilles, -- Gilles Sérasset GETA-CLIPS-IMAG (UJF, INPG & CNRS) BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75

18 years, 1 month

Import do not properly handle file encodings

by Gilles Serasset

Hi all, I'm currently evaluating xwiki for a local install and found severall issues. Here is the first one. When importing a xar file, all contained documents are parsed using the default encoding of the server JVM, regardless of the effective encoding of the files. This leads to incorrect documents when running the server in an UTF-8 configuration and importing the released xar (as they are encoded using ISO-8859-1, and as they effectively contain iso-8859-1 characters, which are, BTW typos coming from French). I already corrected this pb on the current svn snapshot. I'll post the patch in a comment of the JIVA issue I created. Regards, Gilles, -- Gilles Sérasset GETA-CLIPS-IMAG (UJF, INPG & CNRS) BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75

18 years, 1 month

Why do we use Content-Disposition with inline mode in DownloadAction?

by Vincent Massol

Hi there, I'm trying to fix some issue and I'd like to understand why we have the following in DownloadAction: String ofilename = XWiki.getURLEncoded(attachment.getFilename ()).replaceAll("\\+", " "); response.addHeader("Content-disposition", "inline; filename= \"" + ofilename + "\""); response.setDateHeader("Last-Modified", attachment.getDate ().getTime()); To my knowledge, "inline" means that we're giving an indication to the browser so that it does NOT to bring up a "Save As..." dialog box. However my understanding is that when the user uses the /download/ action the attachment is bringing up a Save dialog box. So 2 questions: 1) Why do we use inline? 2) Why is it working? :) Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

18 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2007