August 2011 - xwiki-devs@xwiki.org

[xwiki-devs] XWiki on Cassandra
by Caleb James DeLisle 05 Aug '11

05 Aug '11

I have an instance of XWiki finally running on Cassandra. http://kk.l.to:8080/xwikiOnCassandra/ Cassandra is a "NoSQL" database, unlike a traditional SQL database it cannot do advanced queries but it can store data in a more flexible way eg: each row is like a hashtable where additional "columns" can be added at will. The most important feature of Cassandra is that multiple Cassandra nodes can be connected together into potentially very large "swarms" of nodes which reside in different racks or even data centers continents apart, yet all of them represent the same database. Cassandra was developed by Facebook and their swarm was said to be over 200 nodes strong. In it's application with XWiki, each node can have an XWiki engine sitting on top of it and users can be directed to the geographically closest node or to the node which is most likely to have a cache of the page which they are looking for. Where a traditional cluster is a group of XWiki engines sitting atop a single MySQL engine, this allows for a group of XWiki engines to sit atop a group of Cassandra engines in a potentially very scalable way. In a cloud setting, one would either buy access to a provided NoSQL store such as Google's BigTable or they would setup a number of XWiki/Cassandra stacks in a less managed cloud such as Rackspace's or Amazon's. How it works: XWiki objects in the traditional Hibernate based storage engine are persisted by breaking them up into properties which are then joined again when the object is loaded. A user object which has a name and an age will occupy a row in each of three tables, the xwikiobjects table, the xwikistrings table, and the xwikiintegers table. The object's metadata will be in the xwikiobjects table while the name will be in a row in the xwikistrings table and the age, a number, will go in the xwikiintegers table. The NoSQL/Datanucleus based storage engine does this differently, the same object only occupies space in the XWikiDocument table where it takes advantage of Cassandra's flexibility by simply adding a new column for each property. NOTE: this is not fully implemented yet, objects are still stored serialized. What works * Document storage * Classes and Objects * Attachments * Links and Locks * Basic querying with JDOQL What doesn't work * Querying inside of objects * JPQL/XWQL queries * Document history * Permissions (requires unimplemented queries) * The feature you want I am interested in what the community thinks is the first priority, I can work on performance which will likely lead to patches being merged into master which will benefit everyone or I can work on more features which will benefit people who want to use XWiki as a traditional application wiki but use it on top of Cassandra. You can reply here or add comments to the wiki ;) Caleb

3 6

[xwiki-devs] Restlet upgrade / Breaking APIs
by Jerome Velociter 04 Aug '11

04 Aug '11

