xwiki-devs July 2007

xwiki-devs@xwiki.org

25 participants
104 discussions

[VOTE] Removing 2 XWiki.saveDocument() APIs

by Vincent Massol

Hi, I'd like to to commit the fix for http://jira.xwiki.org/jira/browse/ XWIKI-1517 This involves removing 2 of the 4 APIs. Indeed, 2 APIs take an olddoc parameter of a XWikiDocument type. The only reason for this is because the notification mechanism requires two documents so that it can check if the new one has differences over the old one and send notifications accordingly. However this need should be an implementation need and should not surface in the API. Hence XWIKI-1517. BTW this change allows fixing http://jira.xwiki.org/jira/ browse/XWIKI-1518 and some other potential bugs too. Note: I'm not changing the *.api.XWiki object (only the one in *.xwiki.XWiki). This change will a small impact on people building XWiki applications on top of the XWiki platform but not on end users. I feel this is still ok because: * We need to improve our API if we want to progress in improving XWiki * The alternative is to create a XWiki 2.0 version but we won't have enough manpower to 1) continue supporting the 1.x line and 2) to build XWiki 2.0 from scratch. I think our only reasonable option is to build on XWiki 1.x and start refactoring the internal APIs slowly, a bit in each version. * I'll document this in the release notes * It's easy to fix for anyone hit by this * End users are not touched * It fixes current existing bugs * It makes the API easier to use. Right now in 99% of the code I had to change the olddoc was simply a clone of the current doc thus making the call useless So here's my +1 Thanks -Vincent

18 years

Logging..

by Erin Schnabel

xwiki.org says that XWiki uses log4j, but the code uses a mix of both commons logging interfaces, and those particular to log4j.. Should we be picking one? It seems that the commons logging interfaces would be preferred (as it knows how to interact with log4j), but I'm not sure. ? -- Waste of a good apple. --Samwise Gamgee

18 years

by Guo Ray

18 years

maven build problem

by Jackson Wang

