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

Re: [xwiki-devs] [xwiki-notifications] r28419 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web
by Vincent Massol 20 Apr '10

20 Apr '10

On Apr 17, 2010, at 3:47 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-04-17 03:47:52 +0200 (Sat, 17 Apr 2010) > New Revision: 28419 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java > Log: > XWIKI-5121: Weird behavior when deleting the head of the history of a renamed document > Fixed. > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:23:30 UTC (rev 28418) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:47:52 UTC (rev 28419) > @@ -73,6 +73,10 @@ > // If we delete the most recent (current) version, then rollback to latest undeleted version. > if (!tdoc.getRCSVersion().equals(archive.getLatestVersion())) { > XWikiDocument newdoc = archive.loadDocument(archive.getLatestVersion(), context); > + // Reset the document reference, since the one taken from the archive might be wrong (old name from > + // before a rename) > + newdoc.setDocumentReference(tdoc.getDocumentReference()); > + newdoc.setMetaDataDirty(false); > context.getWiki().getStore().saveXWikiDoc(newdoc, context); > context.setDoc(newdoc); > } hmmm... when a doc is renamed, if we restore a version before the rename, shouldn't we get back the old, not renamed, document? Thanks -Vincent

3 6

[xwiki-devs] [Proposal] Add file access module to allow secure access to the filesystem.
by Caleb James DeLisle 19 Apr '10

19 Apr '10

Currently we have 109 instantiations of the File class spread over 40 java classes. Each one of these has as much access to the filesystem as the user. My proposal is to create a new module in the core which manages access to the filesystem. I would like the module to provide roles for read-only and read/write files or directories. ReadOnlyFile and ReadWriteFile would extend java.io.File and override getParentFile() which allows the owner of a single file to walk the directory tree. Imagine the following situation: A class called Alice needs to be able to read all files in ./skins/ and she needs to be able to write to ./work/alice.txt If we use the component system she might say: @Requirement("./skins/") ReadOnlyFile skinsDirectory; @Requirement("./work/alice.txt") ReadWriteFile workFile; Now suppose an attacker is able to completely compromise Alice and make her execute whatever bytecode he wants. Lets also suppose we have implemented a SecurityManager which prevents Alice from loading the File class or accessing Utils.getComponent. The attacker will be able to read the files in ./skins/ and will be able to read and write to /work/alice.txt but he won't be able to read other files or create new files because Alice has no references to the component manager and thus cannot access additional files. We can leverage the component system to easily provide security using principle of least permission. WDYT? Caleb

1 0

[xwiki-devs] Fwd: [webdriver] New release made
by Vincent Massol 19 Apr '10

19 Apr '10

fyi -Vincent Begin forwarded message: > From: Simon Stewart <simon.m.stewart(a)gmail.com> > Date: April 19, 2010 11:32:45 AM GMT+02:00 > To: webdriver <webdriver(a)googlegroups.com>, selenium-developers <selenium-developers(a)googlegroups.com> > Subject: [webdriver] New release made > Reply-To: webdriver(a)googlegroups.com > > Hi, > > I've just uploaded the JARs for a new alpha of Selenium 2: selenium > 2a3. This contains bug fixes and enhancements including: > > * Better Firefox 3.6 support. > * HtmlUnit 2.7 added. > * The ability to return arrays from the JavascriptExecutor. > * New remote protocol implemented by all remote drivers, including Firefox. > * Better native event support for Firefox on Linux. > * Oodles of bug fixes. > > Note: because of the changes in the wire protocol, you must update the > remote server and the client jars at the same too. Also, the Firefox > driver is now using that same protocol. If you're having trouble > starting it up, then make sure that everything is up to date! > > Jari, Jim, Jason and Michael: could you please update the language > bindings and maven contents that you're so capably owning? > > Patrick, I write some release notes and put them up on the blog. > > Regards, > > Simon

1 0

[xwiki-devs] Implementing the XWiki.org Redesign
by Silvia Rusu 19 Apr '10

19 Apr '10

