Hi JV,
On Aug 12, 2007, at 9:13 PM, Jean-Vincent Drean wrote:
[snip]
> +#if($query != "")
> + #set($lucene = $xwiki.getPlugin("lucene"))
> + #if($lucene)
[snip]
> + #else
> + Error: Lucene plugin not found.
I think it would be nice to tell the user that the Lucene plugin is
not enabled in xwiki's configuration and add a link to the old search
here.
Also what happens if the lucene plugin isn't found? It seems to me
the rest of the code below will get executed, no?
> + #end
> +#end
> +
> +#set($doRebuild = $request.getParameter("rebuild"))
> +#if($doRebuild=="yes")
> + #set($lucene = $xwiki.getPlugin("lucene"))
> + #if($lucene)
> + #set($documentCount = $lucene.rebuildIndex($xwiki,$context))
> + #if(${documentCount}>=0)
> + #info("Started index rebuild with $documentCount documents.\\
> + Will take some time depending on
> the number of pages/attachments.")
> + #else
> + #error("Error: Index rebuild failed.")
> + #end
> + #end
> +#else
> + #if($xwiki.hasAdminRights())
> + #info ("[Rebuild the lucene index>${doc.web}.${doc.name}?
> rebuild=yes]")
> + #end
> +#end
> +
> +#warning("This is the new lucene search engine.\\
> + You can still use the XWiki [default search
> engine>WebSearch?text=$query]..")</content>
There's an extra dot ("."). Shouldn't this be an "info" rather than a
warning? Or it could stay a warning but in that case it might be
better to tell the user that this is an experimental feature, WDYT?
Thanks
-Vincent
Can anyone answer this question?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
<http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
<http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
From: Kito D. Mann [mailto:kmann@virtua.com]
Sent: Sunday, August 05, 2007 2:15 AM
To: xwiki-users(a)objectweb.org
Subject: [xwiki-users] xWiki and eXo 1.1.x
Hello,
Is there a version of xWiki that works with eXo portal 1.1.x?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
<http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
<http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
* Sign up for the JSF Central newsletter!
http://oi.vresp.com/?fid=ac048d0e17 *
Hi,
If our goal is to implement the Confluence XMLRPC interface (http://
confluence.atlassian.com/display/DOC/Remote+API+Specification) then
it seems to me we shouldn't throw XWikiException in any method in our
ConfluenceRpcInterface interface. Several methods instead should
return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
Are we ok to remove all exception throwing?
Thanks
-Vincent
Hi All,
Until recently XMLRPCs returned pages with titles of the form
"<space-name>.<page-title>"
but after i built xwiki's latest sources today, i figured out that they now
have the form "<page-title>" (space name is gone).
We need to change XEclipse a bit to accommodate this change (a very very
tiny change).
Anyway, what caused this change ? am I missing something ?
Thanks.
- Asiri
Hello,
We have decided to implement the Confluence Remote API because the
interoperability would bring many advantages to XWiki (as Vincent
explained here http://tinyurl.com/ypfamt). However at this moment the
XWiki implementation of this API is not yet interoperable with
Confluence. And this is not only because we are implementing only a
very small subset of the API, but more important because nobody ever
checked that we are in fact behaving similarly.
The goal should be to write clients that are able to run against XWiki
or Confluence servers without being able to tell any difference. At
this moment this is not the case and there are many reasons for this.
One reason is that we are currently relying on dynamic proxies in our
client code (http://ws.apache.org/xmlrpc/advanced.html). In this
setting the client and the server have to use the same Java interface,
namely com.xpn.xwiki.xmlrpc.ConfluenceRpcInterface. And no, there is
absolutely no chance to convince the Confluence team to implement this
XWiki-specific interface.
One way around this is to write client code which does not use dynamic
proxies, but that is tedious and error prone (e.g. you can pass as
many agruments as you like and you can call methods that don't exist).
Remote calls look like this:
token = (String)rpc.execute("confluence1.login", new Object[] {token,
username, password});
There is however a better option, and that is to use
swizzle-confluence, a client proxy for the confluence XML-RPC API
(http://docs.codehaus.org/display/SWIZZLE). This would offer all the
advantages of calling a typed proxy. Still all calls would eventually
look like the one above, so they could go to any server that
implements the interface (whether it's XWiki or Confluence). There are
many other advantages: swizzle is intuitive, well-documented,
well-tested and makes it unnecessary to explicitly pass a token
around.
Switching to swizzle would mean that all our client code would need to
be modified. I already started to convert our tests to swizzle and it
seems an easy task. Setup is a lot easier than before. Compare this:
XmlRpcClientConfigImpl clientConfig = new XmlRpcClientConfigImpl();
clientConfig.setServerURL(new URL("http://127.0.0.1:8080/xwiki/xmlrpc"));
XmlRpcClient rpcClient = new XmlRpcClient();
rpcClient.setConfig(clientConfig);
ClientFactory factory = new ClientFactory(rpcClient);
xwikiRpc = (ConfluenceRpcInterface)factory.newInstance(ConfluenceRpcInterface.class);
to this
Confluence rpc = new Confluence("http://127.0.0.1:8080/xwiki/xmlrpc");
And using swizzle for the tests will allow not only to test the xwiki
implementation, but to validate that we are testing the right behavior
by running the tests against a confluence instance (this can be done
once when designing the test, not all the time).
Using swizzle is however not enough. Additionally we need to ensure
that the observable behavior of XWiki matches that of Confluence. For
example we will need to adjust the way we deal with page modifications
and histories to the way Confluence does it. And we will need to
mirror even strange behavior in Confluence. For example we will need
to convert all non-string primitive values (e.g int, Date) into
strings in the maps and lists that get exchanged between the client
and server. Even if this is strange, this is how Confluence does it
and this is how clients (like the ones using swizzle) expect their
results.
I'm already working on these modifications and if everybody agrees
they will make it into the trunk after the M4 release. The easiest way
to adapt clients to these changes will be to make them use swizzle.
Regards,
Catalin
Hi!
We have a (maybe very small) problem that keeps us busy for weeks now, and we do not find the solution.
We want to create XWiki-documents from another web-application and set also the document-rights depending on the rights the user has in that other web-application.
Creating the document works very fine and also the document-rights are set correctly in the database. But with the document-rights we unfortunately have (presumably) problems with the cache.
When a user opens the link to a XWiki-document, the document-rights of that document are newly set before the document is openend. So when user "1" opens a new XWiki-document, the user "XWiki.1" (xws_value) is entered in the db-table "xwikistrings" along with the value "users" in the "xws_name"-column (xws_id of the document). And that user can then correctly see the XWiki-document. But when a second user "2" wants to open that same document, he only gets the message "You are not allowed to view this document or perform this action" although he is correctly entered in the "xwikistrings"-table: xws_id = id of document; xws_name = users; xws_value = "XWiki.1,XWiki.2". That second user can see the document not until a $xwiki.flushcache() is performed (which is not easy to automatically realize in that process) or the tomcat is restartet. A com.xpn.xwiki.XWiki.flushCache() in our Java-Code - which would serve us best - does somehow not have the desired effect.
If we run XWiki without Cache (xwiki.store.cache) our procedure works also correctly. Hence, it seems like flushing the cache from our java-code does not work for any reason.
Here is our code for setting the document-rights:
private boolean doUpdateRight(String fullname, String user, String group, String level, boolean allow, boolean global) throws XWikiException {
this.xdoc = xwiki.getDocument(fullname, context);
this.bobj = new BaseObject();
this.bobj.setName(fullname);
if (global)
this.bclass = xwiki.getGlobalRightsClass(context);
else
this.bclass = xwiki.getRightsClass(context);
this.bobj = (BaseObject) xdoc.getObject(bclass.getName());
String oldusers = bobj.getStringValue("users");
if(!(oldusers.contains(user))) {
bobj.setStringValue("users", oldusers+","+user);
XWikiDocument tdoc;
tdoc = xdoc;
XWikiDocument olddoc = (XWikiDocument) tdoc.clone();
tdoc.setObject(bclass.getClassName(), 0, bobj);
xwiki.saveDocument(tdoc, olddoc, context);
xwiki.flushCache();
}
return true;
}
When starting Xwiki we get the warning, that oscache.properties and oscache-local.properties are not loade although they are existing in the WEB-INF folder ([http-8080-Processor24] WARN com.xpn.xwiki.cache.impl.OSCacheService - Could not load cache properties oscache.properties: null [http-8080-Processor24] WARN com.xpn.xwiki.cache.impl.OSCacheService - Could not load cache properties oscache-local.properties: null). Could that have an influence on the XWiki-cache problem mentioned above?
We are working with XWiki 1.0
We would be very pleased if anybody could help us out. We do have no further ideas what else to try :-(
Thanks in advance!
Georg