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
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
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 '&' ?
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
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
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!
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
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