Hi XWiki devs & users, So far we've been talking a lot about redesigning XWiki.org and all feedback was greatly appreciated. Now it's time we started implementing the redesign Caty was so kind to come up with based on our suggestions. Like the proposal stage this too will be a collaborative effort and we hope you'll join in building an even better site for XWiki.org. The following is a list of things that need to be implemented in order to get us started. It would be great if you'd volunteer for the implementation of the tasks at hand. Please add your name next to the issue you'd like to assign yourself too. Also feel free to add as many other issues you think should appear on the list and to volunteer for those issues as well. Here is the first list of tasks: * Set up the server for the new website (Alex? :) ) * Add the horizontal navigation to the new website * Implement the projects carousel for the homepage * Implement the panels for "Latest Releases", "Latest Extensions". "Latest News"(should display the latest 5 releases, extensions, news) Documentation/Projects * Implement the left navigation for documentation/projects * Implement the panel for the "Latest Documentation Updates" (should display the last 5 documents and their authors) Community page widgets and panels: * Implement the"Development Status" panel, if it's going to have dynamic content * Implement the "Top Committers" panel (show the committer's picture and number of commits) * Implement the "Latest Commits" section (should display an image of the committer, what (s)he commited, the name of the committer and the date the commit was made) * Implement the "Latest Issues" section (should have the latest Jira issues, the person who took an action with regard to the issue - e.g. create, close - and the time the action was taken) * Implement the "Latest Discussion" section (display the list, the topic discussed, the name of the person that added the latest reply and the time he added the answer) * Implement the "Latest Documentation" section (show the number of lines added/deleted, the name of the document, the author of the modification and the time (s)he made the changes) * Implement "Latest Extensions" section (display the extension name, the name of the person that added the extension, the time it was added and a short description) You may read what has already been discussed about the redesign on this page http://markmail.org/message/tfmrludhw2yh5tcn#query:+page:1+mid:h5bukrijteeu… See the latest redesign proposal here http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2 Thanks, Silvia

5 5

[xwiki-devs] Contribution to the DatePicker application
by Raluca Stavro 19 Apr '10

19 Apr '10

Hello devs, I would like to contribute to the DatePicker application. Currently, the DatePicker stylesheet does not take in account the color theme. This is why I created a Jira issue (XCONTRIB-109) and I attached a patch to it. You will see some screenshots with the new styles applied on the DatePicker table. Can someone please give me the right to commit those styles? Raluca.

3 3

[xwiki-devs] Should email invitation code be an application? How should it be put in sandbox?
by Caleb James DeLisle 19 Apr '10

19 Apr '10

I have a reasonably clean revision of the code for inviting friends to join the wiki. Should it be a separate application with it's own jira project? It's not very large but may grow. I can't imagine what other application it should be filed under. I'd like to put it in the sandbox so it can be subject to review and discussion but I don't know how that should be done. I guess that depends on whether it is going to be it's own application. Any thoughts? Caleb

1 0

Re: [xwiki-devs] [xwiki-notifications] r26074 - in platform/core/trunk/xwiki-core/src: main/java/com/xpn/xwiki/doc test/java/com/xpn/xwiki/doc
by Caleb James DeLisle 17 Apr '10

17 Apr '10

(resending, meant to send to the dev list.) Sorry to drag up old commits but I have a couple of questions. vmassol (SVN) wrote: > Author: vmassol > Date: 2010-01-07 23:02:51 +0100 (Thu, 07 Jan 2010) > New Revision: 26074 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java > Log: > XWIKI-4677: Introduce new Model module > > * Fixed infinite cycle (revert some previous change). We need to find a solution. > * Refactored existing code to prevent manual parsing > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2010-01-07 16:55:03 UTC (rev 26073) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2010-01-07 22:02:51 UTC (rev 26074) > @@ -80,6 +80,7 @@ > import org.xwiki.context.ExecutionContextManager; > import org.xwiki.model.reference.DocumentReferenceResolver; > import org.xwiki.model.reference.EntityReferenceSerializer; > +import org.xwiki.model.reference.WikiReference; > import org.xwiki.rendering.block.Block; > import org.xwiki.rendering.block.HeaderBlock; > import org.xwiki.rendering.block.LinkBlock; > @@ -359,8 +360,10 @@ > /** > * Used to create proper {@link Syntax} objects. > */ > - SyntaxFactory syntaxFactory = Utils.getComponent(SyntaxFactory.class); > + private SyntaxFactory syntaxFactory = Utils.getComponent(SyntaxFactory.class); > Why are we holding a hard reference on the Execution which was present when the document was first loaded or created? Is this not a memory leak? Cache holds Document holds Execution holds ExecutionContext holds XWikiContext holds DocumentArchive? > + private Execution execution = Utils.getComponent(Execution.class); > + > /** > * @since 2.2M1 > */ > @@ -375,7 +378,9 @@ > @Deprecated > public XWikiDocument() > { > - this(Utils.getComponent(DocumentReferenceResolver.class).resolve("")); > + // TODO: Replace this with the following when we find a way to not generate a cycle: > + // this(Utils.getComponent(DocumentReferenceResolver.class).resolve("")); > + this(new DocumentReference("xwiki", "Main", "WebHome")); > } > > /** > @@ -397,25 +402,18 @@ > * > * @param wiki The wiki this document belongs to. > * @param space The space this document belongs to. > - * @param name The name of the document. > + * @param name The name of the document (can contain either the page name or the space and page name) > * @deprecated since 2.2M1 use {@link #XWikiDocument(org.xwiki.model.reference.DocumentReference)} instead > */ > @Deprecated > public XWikiDocument(String wiki, String space, String name) > { > - String normalizedPage; > - String normalizedSpace; > - int i1 = name.indexOf("."); > - if (i1 == -1) { > - normalizedPage = name; > - normalizedSpace = space; > - } else { > - normalizedSpace = name.substring(0, i1); > - normalizedPage = name.substring(i1 + 1); > - } > - > - init(Utils.getComponent(DocumentReferenceResolver.class, "current/reference").resolve( > - new DocumentReference(wiki, normalizedSpace, normalizedPage))); > + // We allow to specify the space in the name (eg name = "space.page"). In this case the passed space is > + // ignored. > + DocumentReference reference = resolveReference(name, new DocumentReference(wiki, space, null)); > + // Replace the resolved wiki by the passed wiki > + reference.setWikiReference(new WikiReference(wiki)); > + init(reference); > } > > public XWikiStoreInterface getStore(XWikiContext context) > @@ -5846,4 +5844,21 @@ > > return syntaxId; > } > + > + private DocumentReference resolveReference(String referenceAsString, DocumentReference defaultReference) > + { > + XWikiContext xcontext = getXWikiContext(); > + XWikiDocument originalCurentDocument = xcontext.getDoc(); > + try { > + xcontext.setDoc(new XWikiDocument(defaultReference)); > + return this.currentDocumentReferenceResolver.resolve(referenceAsString); > + } finally { > + xcontext.setDoc(originalCurentDocument); > + } > + } > + How is this different from XWikiDocument#getContext() introduced in 23506? Is the only difference that the context is the one from when the document was created/loaded rather than the current context? If so this probably ought to be commented since it is a major trap for anyone who expects getXWikiContext().getUser() to yield the current user (for example). > + private XWikiContext getXWikiContext() > + { > + return (XWikiContext) this.execution.getContext().getProperty("xwikicontext"); > + } > } > > Modified: platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java 2010-01-07 16:55:03 UTC (rev 26073) > +++ platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java 2010-01-07 22:02:51 UTC (rev 26074) > @@ -155,6 +155,29 @@ > this.mockXWikiStoreInterface.stubs().method("search").will(returnValue(new ArrayList<XWikiDocument>())); > } > > + public void testConstructor() > + { > + XWikiDocument doc = new XWikiDocument("notused", "space.page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("xwiki", doc.getWikiName()); > + > + doc = new XWikiDocument("space", "page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("xwiki", doc.getWikiName()); > + > + doc = new XWikiDocument("wiki", "space", "page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("wiki", doc.getWikiName()); > + > + doc = new XWikiDocument("wiki", "notused", "notused:space.page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("wiki", doc.getWikiName()); > + } > + > public void testGetDisplayTitleWhenNoTitleAndNoContent() > { > this.document.setContent("Some content"); > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications >

3 4

[xwiki-devs] [proposal] Fix XWIKI-4265 by changing the way the previous version of a document is found.
by Caleb James DeLisle 17 Apr '10

17 Apr '10

Currently, api.Document.getPreviousVersion() calls doc.XWikiDocument.getPreviousVersion() which calls doc.XWikiDocument.getDocumentArchive() which will return null if the document archive is not currently loaded. doc.XWikiDocument.getPreviousVersion() is inherently dangerous and should be deprecated then removed. doc.XWikiDocument.getDocumentArchive() sometimes returns null and should be deprecated then made private. everywhere doc.XWikiDocument.getDocumentArchive() is used it should be replaced with doc.XWikiDocument.getDocumentArchive(XWikiContext) which calls loadDocumentArchive first. What I propose we do now (for 2.3) #1 Change api.Document.getPreviousVersion() to call getDocumentArchive(getXWikiContext()) and move the logic from doc.XWikiDocument.getPreviousVersion() into api.Document.getPreviousVersion() #2 change doc.XWikiDocument.copyDocument(DocumentReference newDocumentReference, XWikiContext context) to call getDocumentArchive(XWikiContext) instead of getDocumentArchive() #3 Add warnings in javadoc for: clone(XWikiDocument document) cloneInternal(DocumentReference newDocumentReference, boolean keepsIdentity) to say that they may not copy the archive since they use getDocumentArchive() #4 mark doc.XWikiDocument.getPreviousVersion() and doc.XWikiDocument.getDocumentArchive() as depricated and explain why in a comment. WDYT? Caleb

3 7

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.2.5 Released
by Thomas Mortagne 16 Apr '10

16 Apr '10

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.2.5. This is a bug fix release for the 2.2 branches. Improvement * [XSCOLIBRI-206] - Use isInPortletMode and isInServletMode velocity variables instead of querying context mode * [XWIKI-5095] - Introduce isInPortletMode and isInServletMode velocity variables and use them instead of querying context mode * [XWIKI-5096] - Prevent ActionFilter from being called recursively and map it only to the action servlet * [XWIKI-5097] - Make sure SavedRequestRestorerFilter is not applied recursively * [XWIKI-5114] - Allow controlling the depth of headers to look for when generating titles from document's content Important Bugs fixed * [XSCOLIBRI-207] - Printing problems with displaying content and comments * [XPMAIL-24] - If there is an exception while sending mail which has no message (NPE) another exception is thrown hiding the real one. * [XWIKI-5076] - Fail to parse content with macro containing only a newline * [XWIKI-5085] - OfficeImporter does not set title of imported documents * [XWIKI-5086] - OfficeImporter is generating absolute links when performing splitting operations * [XWIKI-5087] - Paging History is broken * [XWIKI-5093] - Cancel edit JavaScript handler doesn't check if the URL fragment is present before appending the query string * [XWIKI-5094] - Administration rights editor cannot be used in portlet mode * [XWIKI-5107] - URLs are not escaped in link labels if link meta data is missing * [XWIKI-5109] - The application/x-www-form-urlencoded reader for objects and properties is broken * [XWIKI-5116] - NPE during resolution of XClassReference * [XWIKI-5119] - In a subwiki, a global user cannot save global documents * [XE-634] - RecentChanges fails to display with some mysql versions For more information see the Releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise225 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM225 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Computed title depth configuration option
by Vincent Massol 16 Apr '10

16 Apr '10

Hi, We've had a user request (Ludovic as a user ;)) to have a config option to decide the header level to consider for a title. Right now we consider only levels 1 and 2 when computing a title from the doc content. Thus I'm going to add a config option named xwiki.title.headerdepth and with a default value of 2 (to have the same behavior as now) and use it in XWikiDocument.getRenderedContentTitle(). Note that this is only for the 2.0 syntax (since it's too hard to do for syntax 1.0 and we're not supposed to bring changes to the 1.0 syntax). Please shout quickly if you're against this. Thanks -Vincent

5 8