xwiki-users January 2012

xwiki-users@xwiki.org

48 participants
125 discussions

by Richard Rafalski

Hi, i played a litle bit with the new release 3.4 and debian on virtual machines. First i tried out the standalone installation on the testing distribution wheezy. The installation works well. But the page 'Administration: Rights' does not show the users and the groups. Did not investigate the situation further. Instead tried to install form the debian package xwiki-enterprise-tomcat-pgsql. Here got the error 'depends on libpg-java (>= 8.4) [UNAVAILABLE]'. Should XWiki run on wheezy at all? So I changed to the stable distribution squeeze. The installation of the deb package xwiki-enterprise-tomcat-pgsql works well here (did not try the standalone installation anymore). The Wiki is also runing well, with one exception: The browser shows a message box with the text 'Server returned TRANSPORT_ERROR with no error message' somtimes. But all seems to be ok. So far my feedback. The issues with the testing distribution are no problem for me. Feel confortable enough with the stable distribution but would like to get rid of the above-mentioned errer messages. Any ideas how to solve this. Thanks Ritchi

12 years, 9 months

[xwiki-users] debian installer

by Legeinfo

Is there more information for the xwiki debian installer out there? Volker -- View this message in context: http://xwiki.475771.n2.nabble.com/debian-installer-tp7110261p7110261.html Sent from the XWiki- Users mailing list archive at Nabble.com.

12 years, 9 months

[xwiki-users] State of the XWiki Community

by Sergiu Dumitriu