Hi, I change mysql connect url setting in xwiki-2.pom (local repository) from <xwiki.db.connection.url>"jdbc:mysql://localhost/xwiki?useServerPrepStmts=false"</xwiki.db.connection.url> to <xwiki.db.connection.url>"jdbc:mysql://localhost/xwiki ?useUnicode=true&useServerPrepStmts=false"</xwiki.db.connection.url> then build 'xwiki-web-standard' by 'mvn install -Pxe,mysql ', get eror: [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: unknown:xwiki-web-standard POM Location: E:\dev\xwiki\svnroot\xwiki-users\xwiki-platform-web\standard\pom.xml Reason: Cannot read project model from interpolating filter of serialized version. I have build successfully before this modification. Does pom file can not use the expression '&' ?

18 years

Email shortage of 16/17th July 2007 - Please resend

by Vincent Massol

Hi everyone, ObjectWeb (our infrastructure) is not answering as to whether we will recover the mails lost on the 16th and 17th. I have asked OW Admins at least 3 times for the past 6 days and they said they're working on it (but they haven't told us whether it'll be possible or not to recover them). Thus we cannot wait any longer as there were important mails sent during that period. I'm going to resend my emails and I advise everyone to do the same. We're really sorry about this. I'm following this up on OW's side. Please note that the emails sent this week end have also not made it to the list yet. Let's hope they're not lost too. Thanks and again please accept our apologies for all these emails issues we're suffering from the past 3 months. We're working on finding a solution real soon so that it doesn't happen again in the future. -Vincent Massol XWiki Release Manager

18 years

We still haven't received emails sent between the 16th and the 18th...

by Vincent Massol

Just a note to tell you that I have (again) asked the ObjectWeb admin to give us a status about the missing emails and that I have not yet received any answer... :( This is a real *pain*. I'm fully committed that these email issues don't happen again in the future. I'll let you know more about the solution... Thanks -Vincent

18 years

Why are we creating Tag objects automatically?

by Vincent Massol

Hi, Can someone tell me why we are creating empty Tag objects automatically for all documents. It seems to me this is wrong. Thanks -Vincent

18 years

LDAP and user registration

by Jacob Bresciani

I¹m setting up an xwiki for my organization and I¹ve managed to tie it to our 2003 Domain controller for user authentication. My problem is that with xwiki 1.0 users could just log in with their domain accounts, registration of said user was automatic. With 1.1 milestone 2 the user must be registered first or they don¹t seem to have permissions to view anything, sometimes it just won¹t accept them at all. I¹m using the same configuration lines in xwiki.cfg for 1.1 as I did for 1.0. Am I missing something? Or is this working as intended? ------------------------------------------------------------------ Jacob Bresciani Systems Analyst, Information Systems Support Procurement and Supply Services Phone: (250) 356-7115 Fax: (250) 387-0388 E-mail: jacob.bresciani(a)gov.bc.ca Visit us online at: http://www.pss.gov.bc.ca/ Committed to our customers ... always working for you!

18 years

Fwd: About XWiki XMLRPC

by Asiri Rathnayake

I'm re-sending this email because i just heard that mailing list was down for past two days. Please excuse me If you receive this mail twice. Thanks. - Asiri ---------- Forwarded message ---------- From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com> Date: Jul 18, 2007 9:37 AM Subject: About XWiki XMLRPC To: xwiki-dev(a)objectweb.org Hi all, After going through xwiki sources, I finally managed to fix the issues with XMLRPC. But before opening up any JIRA issues or submitting patches, i thought it would be better to get some feedback. Following are my observations on XMLRPCs, 1. XWiki's XMLRPC implementation does not map one-to-one with the given documentation<http://confluence.atlassian.com/display/DOC/Remote+API+Specification> Ex. - in XWiki, there is no method as removePage(), instead we have deletePage() - in XWiki, there is no method as removeSpace() but it's achieved by deleting all the child pages. 2. Some XMLRPCs are not implemented. But these are not used used in Xeclipse (yet), so i didn't pay much attention to them. 3. One XMLRPC call threw an exception when it's return type was 'void'. I changed this one to 'boolean' and everything works fine. I don't know why this happens though. 4. storePage() RPC had a problem which makes it override other pages when trying to save a newly created page. I think this is a typo, anyway, it's fixed. 5. I also noted that there is a XWiki specific XMLRPC API too (which is very limited). So, if any of you have any concerns, thoughts, opinions, please throw them in. I'll create the JIRA issues little later. Thanks. - Asiri

18 years

XWikiMessageTool refactoring

by Sergiu Dumitriu

Hi, I looked today over the XWikiMessageTool class, and I must say that I'm not quite satisfied with it. First, there was XWIKI-919, which I implemented. OK, I understand that files stored on disk should be charset independent, so only ASCII characters are supported by the ResourceBundle class (jvm) .But, when I can edit a wiki document for storing bundles, I expect it to accept all the characters the wiki supports (in my case, it was an UTF8 instance). I had some troubles fixing this, since the JavaDoc says that bundles accepts only ASCII characters, but it understands and parses unicode references ( \u0123 ). Maybe I did something wrong, but doing content.replaceAll("\u0139", "\\u0139") resulted in the string u0139 being displayed in the page. So I had to trick it into believing that the component bytes of the encoding are ASCII characters and manually restore the multibyte chars. Second, I don't like the fact that XWIKI-921 was not already implemented. Third, I don't like the cache refresh mechanism. It retrieves the XWikiProperties->documentBundles property for each request, and It retrieves the bundle documents for every request and checks if it must be refreshed or not. Why isn't the com.xpn.xwiki.notify package used? It allows registering callback handlers for specific document changes. How I see it: - at startup, register a handler for XWiki.XWikiPreferences (so that we know when the documentBundles property might change). - remember the list of document bundles, don't ask it for each request - also register handlers for the current bundle documents and load the strings from these documents - when XWikiPreferences is changed, if the documentBundle property is also changed, remove the unused bundles and build the new ones - when a undle document (or a translation for it) is changed, rebuild the bundle for that document This should speedup the code a bit, it makes use of a nice, but mostly unknown feature, it doesn't log an error for each request when a specified document is not found in the wiki, and it doesn't require so many variables (previousDates, docsToRefresh). Fourth, as I said above, if a document is specified in the documentBundles property, but it does not exist in the wiki, for each $msg.get call an error is logged. And there are a lot of calls for each request. Now, in my opinion this is a nice way to get in the core of XWiki for a newcomer, so does anybody want to write the changes I mentioned? Also, this is a good occasion to document the event notification mechanism, in JavaDoc and on www.xwiki.org Regards, Sergiu Dumitriu -- http://purl.org/net/sergiu

18 years

← Newer
1
2
3
4
5
6
7
...
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2007