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
Hello,
First of all sorry for the my english, I hope it's understandable.
For the multiwiki plugin (mostly used for XEM product) needs I had
started to make some JAVA tools mostly for plugins development that
can be useful for others. I will expose you the ideas to let everyone
discuss around and see what I can change. First implementation (to
illustrate) of theses ideas are in jira.
SUPERCLASS:
http://jira.xwiki.org/jira/browse/XWIKI-1576
First the "SuperClass" concept: not very original (inspired by
"com.xpn.xwiki.plugin.userdirectory.Group" class), it's a Xwiki Class
and Xwiki Object management tool. It automate some very common actions
and assure that needed Class document exist and is valid.
It's composed in two interfaces and their abstract default
implementations : ISuperClass (and AbstractSuperClass) and
IsuperDocument (and IsuperDocument).
SuperClass : manage the Xwiki Class document :
- first it assure that when using it the class exists in the
database with all needed feelds. Not only the Class but also the
ClassSheet and the ClassTemplate documents.
- it generate, based on the actual pseudo xwiki product
implementation norm, all the "ClassName", "FullClassName",
"ClassSpace", "ClassSheetName", etc.
SuperDocument : manage document containing one instance object of this
XwikiClass : just encapsulate XwikiDocument and Document and simplify
creation, saving, deleting, merging.
These two java classes had to be extended with the type we want to
manage (Group, User, Application, Wiki, etc.).
XWIKI APPLICATION:
http://jira.xwiki.org/jira/browse/XWIKI-1577 (also a example of
"SuperClass" use)
To create a new sub wiki in XEM from template I need to determine in
the "template" wiki which document have to be copied and which
included. For this I think that have a real "Xwiki Application"
descriptor can be very useful. My implementation is composed in a
mainly document that contains all application configuration:
- application name (that can be different from Document name)
- other applications dependencies
- document that application contains (that is not in other
applications dependencies)
- in theses documents which have to be included
and other field that I had not implemented yet but can be very soon:
- plugins dependencies
- in theses document which have to be linked (need that XWiki
support this concept)
For now my "application packager" just give to the actual xwiki xar
packager all the documents including applications descriptors
documents and make a xar file with all this. I think an other format
that a maven plugin can parse like XML application descriptor to
generate the package combining all the applications dependencies can
be made later.
Regards,
Thomas