Hi Community, The following message expresses my personal opinions as a member of the community, so it might not be entirely accurate. The goal is to start a discussion about how can we attract more contributors and committers to the XWiki open source project, and will address three main subjects: - the current state of the community and committers - the possibility of joining or creating a non-profit foundation to govern XWiki - the possibility of using Fundry as a way for users to fund XWiki development ----- Status of the community At the start of a new year, it's time to look a bit at the status of XWiki, the project and the community. XWiki was created by Ludovic Dubost as an open source project from the start. Later, he founded a commercial company (XWiki SAS, back then XPertNet SaRL) as a way to financially support the development of the product. It kept the project entirely open, unlike the many false open source companies that only offer a basic open source version, forcing people to buy the commercial one (the open core model), or that only release the source code while still doing behind-the-curtains development, or that almost completely ignore the outside community. See the XWiki SAS values: http://purl.org/xwiki/sas-values and manifesto: http://purl.org/xwiki/sas-manifesto The committers, elected for their merit, and not made automatically as employees of the company, always tried to maintain a healthy community and attract new contributors/committers. Thus, the XWiki software is developed not by the XWiki SAS company, but by the XWiki community. http://dev.xwiki.org/xwiki/bin/Community/ has a lot of information about the community, and the development process. As of January 2011, there are 16 core committers, 12 of which are XWiki SAS employees, and 3 are or were related to XWiki SAS one way or another. http://dev.xwiki.org/xwiki/bin/Community/HallOfFame#HCoreCommitters A big part of the development is aided by non-committer members of the community, either by providing patches, testing and reporting bugs, requesting new features, providing feedback, answering on the mailing lists, etc. As committers, we tried to listen to the community when developing the project, but as paid employees we have to also listen to the company requirements. With a limited manpower it's very hard to evolve as fast as the community would want, or in all the directions that the community wants. And we welcome any help here. The project is healthy, we have regular and frequent releases, with visible progress with each new release (see Vincent's statistics on http://massol.myxwiki.org/xwiki/bin/Blog/XWikiIn2010 for more details). Still, I'm a little disappointed with the development speed. Lately, out of the 16 committers on average about 3-4 are actually available for platform development during a day. * How can we help speed up the growth of the community? * How can we attract more developers outside XWiki SAS? ----- Joining/forming a free software foundation One possible reason while so few people are willing to become committers could be that XWiki SAS might appear to over-control the software, and a clear non-profit foundation on top of XWiki might make it more obvious that XWiki is a true open source project, and anybody is welcome to join. XWiki SAS is a member of the OW2 consortium http://ow2.org/ , and this membership also extends a bit to the XWiki project. OW2 used to host all our infrastructure, SVN, mailing lists, downloads... Currently only the official downloads linked from the main download page are hosted on OW2 servers, as we've gradually moved parts of the development infrastructure on servers provided by XWiki SAS. While OW2 is a great home for XWiki SAS, it's mostly a company consortium, not a software development foundation. The most development help coming from OW2 consists of research projects involving both OW2 and XWiki SAS, thus the OW2 membership doesn't bring much value when it comes to code. One option is to form an XWiki non-profit Foundation, which will govern all XWiki-related software development. The main disadvantage would be that there's a risk that it won't make any difference at all, while adding the burden of more paperwork. This is where your opinion comes into play, since there's no point in doing all the hard work if the community doesn't see a clear benefit in it. The Apache Foundation has the huge disadvantage that it requires a license change, but it's a very well known home for software development, with good visibility. The Software Freedom Conservancy has been getting a lot of press recently, since several high profile projects joined it. It's got a few top-notch projects under its hood, so XWiki would be among well known projects in there. A smaller, compatible alternative is Codehaus, but I'm not convinced they would make a difference with respect to our needs. Other foundations aren't really suited for XWiki, since they either don't bring value to the community because they don't foster inter-project collaboration (SourceForge, Google Code), or don't match the project goals (FSF, GNU, Eclipse, Linux, Mozilla...). So, some questions in regard to this subject: * Is there anybody that would like contribute more / become a committer? * Do users believe that a foundation on top of XWiki will help attract more developers? Please note that this is not THE discussion about which foundation to join, just trying to see if there is a benefit in doing so. ----- Supporting code development Becoming a committer requires time, and few people can spend that time when there's no direct benefit involved. XWiki SAS employees are already being paid to work with XWiki, so they can contribute to the platform because the company benefits directly from their work. Employees of other companies that deal with XWiki do spend time contributing, but very few actually got to hang around enough to be voted as committers, although many came close, but stopped short of it. One way of supporting code development is to contact XWiki SAS and sign a contract to develop one or more features with a higher priority. An alternative, which allows to share the cost with other companies/individuals, is to collaboratively request and support feature development (crowdfunding), for example through Fundry, a new site especially designed for this. I've set up an account for XWiki at https://fundry.com/project/58-xwiki . This is also a good place to donate to the XWiki project, since there are no visible ways to financially support the project. Fundry would allow to gather financial incentives for non-employees to contribute more code, thus involving the community more in the direction the software evolves, and attracting more potential contributors. * Do you (the community) think this is a good idea and it would help? * Would you be willing to contribute/donate to the project? ----- Please provide us with your feedback, so we can advance on these topics. Thanks, -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 10 months

[xwiki-users] XWiki Enterprise and XWiki Enterprise Manager 3.4 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4. XWiki Enterprise 3.4 is a stabilization release as we're approaching the end of the 3.x cycle so its main goal was to improve the Extension Manager and App Within Minutes features. However, this release also comes with a new look and a new default wiki page syntax. The highlights of this release are: * New color themes * XWiki 2.1 is the default page syntax * Improved Extension Manager UI * Delete space menu * Simple space templates * Special characters in attachment file names * Minimized action menu * Display macro See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

12 years, 10 months

[xwiki-users] Video inserting

by Alexander Adema

Hey, this is my first post and i hope to nothing wrong. I know that ther is a macro for linking up a video in xwiki-sides from other sources like youtube or something else. But how can i put my own video (.avi, .mpeg, etc.) on a wiki side by using the attachment selection? I've tried to put it with some html-code with <embed... but that won't work. Thanks for your help!!! Alex -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

12 years, 10 months

[xwiki-users] Background color for a livetable

by Stéphanie

Hello everyone, I have a livetable build like every livetable : #livetable("allapps" $collist $ colprops $options) My livetable is build using a class and one of the field of this class is "state". This field can have three value : "new", "in progress", "closed". I want to put a background color for each line depending of this field "state". I want the background colors like this : - "new" -> background color = green - "in progress" -> background color = orange - "closed" -> background color = red Is there a possibility to define this somewhere ? And if yes, where exactly ? In the options of my livetable ? I hope this possibility exists because I really need it. Have a good day, Stéphanie -- View this message in context: http://xwiki.475771.n2.nabble.com/Background-color-for-a-livetable-tp721965… Sent from the XWiki- Users mailing list archive at Nabble.com.

12 years, 10 months

Re: [xwiki-users] Workspace manager free default pages set + "new idea"

by Haru Mamburu

Hi Eduard, Thanks for explnation. I'm very happy to issue a "new idea", but idea itself is a bit wider and deeper, then described below. I would like to point out some reasons and effects to be more clear before "jiraing" it :-) "Security leak" XE/XEM Usecase XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of workspaces. To be more real we'd add Wiki Manager and tens of virtual wikis running on the same engine (something like XWiki.com running) As my humble experience shows, nearly never in natural way XWiki would have only one User with Admin Rights on the Wiki level. It's human to be all the time in a hurry and meanwhile XWiki becomes messy inside. It's not the big problem yet. :-) As an Admin User on wiki level, I can easily gain programming rights. For now, it's completely uncontrolled and will run unnoticed. So, let's imagine that all stars in solar system lined up in a bad way and one Admin became an AngryAdmin with a revenge as a primary goal of life. Let's make it even worth: AngryAdmin knows XWiki quite good and scripting for him is an open book. To make it more real: AngryAdmin doesn't have root access to the server. :-) At this stage he has all necessary knowledge and access rights to ruin ALL WIKIs onboard. I didn't dig much in it, but if Workspace Manager has appropriate tools, then it's possible: one short script and it's over :-) I didn't met such occasions before, but heard a lot of similar usecases (not with XWiki :-) Thus, I NEVER run production on MAIN wiki! It looks dangerous for me. I'd better be paranoic admin rather embarrased admin. If somebody will become an "angry-beaver-admin", he would be able to ruin only one space (now he has a front-end tool for this :-)) or more, but only inside one project and all running wikis will stay alive. Such workflow keeps my paranoia quiet :-) SO, at last "new idea": escape MAIN WIKI from production completely. As only global users has programming rights, it looks very logic to leave Main Wiki to "Core and instances" management and keep it safe from local admins. When U have a lot of users it sounds reasonable for me. Let's return to our Case 1-3 described below. The most flexible solution looks as following: | virtual wiki 1 -> workspaces | virtual wiki 2 -> workspaces -> workspaces (probably) Main Wiki | .................................................. | virtual wiki N - "Solo" - No Workspace Manager onboard (administration) (production) Such a way we can run everything simultaneously on the same server. No need to run a lot of instances. If someone want's programming rights, he could be isolated locally and won't affect other wikis. Looks safe for me. Bad news: - Nobody, besides MySQL users would be happy, XEM is MySQL dependent still :-( So, before I'd "jira" an idea, I'd like to know community opinion to keep it comprehensive. Hope, it would be nice idea for 4.0 roadmap to think over :-) Best Regards, Dmitry 28 января 2012, 00:53 от Eduard Moraru <enygma2002(a)gmail.com>: Hello again, Please see below... On Fri, Jan 27, 2012 at 3:17 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Thanks a lot for clarification. It makes sence now from explained point of view, but I still can't get WHY as global user on NON-workspace wiki I should see Workspace Manager menus? As I tried to explain in my previous mail, the idea is that you are a global user, coming from a global context (the main wiki). In that global context, you have the Workspace application installed and available for you to use. This means that, the Workspace application offers you the possibility to create a new workspace, jump to the main wiki or view existing workspaces trough the top-menu. From the Workspace application's point of view, it is only natural to allow you to perform these actions, regardless of your current location (that means even if you are viewing a non-workspace subwiki). As long as the Workspace application is installed, it will perform as designed :) Anyhow I can't use Workspace Manager INSIDE virtual Wiki. It makes sence if you would extend Workspace manager and make it completely independent on each and every virtual wiki. So, the main reason why: it's just useles inside virtual wiki (for now) Again, the extra menus are not about what you can do on the current wiki, but they are about what you can do on the whole XWiki, since this is a feature that spans cross wikis and is not restricted to an individual wiki (even if it is installed on the main wiki). For me, e.g., ideal workflow looks like: Case 1. XEM -> virtual wiki isolated, no Workspace Manager on board This is perfectly doable right now. If you think about the reasons for which you are creating a regular subwiki and not a workspace, you`ll notice that the main one is that you want local users. But since local users do not see any extra menus, you are good to go. Only you, as a global user (or admin) will see those menus, but that is just because the main wiki is offering you this possibility (since you are its member). Case 2. XEM -> virtual wiki isolated, WITH Workspace Manager on board. Each virtual wiki in this case will be able to produce it's own workspaces isolated from each other (like independent projects on the same server). Only Local Users can take part in workspace management. As you might already know, XWiki currently supports only *one level* of virtualisation and only one main wiki. You can not currently create a subwiki within a subwiki, not even with the WikiManager application. This means that you can not do this with Workspaces either. If you wish to obtain this scenario, you will have to set up multiple instances of XWiki. Having a subwiki within another subwiki might be an interesting new feature for the WikiManager application (and for Workspaces too). Please feel free to add a new feature request on jira.xwiki.org for the WikiManager component. Case 3. XEM -> virtual wiki isolated + Workspace manager on board. Same as Case 2, but Local Users can log once in any virtual/workspace wiki they allowed AND via this login have access to each and every wiki they registered/invited. If I understand correctly, this usecase would imply that local users (created in regular subwikis or, specifically for your case, in subwikis of subwikis) have a mechanism that allows them to escape from the isolation of the current subwiki of which they are part of and gain access to other subwikis or workspaces. Maybe you could do this by promoting the local user as a global user, optionally putting him in a special group to better manage rights. This way he/she can create/join workspaces and join other wikis. For current purposes I would prefer Case 1 behaviour. Soon I'd like to use Case 2 then 3 scenario, but for now - no way :-( Hope it would be useful for futher development. Yes, as I said, having subwikis within subwikis is a good idea that might actually be not so hard to implement (as far as Thomas tells me). Hope this helped. Thanks, Eduard Kind Regards, Dmitry 27 января 2012, 16:48 от Eduard Moraru <enygma2002(a)gmail.com>: Oh, I see now. The way it works now when visiting a normal subwiki (not a workspace) is that: 1) If you are a global user (user of the main wiki), the menus will be displayed to you (and you will be thus exposed to the global context of which you are part of). 2) If you are a local user (user of a subwiki that is part of a wiki *farm*), you don`t see the menus any more and are isolated inside the wiki (and not exposed to the global context). So, as a conclusion, the menus appear to you based on your user type and not on the type of wiki you are currently viewing. Does that make sense now? Does this fit your usecase? If not, can you please elaborate on the reason why you would like global users not to be able to see the global context when viewing a regular subwiki? Thanks, Eduard On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Thank you Eduard, Sorry, probably I wasn't clear in my questions... - I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. - BUT, the same time I want to use WIKI Manager to have completely independent from main wiki and other workspaces virtual wikis. So, I set up XEM, installed Workspace manager to play around AND with Wiki Manager created virtual Wiki. Now I completely stuck how to get rid of all Workspace Manager links in wiki farm (!) (not workspaces). I would prefer to keep running Workspace Manager on main Wiki AND Wiki farm simultaneously, if possible. Is there any simple solution? The only thing I suppose should work is to take *.vm files from XE and attach them to the skin file. Looks wierd and unpredictable for me :-( Kind Regards, Dmitry 27 января 2012, 14:26 от Eduard Moraru <enygma2002(a)gmail.com>: Hi Dmitry, Starting with 3.3, XEM has moved the main usecase for subwikis from farm to workspaces. This means that, additionally to the WikiManager application [1], now XEM also contains the Workspace Application [2]. The encouraged way of for creating a wiki farm right now (if that is really what you need) is to get XE, install WikiManager [1] and create your farm. If you *insist* on using XEM for creating a wiki farm, all you have to do is delete the WorkspaceManager space, thus removing the Workspaces application and disabling the extra menus that were getting in your way. Additionally, you should also remove the xwiki-platform-workspace-api-<version>.jar file from the /webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and you have removed the UI. However, if your plan is to have global users that work on different subwikis (like an intranet with departments mapped to subwikis or a place where you work on projects mapped to subwikis, etc.), you might reconsider using Workspaces. In any case, I hope this solves your problem. Thanks, Eduard ----------------- References: [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Applicati… [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu <haru_mamburu(a)mail.ru>: > Hi All, > > By accident I found a soluion. For me it looks a bit wierd. > > If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. > > For now, if I want to use usepath and don't want to use Workspace Manager, there is no an "one click solution" :-( > > Is it a bug or it's a feature? Should I report it? > > Kind regards, > > Dmitry > > 27 января 2012, 01:34 от Haru Mamburu <haru_mamburu(a)mail.ru>: > > Hi. all! > > > > XEM 3.4. Main Wiki works fine. > > > > I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. > > > > What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? > > > > Kind regards, > > > > Dmitry _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

12 years, 10 months

[xwiki-users] Page title bugs when using objects in XE 3.4?

by Mark Wallace

Are these bugs in XE 3.4? When I create a new class and then objects of that class, the page title is the name of the class sheet, not the name I entered for the page (which is what I'd expect and what you'd see in earlier versions such as XE 3.1). I call this BUG 2 in the steps to reproduce, below. While we're at it, there is also what I call BUG 1 in the steps below, where it appears the name of the class does not show up in the "bread crumbs" trail (or whatever you call that) at the top of the page. Steps to reproduce: 1.Log in as Administrator 2.Go to /Data types/ page (http://localhost:8080/xwiki/bin/view/XWiki/XWikiClasses) 3.Enter class name /TitleTest/ and click /Create This Class/; (system shows an edit page) 4.Click /Save & View/; (system shows the class page) 5.Click on /class editor/ link; (system shows editing class page) 6.Enter property name /aString/ with type /String/ and click /ADD/ button 7.Click /Save & View/ 8.*BUG 1*: Note that at top of page, says Wiki Home >> XWiki Space >> Data Types >> (blank).Shouldn't there be the class name here?) 9.Click /Create the Document Sheet/ 10.Click /Bind the sheet to the class/ 11.Click /Create the Class Template/ 12.Click /Add a TitleTest object to the template/ 13.Under /Create a new document/, enter Document name /TestDoc1/ and click /Create this Document/ 14.Enter the value /some value/ for the /aString/ property and click /Save & View/ 15.*BUG 2*(?): Note that the largest text on the page is /TitleTestClass Sheet/ --shouldn't this be the page name we used to create the new document, the same name that is at the end of the URL (http://localhost:8080/xwiki/bin/view/Main/TestDoc1), which is TestDoc1?? 16.Click /Edit > Wiki/, and enter the title /TestDoc1/ and click /Save & View/. 17.Note that the largest text on the page still says /TitleTestClass Sheet/ --shouldn't this be the title we just entered?? -- Mark Wallace Principal Engineer, Semantic Applications Modus Operandi, Inc.

