March 2009 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Release XE 1.8 final
by Thomas Mortagne 19 Mar '09

19 Mar '09

Hi devs, All blocking bugs are fixed and remaining features are moved to 1.9 branch. Time to release 1.8 final. You can look at http://jira.xwiki.org/jira/secure/ReleaseNote.jspa?version=11012&styleName=… for a detailed release note. Here is my +1. -- Thomas Mortagne

8 8

[xwiki-devs] Xwiki Forms Error - com.xpn.xwiki.api.XWiki threw exception java.lang.ClassFormatError: Invalid method Code length
by Rajeshere 19 Mar '09

19 Mar '09

Hi, I have created a custom application using Xwiki forms and the size of the page to add a new item is too large. Now, when i tried to add few more lines of code in it, it throws following error. org.apache.velocity.exception.MethodInvocationException: Invocation of method 'includeForm' in class com.xpn.xwiki.api.XWiki threw exception java.lang.ClassFormatError: Invalid method Code length 66381 in class file Script1 @ ACSFacilities.test221,8? at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:300) Failed to find a solution in Xwiki FAQ's and forums. Your kindly help is much appreciated... Thanks. Regards, Rajesh -- View this message in context: http://n2.nabble.com/Xwiki-Forms-Error---com.xpn.xwiki.api.XWiki-threw-exce… Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 4

Re: [xwiki-devs] How to implement SSO in XWiki?
by Shiva Shankar 18 Mar '09

18 Mar '09

Hi This has been discussed in the past. http://n2.nabble.com/Which-forum-to-use-with-XWiki-tp505129p505129.html Regards, Shiva vijaydesai wrote: > > Please tell me how to integrate XWiki with JForum, Apache Roller using > SSO? > I was successful in implementing LDAP authentication using Active > Directory in XWiki but I am unable to implement SSO in XWiki. > > We are working on a portal which includes forum, blog and xwiki to be > integrated.. > Please tell me how to make any configuration changes or code changes in > XWiki for SSO implementation? > > > Thank you > Vijay > -- View this message in context: http://n2.nabble.com/How-to-implement-SSO-in-XWiki--tp2495723p2496004.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 0

[xwiki-devs] XE1.8 problem with long/big documents in firefox on windows?
by Niels Mayer 18 Mar '09

18 Mar '09

I saw this just recently playing around with abusing the rss:feed macro http://nielsmayer.com/xwiki/bin/viewrev/XWiki/NielsMayer?rev=17.1 which basically presents an entire blog as one **HUGE** document "{rss:feed= http://nielsmayer.com/roller/NielsMayer/feed/entries/rss|count=50|img=true|… " This actually works great -- even the flashplayers work -- however, in windows firefox 3.0.7, very long documents go "black" after several screenfulls of scroll. Further inspection reveals the HTML is correct and not truncated, and View-source shows the entire document was received. Viewing the same URL's in xemacs' w3m-browser or in MS Internet Explorer (7.0.5730.13) doesn't have this problem. Firefox 3.0.7 in fedora10 linux doesn't have this problem either. Some other documents exhibiting this problem in Windows Firefox but not other browsers. http://morgellonswiki.info/xwiki/bin/view/Spirochetes/ConflictsOfInterestDo… http://www.lymediseaseassociation.org/Conflicts.doc ) http://morgellonswiki.info/xwiki/bin/view/Sandbox/fda-gov-ohrms-dockets-ac-… http://www.fda.gov/ohrms/dockets/ac/01/transcripts/3680t2.rtf* )* FYI the whole reason for writing this mail was that i was about to report it as a office importer bug when i thankfully recalled seeing the same problem with the rss:feed macro) and realized it was more general. Before reporting a bug, I wanted to see if other people have this problem w/ Windows Firefox -- I have no other MS/Windows systems to test with. Niels http://nielsmayer.com

1 0

Re: [xwiki-devs] [xwiki-notifications] r17602 - in platform/core/trunk: xwiki-cache/xwiki-cache-tests/src/main/java/org/xwiki/cache/tests xwiki-containers/xwiki-container-api/src/main/java/org/xwiki/container xwiki-containers/xwiki-container-portlet/
by Thomas Mortagne 17 Mar '09

17 Mar '09