Hello devs, I finally found a way to work with an issue in our REST annotation API that prevented to upgrade to Restlet 2.0.8 (see http://jira.xwiki.org/jira/browse/XWIKI-6632) The upgrade introduces some non-backward compatible change in 5 classes in the REST server module. Mostly Restlet plumbing (that probably should have been in an internal package in the first place). You can see the incriminated classes here : https://github.com/jvelo/xwiki-platform/commit/ebda7e5792839a89164f9fa27c15… If anyone here knows of any reason why this classes should not be broken, let them speak now, or forever hold their peace. Peace, Jerome

2 2

[xwiki-devs] [Discussion] Defining Sheets
by Marius Dumitru Florea 04 Aug '11

04 Aug '11

Hi devs, A prerequisite for Application Within Minutes [1] is to be able to specify the sheet that will be used to display a document without touching the content of that document [2]. This can be done in multiple ways, depending on how we define the notion of a sheet. (1) Class sheets vs. document sheets A class sheet displays an object of a particular type and is specified in the definition of that type. This means that when you create or edit a class, i.e. a type of object, you can specify which sheet should be used to display the instances of that class. Pro: Documents don't have to specify a sheet. Con: We have to determine which sheet to use in case there are multiple objects attached to a document. A document sheet displays a document of a particular type and is specified at document level because the document type, unlike the xclass, does not exist actually. The document type is inferred from the type of objects the document has, or from its content, or, why not, from the type of attachments it has. Pro: Doesn't have the class sheet con. Con: Each document has to specify which sheet to use. Class sheets are enough for Application Within Minutes because the wizard will create a single class (with a sheet) and so the application items will have only one object that specifies a sheet. (2) Separate sheets per action? The current practice is to define a single (class) sheet which either checks for the current action in its code or uses doc.display method whose output is action specific. How often did you had the need to write separate sheets per action (e.g. create, view, edit, search, changes)? (3) Which actions require a sheet? If we're talking about class sheets then the list of actions that target an object and which require a sheet is limited. Currently we have "view" and "edit", but Ludovic proposed also "create", "search" and "changes". If we're talking about document sheets then we can have custom actions and so we need an extensible mechanism to map actions to sheets. (4) Sheet parameters? If we're talking about class sheets then they only need to specify how an object is displayed. Document sheets on the other hand may need to control elements like: * which tabs (comments, annotations, attachments, etc.), if any, are displayed * show title field in edit mode * the side panels * the form buttons WDYT? Thanks, Marius [1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes [2] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…

7 14

Re: [xwiki-devs] Need help on creating virtual xwiki using API
by Eduard Moraru 04 Aug '11

04 Aug '11

Hi Karamjit, WikiManager plugin requires admin rights for handling subwikis. See http://jira.xwiki.org/jira/browse/XEM-113 for details and a workaround. Thanks, Eduard On Jul 31, 2011 5:08 PM, "Karamjit Singh" <karamjitmult(a)gmail.com> wrote: > > Yes. I have installed it already. I am getting bellow error message > " you donot have create wiki rights" > > Looks like a permission issue. Any idea how to set user in wikicontext? > On Jul 31, 2011 7:23 PM, "Eduard Moraru" <enygma2002(a)gmail.com> wrote: > > Hi Karamjit, > > > > On Sun, Jul 31, 2011 at 2:13 PM, Karamjit Singh <karamjitmult(a)gmail.com > >wrote: > > > >> Hi Team, > >> > >> I am not able to create virtual xwiki through the XwikiManagerPluginAPI. > I > >> have developed just sample restful web service. Below is the code which I > >> am > >> using to create virtual xwiki :- > >> > >> @Component("org.sisgma.xwiki.rest.HelloWorldResource") > >> @Path("/hello/") > >> public class HelloWorldResource extends XWikiResource { > >> public HelloWorldResource(){ > >> } > >> @GET > >> public String get(@DefaultValue("world") String myresourcename) throws > >> XWikiException, QueryException { > >> XWikiContext ctx = Utils.getXWikiContext(componentManager); > >> try { > >> WikiManagerPluginApi aoi = > >> > >> > (WikiManagerPluginApi)ctx.getWiki().getPluginApi(WikiManagerPlugin.PLUGIN_NAME, > >> ctx); > >> ctx.setDoc(new XWikiDocument(new DocumentReference("jaspreet", "space", > >> "page"))); > >> System.out.println("_____________********* deleting xwiki"); > >> aoi.deleteWiki("neenu", true); > >> aoi.deleteWiki("neenu1", true); > >> aoi.deleteWiki("karam", true); > >> System.out.println("_____________********* deleted xwikies"); > >> System.out.println("_____________********* Creating new xwiki"); > >> aoi.createNewWiki("jaspreet", "templatexe", > null,aoi.createWikiDocument(), > >> true); > >> > > > > Did you install the default template "templatexe"? > > > > > >> } catch (XWikiException e) { > >> e.printStackTrace(); > >> } > >> System.out.println("_____________********* " +ctx); > >> System.out.println("_____________"+ctx); > >> return "Hello " + myresourcename; > >> } > >> } > >> > >> Above code is not working. Virtual xwiki is not being created using the > >> API. > >> > > > > You should share the stack trace of the exception that is thrown. > > > > Thanks, > > Eduard > > > > > >> It is very urgent. Please help. > >> > >> Thanks > >> Karamjit. > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

2 6

[xwiki-devs] [Proposal] Technical Spaces + Application Spaces
by Vincent Massol 04 Aug '11

04 Aug '11

Hi devs, I'd like to propose 2 small changes that should make a huge difference for our users. 1) Introduce the notion of technical spaces The idea is that in WebPreferences for a space we should have a boolean property mentioning if the space is a technical space or not. This will allow to: * Remove the blacklistedspaces variable * List only non technical spaces for simple users 2) Introduce the notion of Application spaces The idea is that in WebPreferences for a space we should have a boolean property mentioning if the space is an application space or not. This will allow to: * Replace the Quick Links Panel with an Applications Panel listing all spaces that are application spaces * Only list Content spaces in the Spaces Gadget in the Dashboard * Add the ability for extensions to declare new applications that automatically appear in the Applications Panel I'd also like to suggest adding a global admin preferences to quickly select all spaces that are application and/or technical spaces (imagine a list of all spaces with 2 checkboxes for each space listed). This makes it very easy for the admin to reconfigure what are application spaces (thus showing in the app panel) and what spaces should be hidden for simple users. Of course modifying these would modify the WebPreferences of the said spaces. In addition to make this autodiscoverable I'd suggest that for admins the Application Panel should have a link to this admin feature. Something like "Configure Applications...". WDYT? Thanks -Vincent PS: I'm very excited about these 2 ideas since they're simple and IMO will make XE much easier to use and understand for people starting to use it.

9 14

[xwiki-devs] Status: XWiki Android Client
by Chamika Weerasinghe 03 Aug '11

03 Aug '11

Hi, Since xwiki isn't handling json POST request I've modified all my source code to work with xml using simple-xml library(Andriod friendly library). Earlier I used json deserilizer as gson. I've created separate module for gson as the xwiki data model. Now I've created another module for simple-xml. Should I remove gson module and replace it with simple-xml module? or keep both modules. (gson module is no longer used for my project). *New xwiki-android-component was developed for adding and viewing comments. sources aren't pushed to repo yet since above module decision. This week plan Following components will be developed this week. * View/Upload page attachments. - Viewing is limited to Android native viewers(Image Viewer, Video Player, Web Browser for text etc.). Native file selectors are used for selecting files to upload. * Add search component Best Regards, Chamika Weerasinghe

3 2

[xwiki-devs] [VOTE] Create twitter account for xwiki.org and use it to tweet releases
by Vincent Massol 03 Aug '11

03 Aug '11

Hi devs, I'd like to propose to create a twitter account for xwiki.org. The idea at first is to use it to announce new releases as part of the release process. More specifically to tweet a link to the blog post we write on xwiki.org at each release. Here's my +1 (I'll do it if we agree) Thanks -Vincent

10 9

[xwiki-devs] @Intermittent annotation to debug flickering tests
by Vincent Massol 03 Aug '11

03 Aug '11

Hi devs, FYI I've added a bullet point about debug flickering tests by running several times in a row at http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HSelenium2-basedFrame… Thanks -Vincent

1 0

extra inkomen � 2731 per maand
by sergiu＠xwiki.org 03 Aug '11

03 Aug '11

Een groot Europees bedrijf is op zoek naar de kandidaten voor beschikbare vacatures. U zult zonder geldinvesteringen en met minimaal tijdsverlies het geld kunnen verdienen. Wij zullen een opleiding voor u geven; zelfs tijdens de opleidingsperiode zult u al beginnen het geld te verdienen. Deelname aan de opleiding zal niet voor je hoofdactiviteiten lastig vallen. Wanneer U gennteresseerd bent - stuur uw resum op ons e-mail: job(a)sprytex-it.org

1 0

[xwiki-devs] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 3.0.1 released
by Sergiu Dumitriu 03 Aug '11

03 Aug '11

The XWiki development team is proud to announce the release of XWiki Enterprise 3.0.1. This is the first (and probably last) bugfix release for the 3.0 series, with 37 issues closed on top of 3.0. Backported from the 3.1 branch, two new features found their way into this release: the possibility to export a wiki document into an office format using a running OpenOffice/LibreOffice installation, and the new UI for customizing the PDF export. More details in the full release notes, at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Since this is a bugfix release on an older branch, the Download page doesn't list the new binaries, but you can download them directly from the OW2 Forge download page: http://forge.ow2.org/project/showfiles.php?group_id=170 -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0