12 years, 10 months

Re: [xwiki-users] dafault DB name change

by Haru Mamburu

Here it is... Timestamp Jan 30, 2012 17:56:30.064 Log Level INFO Logger javax.enterprise.system.std.com.sun.enterprise.server.logging Name-Value Pairs _ThreadID=25;_ThreadName=Thread-2; Record Number 72 Message ID Complete Message 2012-01-30 17:56:30,064 [http://mydomain.com:8180/xwiki/bin/view/Main/] WARN c.x.x.XWiki - Exception while getting wiki preference [xwiki.plugin.activitystream.daystokeepevents] com.xpn.xwiki.XWikiException: Error number 3202 in 3: Exception while reading document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null]]]] Wrapped Exception: Error number 3301 in 3: Exception while switching to database xwiki Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' at com.xpn.xwiki.store.XWikiHibernateStore.loadXWikiDoc(XWikiHibernateStore.java:856) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.store.XWikiCacheStore.loadXWikiDoc(XWikiCacheStore.java:283) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getDocument(XWiki.java:1427) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getDocument(XWiki.java:1470) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getXWikiPreference(XWiki.java:2207) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.plugin.ActivityStreamPlugin.getActivityStreamPreference(ActivityStreamPlugin.java:111) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.impl.ActivityStreamCleaner.getNumberOfDaysToKeep(ActivityStreamCleaner.java:106) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.impl.ActivityStreamCleaner.init(ActivityStreamCleaner.java:215) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.impl.ActivityStreamImpl.init(ActivityStreamImpl.java:230) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.plugin.ActivityStreamPlugin.init(ActivityStreamPlugin.java:124) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.XWikiPluginManager.initPlugin(XWikiPluginManager.java:152) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.plugin.XWikiPluginManager.addPlugin(XWikiPluginManager.java:88) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.plugin.XWikiPluginManager.addPlugins(XWikiPluginManager.java:116) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.preparePlugins(XWiki.java:1111) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:792) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.<init>(XWiki.java:739) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:401) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getXWiki(XWiki.java:487) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:116) [xwiki-platform-legacy-oldcore-3.4.jar:na] at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) [struts-1.2.9.jar:1.2.9] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [javax.servlet.jar:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [javax.servlet.jar:na] at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:128) [xwiki-platform-legacy-oldcore-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:144) [xwiki-platform-wysiwyg-server-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) [xwiki-platform-webdav-server-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:217) [xwiki-platform-container-servlet-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) [xwiki-platform-container-servlet-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) [web-core.jar:3.1.1] at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98) [web-glue.jar:3.1.1] at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) [web-glue.jar:3.1.1] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) [web-core.jar:3.1.1] at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330) [web-core.jar:3.1.1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) [web-core.jar:3.1.1] at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) [kernel.jar:3.1.1] at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) [grizzly-http.jar:1.9.36] at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) [grizzly-http.jar:1.9.36] at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019) [grizzly-http.jar:1.9.36] at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) [grizzly-http.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) [grizzly-http.jar:1.9.36] at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.ContextTask.run(ContextTask.java:71) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) [grizzly-utils.jar:1.9.36] at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) [grizzly-utils.jar:1.9.36] at java.lang.Thread.run(Thread.java:662) [na:1.6.0_26] Caused by: com.xpn.xwiki.XWikiException: Error number 3301 in 3: Exception while switching to database xwiki Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' at com.xpn.xwiki.store.XWikiHibernateBaseStore.setDatabase(XWikiHibernateBaseStore.java:631) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.store.XWikiHibernateBaseStore.beginTransaction(XWikiHibernateBaseStore.java:767) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.store.XWikiHibernateStore.loadXWikiDoc(XWikiHibernateStore.java:731) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] ... 67 common frames omitted Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied for user 'test'@'localhost' to database 'xwiki' at sun.reflect.GeneratedConstructorAccessor162.newInstance(Unknown Source) ~[na:na] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_26] at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_26] at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.ConnectionImpl.setCatalog(ConnectionImpl.java:5086) ~[mysql-connector-java-5.1.18-bin.jar:na] at org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374) ~[commons-dbcp-1.3.jar:1.3] at org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374) ~[commons-dbcp-1.3.jar:1.3] at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setCatalog(PoolingDataSource.java:333) ~[commons-dbcp-1.3.jar:1.3] at sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_26] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_26] at org.hibernate.jdbc.BorrowedConnectionProxy.invoke(BorrowedConnectionProxy.java:74) ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] at $Proxy213.setCatalog(Unknown Source) ~[na:na] at com.xpn.xwiki.store.XWikiHibernateBaseStore.setDatabase(XWikiHibernateBaseStore.java:620) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] ... 69 common frames omitted 30 января 2012, 21:29 от Thomas Mortagne <thomas.mortagne(a)xwiki.com>: > On Mon, Jan 30, 2012 at 6:10 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: > > Yes, I did. :-( > > > > XEM 3.4 > > > > javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context > > Wrapped Exception: Error number 3202 in 3: Exception while reading document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null]]]] > > Wrapped Exception: Error number 3301 in 3: Exception while switching to database xwiki > > Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' > > Do you have more ? Would be nice to get the full stack trace. > > > > > And actually there is no DB xwiki in Mysql. Xwiki is completely right. > > The rest settings in xwiki.cfg are intact. > > > > Kind regards > > > > Dmitry > > > > PS. Sorry for the private mailing > >> > >> 30 января 2012, 20:46 от Thomas Mortagne <thomas.mortagne(a)xwiki.com>: > >> > On Mon, Jan 30, 2012 at 5:06 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: > >> > > Hi, All! > >> > > > >> > > Does anyone know, is it possible to change default DB name xwiki to smth else? > >> > > > >> > > I changed in config.cfg, > >> > > > >> > > xwiki.db=test > >> > > > >> > > in hibernate.cfg.xml > >> > > > >> > > <property name="connection.url">jdbc:mysql://localhost/test</property> > >> > > > >> > > After XWiki reload it tries to access xwiki db still. :-( > >> > > > >> > > What is correct way to do it? > >> > > >> > Well that's supposed to be the correct way actually. You sure you > >> > uncommented xwiki.db ? > >> > > >> > > > >> > > Thanks in advance, > >> > > > >> > > Dmitry > >> > > _______________________________________________ > >> > > users mailing list > >> > > users(a)xwiki.org > >> > > http://lists.xwiki.org/mailman/listinfo/users > >> > > >> > -- > >> > Thomas Mortagne > >> > > > _______________________________________________ > > users mailing list > > users(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > -- > Thomas Mortagne >

12 years, 10 months

[xwiki-users] [Poll] What features would you like to have in XWiki 4.x?

by Vincent Massol

Hi XWiki users, In 2009 we launched a survey on xwiki.org about features would like to have in XWiki in priority: http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2009 The results were published here: - http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results - http://www.xwiki.org/xwiki/bin/view/Blog/FeatureStatus20120119 The idea is to do that same with a new survey in order to give us some information to prepare our XWiki 4.x roadmaps. Thus it would help us a lot if you could go the following URL and answer the survey there: http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2012 Please answer as soon as possible since the earliest we get feedback the earliest we can start using it to decide what's put in the roadmaps! :) Results will be published on xwiki.org. Thanks -Vincent on behalf of the XWiki Committers

12 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-users January 2012