On Fri, Mar 13, 2009 at 11:46, Vincent Massol <vincent(a)massol.net> wrote: > > On Mar 13, 2009, at 11:31 AM, Sergiu Dumitriu wrote: > >> Vincent Massol wrote: >>> Hi Sergiu, >>> >>> On Mar 13, 2009, at 12:38 AM, sdumitriu (SVN) wrote: >>> >>>> Author: sdumitriu >>>> Date: 2009-03-13 00:38:08 +0100 (Fri, 13 Mar 2009) >>>> New Revision: 17602 >>>> >>>> Modified: >>>> platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/main/java/ >>>> org/xwiki/cache/tests/AbstractTestCache.java >>>> platform/core/trunk/xwiki-containers/xwiki-container-api/src/main/ >>>> java/org/xwiki/container/ApplicationContext.java >>>> platform/core/trunk/xwiki-containers/xwiki-container-portlet/src/ >>>> main/java/org/xwiki/container/portlet/PortletApplicationContext.java >>>> platform/core/trunk/xwiki-containers/xwiki-container-servlet/src/ >>>> main/java/org/xwiki/container/servlet/ServletApplicationContext.java >>>> platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/test/ >>>> TestApplicationContext.java >>>> Log: >>>> XWIKI-3312: Add a getTemporaryDirectory() method to >>>> ApplicationContext >>>> Done. >>>> Patch submitted by Dan Miron, enhanced and extended. >>>> >>>> >>>> Modified: platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/ >>>> main/ >>>> java/org/xwiki/cache/tests/AbstractTestCache.java >>>> =================================================================== >>>> --- platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/main/java/ >>>> org/xwiki/cache/tests/AbstractTestCache.java 2009-03-12 23:03:56 UTC >>>> (rev 17601) >>>> +++ platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/main/java/ >>>> org/xwiki/cache/tests/AbstractTestCache.java 2009-03-12 23:38:08 UTC >>>> (rev 17602) >>>> @@ -19,6 +19,7 @@ >>>> */ >>>> package org.xwiki.cache.tests; >>>> >>>> +import java.io.File; >>>> import java.io.InputStream; >>>> import java.net.MalformedURLException; >>>> import java.net.URL; >>>> @@ -130,6 +131,21 @@ >>>> } >>>> >>>> /** >>>> + * {@inheritDoc} >>>> + * >>>> + * @see >>>> org.xwiki.container.ApplicationContext#getTemporaryDirectory() >>>> + */ >>>> + public File getTemporaryDirectory() >>>> + { >>>> + try { >>>> + // The system temporary directory is a good place for >>>> temporary test data. >>>> + return new File(System.getProperty("java.io.tmpdir")); >>>> + } catch (SecurityException e) { >>>> + return new File("."); >>>> + } >>>> + } >>> >>> I don't understand why you had to modify the cache module. >> >> Because it implements ApplicationContext, don't ask me why it does >> that... I was pretty surprised by this also. > > Thomas? This looks wrong and it certainly is since there's code > duplication. The cache test implement ApplicationContext because cache components use it to get configuration files, it's a mock. > >>>> + >>>> + /** >>>> * @return a instance of the cache factory. >>>> * @throws Exception error when searching for cache factory >>>> component. >>>> */ >>>> >>>> Modified: platform/core/trunk/xwiki-containers/xwiki-container-api/ >>>> src/main/java/org/xwiki/container/ApplicationContext.java >>>> =================================================================== >>>> --- platform/core/trunk/xwiki-containers/xwiki-container-api/src/ >>>> main/java/org/xwiki/container/ApplicationContext.java 2009-03-12 >>>> 23:03:56 UTC (rev 17601) >>>> +++ platform/core/trunk/xwiki-containers/xwiki-container-api/src/ >>>> main/java/org/xwiki/container/ApplicationContext.java 2009-03-12 >>>> 23:38:08 UTC (rev 17602) >>>> @@ -20,6 +20,7 @@ >>>> */ >>>> package org.xwiki.container; >>>> >>>> +import java.io.File; >>>> import java.io.InputStream; >>>> import java.net.MalformedURLException; >>>> import java.net.URL; >>>> @@ -27,5 +28,15 @@ >>>> public interface ApplicationContext >>>> { >>>> InputStream getResourceAsStream(String resourceName); >>>> + >>>> URL getResource(String resourceName) throws >>>> MalformedURLException; >>>> + >>>> + /** >>>> + * Gets the directory which the container must provide for >>>> storing temporary data. The contents of this directory >>>> + * may be deleted between container restarts (<em>temporary</ >>>> em>, as the name implies), so it is not a safe place to >>>> + * store permanent/important data. >>>> + * >>>> + * @return a {@link File} object pointing to a directory that >>>> the application can use for storing temporary files >>>> + */ >>>> + File getTemporaryDirectory(); >>> >>> I don't like this too much but it's ok for now. However I don't think >>> this is a good generic solution for the future. I think it would be >>> better to implement a temporary storage that uses the same storage >>> api >>> as the other storages (main storage, version storage, attachment >>> storage, etc). The pb with returning a File is that 1) it ties us >>> to a >>> disk storage which might not be available in all environments for >>> various reasons and 2) it's not extensible and you cannot swap >>> another >>> implementation (like it you want to use a memory storage for >>> example). >>> >>> For this we need the new storage/model of course which is why it's ok >>> to have this now. >>> >>> WDYT? >> >> Yes, but this is not a storage, it's a temporary directory on the >> server. If we want to implement a temporary storage based on files, it >> will need to get a temporary directory. >> It seems normal to me that an >> environment should provide access to a place where to store data. > > In cargo I had used commons vfs for all file storage and this was > quite nice since it's independent of the underlying FS implementation > and it was providing several implementations (FS, ftp, http, memory, > etc). > http://commons.apache.org/vfs/filesystems.html > > That project is a bit dead now I think unfortunately but the idea was > very nice and that's what I had in mind. > > Once nice side effect was the ability to easily write unit tests for > file-based IO easily without going to the file system: > http://blogs.codehaus.org/people/vmassol/archives/think_tank.html#001370_ea… > > It might be overkill for now. Just a thought. > > -Vincent > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

3 2

[xwiki-devs] if you want to really delete, make sure it's not in recycle bin.
by Niels Mayer 17 Mar '09

17 Mar '09

Lets say you delete a spam user, e.g. /xwiki/bin/view/XWiki/xanax via the administration tools. You then log out as admin. Now, as an unregistered user, browse /xwiki/bin/view/XWiki/xanax You'll be given a link to 'Restore' the deleted file e.g. /xwiki/bin/undelete/XWiki/xanax?id=47 When an unregistered user clicks 'Restore' the file is restored (!! bug !!). Fortunately if the "restored" account is used for login, the user can't view or edit any files. IMHO there ought to be an additional option on deleting users which will also remove the account from the recyclebin or not recycle accounts. Unfortunately, if there's a file you wanted deleted, apparently an unregistered user will be able to find out it was there (say, through a search engine), and restore it if they want to. This is on 1.8RC2. Niels http://nielsmayer.com PS: quick and dirty solution -- set "xwiki.recyclebin=0"

2 1

Re: [xwiki-devs] [xwiki-notifications] r17629 - platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/render/filter
by Sergiu Dumitriu 17 Mar '09

17 Mar '09

jvelociter (SVN) wrote: > Author: jvelociter > Date: 2009-03-14 23:32:39 +0100 (Sat, 14 Mar 2009) > New Revision: 17629 > > Modified: > platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/render/filter/XWikiHeadingFilter.java > Log: > XWIKI-3360 Including a document with first or second heading level breaks the including document section edit links (Syntax 1.0) > > Internal count of section was incremented for headings of included documents while they are not part of the document and thus not subject to section edit in an included context. In doubt I left the comment related to the increment, though I am not sure it is relevant. > > > Modified: platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/render/filter/XWikiHeadingFilter.java > =================================================================== > --- platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/render/filter/XWikiHeadingFilter.java 2009-03-14 15:43:17 UTC (rev 17628) > +++ platform/core/branches/xwiki-core-1.8/xwiki-core/src/main/java/com/xpn/xwiki/render/filter/XWikiHeadingFilter.java 2009-03-14 22:32:39 UTC (rev 17629) > @@ -158,15 +158,15 @@ > } > > if (level.equals("1") || level.equals("1.1")) { > - // TODO: This is unstable, meaning that it works in the current skin, but it might > - // fail if there are other headings processed before the document content. > - sectionNumber++; > // This check is needed so that only the document content generates sectionedit > // links. > // TODO: Find a better way to make this check, as this prevents generating links for > // titles that are transformed by velocity (1.1 about $doc.fullName) or by radeox > // (1.1 This is *important*). > if (doc != null && doc.getContent().indexOf(title.trim()) != -1) { > + // TODO: This is unstable, meaning that it works in the current skin, but it might > + // fail if there are other headings processed before the document content. > + sectionNumber++; > StringBuffer editparams = new StringBuffer(); > if (xcontext.getWiki().getEditorPreference(xcontext).equals("wysiwyg")) { > editparams.append("xpage=wysiwyg&section=").append(sectionNumber); You just re-introduced http://jira.xwiki.org/jira/browse/XWIKI-1176 Too bad there was no test for it (my fault). The problem is that the section edit buttons should be added just for real sections in the current document, but it is hard to do that. The current code does a simple check to see if the current header (wiki syntax) is found in the document. This raises two issues: since radeox is executed after velocity, if the document source contained a heading with velocity, this check raises a false negative. Now: - if we put the increment inside the if, the sections will be wrong because of this false negative - if we leave it outside, true negatives (like imported content or headers generated inside loops) will also shift section numbers So either way, the whole code is wrong. For reference, this was the change I made: http://fisheye2.atlassian.com/changelog/xwiki?cs=4485 (for some unknown reason svn fails to show the changes, although it says that 3 lines were added and one removed). -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

[xwiki-devs] [VOTE] Switch to UTF-8 by default in our distributions
by Sergiu Dumitriu 17 Mar '09

17 Mar '09

Niels Mayer wrote: > > PS: Why not just have xwiki.cfg's default be: 'xwiki.encoding=UTF-8' ; > likewise have web.xml's default for > com.xpn.xwiki.web.SetCharacterEncodingFilter's 'encoding' be UTF-8. These > encoding errors that oft go unnoticed are probably resulting in a number of > configuration errors, and perhaps other bug-reports that aren't entirely > valid, should they depend on encoding issues. Big +1 This is one of the oldest issues open (http://jira.xwiki.org/jira/browse/XWIKI-94) I guess that since we're nearing 2.0, it would be a good thing to set this on trunk, before the 1.9M1 release. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

5 12

[xwiki-devs] [Proposal] Move WYSIWYG DOM API in a separate module
by Marius Dumitru Florea 17 Mar '09

17 Mar '09

Hi devs, The new WYSIWYG editor uses an enhanced DOM API to manipulate the edited document. This API extends the default DOM API found in GWT adding: * W3C Range and Selection support ( http://tinyurl.com/cvsm3a ) * Multiple-window support ( http://tinyurl.com/cphdep ) * Depth-first pre-order iterator (part of Document traversal support) * Lots of DOM utility methods I'd like to move this API in a separate build module to make it reusable inside and outside XWiki. We could name it xwiki-web-gwt-dom (or xwiki-gwt-dom?) and place it, at list for now, in platform/web/gwt-dom (or platform/web/xwiki-gwt-dom?). Also, I'd like to rename the package name from com.xpn.xwiki.wysiwyg.client.dom to org.xwiki.gwt.dom. WDYT? Marius

6 5

Re: [xwiki-devs] [xwiki-notifications] r17677 - in platform/core/trunk/xwiki-xml: . src/main/java/org/xwiki/xml/internal/html
by Vincent Massol 17 Mar '09

17 Mar '09

Hi Asiri, On Mar 16, 2009, at 6:58 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-03-16 18:58:57 +0100 (Mon, 16 Mar 2009) > New Revision: 17677 > > Modified: > platform/core/trunk/xwiki-xml/pom.xml > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/DefaultHTMLCleaner.java > Log: > XWIKI-3365: Get rid of jdom dependency in xwiki-xml module > > * Fixed. [snip] > + } > // Workaround HTML XML declaration bug. > - fixCleanedNodeBug(cleanedNode); > - > - // Ideally following code should be enough. But SF's HTML > Cleaner seems to omit the DocType declaration while > - // serializing. > - // See https://sourceforge.net/tracker/index.php?func=detail&aid=2062318&group_id=… > - // cleanedNode.setDocType(new DoctypeToken("html", > "PUBLIC", "-//W3C//DTD XHTML 1.0 Strict//EN", > - // "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd > ")); > - // try { > - // result = new DomSerializer(cleanerProperties, > false).createDOM(cleanedNode); > - // } catch(ParserConfigurationException ex) { } > - // As a workaround, we have go through JDOM so that we can > set the DocType manually. > - org.jdom.Document jdomDoc = null; > - jdomDoc = new JDomSerializer(cleanerProperties, > false).createJDom(cleanedNode); > - jdomDoc.setDocType(new DocType("html", "-//W3C//DTD XHTML > 1.0 Strict//EN", > - "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd")); > + fixCleanedNodeBug(cleanedNode); > + // Serialize the cleanedNode TagNode into a w3c dom. > try { > - result = new DOMOutputter().output(jdomDoc); > - } catch (JDOMException ex) { > - throw new RuntimeException("Error while transforming > jdom document into w3c document", ex); > + Document tempDoc = new DomSerializer(cleanerProperties, > false).createDOM(cleanedNode); > + DOMImplementation domImpl = > + > DocumentBuilderFactory > .newInstance().newDocumentBuilder().getDOMImplementation(); > + DocumentType docType = > + domImpl.createDocumentType(QUALIFIED_NAME_HTML, "-// > W3C//DTD XHTML 1.0 Strict//EN", > + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd > "); > + result = domImpl.createDocument(null, > QUALIFIED_NAME_HTML, docType); > + > result.replaceChild(result.adoptNode(tempDoc.getDocumentElement()), > result.getDocumentElement()); > + } catch (ParserConfigurationException ex) { > + throw new RuntimeException("Error while serializing > TagNode into w3c dom.", ex); cool but why have you removed the comment saying that there's a SF html cleaner bug? Can you put it back and instead add that this is workaround? Thanks -Vincent

2 1