Hi,
I have installed the xwiki.war complete all the intructions for Tomcat
Servlet and MySQL Database configuration. But my xwiki is not working
properly ,its giving me the following error.
I have installed the enterprise version of xwiki war. I have gone throught
the forum to see if anyone's got a similar error , but looks like its just
me, just in case if i have missed this error posted by some user and if
there was a solution posted earlier, please point me to that link.
Here is the exception what i get
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Error number 3 in 0: Could not initialize
main XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from
param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Hibernate Dialect must be explicitly set
org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
root cause
com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main
XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from
param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Hibernate Dialect must be explicitly set
com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:328)
com.xpn.xwiki.XWiki.getXWiki(XWiki.java:515)
com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
note The full stack trace of the root cause is available in the Tomcat logs.
ANd i have installed JDK 1.5.
Can please let help me out with this error.
Thanks,
Nishii
--
View this message in context: http://n2.nabble.com/Could-not-initialize-main-XWiki-context-tp534219p53421…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
I would like to release a first version of XWord, but in order to do
that we need to move it out of the sandbox.
Here is what I propose:
* Rename XWord to XOffice since we want to address other Office
applications in the future;
* Move the code in svn to https://svn.xwiki.org/svnroot/xwiki/xoffice
* Rename the jira project to XOFFICE
* Create http://xoffice.xwiki.org
* in the future we should try to integrate msbuild with our hudson
server, to have XOffice under countinuous integration
* release XOffice - version 1.0 M1
Here is my +1
Hi,
We need to allow users to write macros using Velocity and still use
the same mechanism as the new rendering. Basically this means
transforming velocity macros into Rendering Macros. Once this is done
then the velocity macro will be able to be used as standard Rendering
Macros, they'll appear in the new WYSIWYG, etc.
Here's a proposal for doing so:
* Split xwiki-velocity/ module into 2
- xwiki-velocity-engine/ (the one currently in xwiki-velocity)
- xwiki-velocity-macro/ (the new one)
* In xwiki-velocity-macro create a VelocityMacroManager class that
does the following:
- initialize itself at xwiki startup
- create a VelocityMacroClass definition in the wiki if it doesn't
exist
- query the wiki for all objects of type VelocityMacroClass
- for each of them register them dynamically (we can already do
this) as a Rendering Macro
* The VelocityMacroClass has several fields:
- macro name, parameter names, parameters description, macro
description, usage example, velocity content to execute (the macro
content)
* The VelocityMacroManager register itself against the Observation
component to receive notifications whenever a VelocityMacroClass is
modified (added, removed, etc)
* Users will then be able to add velocity macros by simply creating a
new page, adding the VelocityMacroClass in it, fill the values.
* We should also provide a VelocityMacroClassSheet so that the macro
page containing the VelocityMacroClass can display the help for the
macro (self-standing)
The nice thing is that this keeps velocity macro handling in the xwiki-
velocity/ module and makes it completely optional (i.e. the wiki will
still work and there's no ties with this feature elsewhere).
WDYT?
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi devs,
Currently when a document is saved it is rendered with a custom
URLFactory to catch links.
IMO this is wrong because:
- it's impossible to really support generated links since the document
is renderer with a specific context in a specific time etc...
- it could makes saving document real slow if the document contains
big scripts which should not have to worry about that kind of very
crappy rendering
I understand it was easier to do this that way for 1.0 since it was
difficult to parse the document content to find links but the new
rendering does not have this issue anymore. It's now very easy to get
the XDOM and all the links it contains.
So I propose to only take the links found in XDOM before the transformation.
Here is my +1
Thanks,
--
Thomas Mortagne
Hi,
I present myself because I have the intention to participate to the dev of
xwiki.
I hope xwiki give me a multi-user platform. I construct a swing application
with formulaires which modifiates some web pages. My concepts of "content",
"forms" and so on are close xwiki.
My competences are all commons stufs about web, all commons stufs
about net, spring, jdbc, jcr (jackrabbit), swing, freemarker (a little
velocity, but I prefer freemarker), xml, a little j2me, etc.
I work with netbeans, ant, maven, junit, linux (mandriva).
I am in Saint Etienne, France. I work in my very little company (myself, it's
all), and the customers are the ultimate immediate chiefs. I dispose of one or
two hours by days for xwiki.
I suppose the best to begin is to install sources and solve some simple
bugs ?...
(and sorry for my english)
Arvind Gupta (arvind.bernaulli(a)gmail.com) wants to share their location
with you on Google Latitude. You need to sign in to Latitude with a Google
Account (eg @googlemail.com) and invite Arvind Gupta. To get started, or to
learn more about Latitude, click the link below.
http://m.google.com/latitude
(c) 2009 Google Inc., 1600 Amphitheathre Parkway, Mountain View, CA, USA.
Terms of Service | Privacy Policy
Hi devs,
I'm currently doing some experiments about the wiki explorer and I've
started to play with smartGWT.
My initial plan was to use the new REST APIs to populate the wiki
explorer tree, the root node would have called /rest/wikis, wiki nodes
would have called /rest/wikis/WIKI/spaces, and so on. Unfortunately it
is currently impossible to use multiple sources (REST in our case) to
populate smartGWT TreeGrid, there are experiments in the field but
this is not yet supported [1]. Note that using a single DataSource
works like a charm but as far as I understand it is not designed to
lazily load bunch of items after bunch of items from the server (they
are lazily parsed/rendered though), in our case it means that we'd
have to build a huge XML file describing all the resources in the
wikis to feed the wiki explorer; of course this is not an option.
Here are the options I'm currently evaluating:
1) Continue with smart(client/GWT) and extend smartGWT TreeGrid to be
able to use multiple DataSource (if doable).
2) Develop a dynamic tree on top of GWT Tree widget and:
a) use the GWT XWikiService to populate the tree (need new methods,
doesn't take advantage of REST operations).
b) use restlet GWT REST client [2] to populate the tree from our
REST services.
c) use sonatype GWT REST client [3] to populate the tree from our
REST services.
[1]: http://forums.smartclient.com/showthread.php?t=3181
[2]: http://wiki.restlet.org/docs_1.1/13-restlet/144-restlet.html
[3]: http://svn.sonatype.org/nexus/trunk/sandbox/nexus-gwt-ui/sonatype-gwt-rest/
Thanks,
JV.
Arvind Gupta (arvind.bernaulli(a)gmail.com) wants to share their location
with you on Google Latitude. You need to sign in to Latitude with a Google
Account (eg @googlemail.com) and invite Arvind Gupta. To get started, or to
learn more about Latitude, click the link below.
http://m.google.com/latitude
(c) 2009 Google Inc., 1600 Amphitheathre Parkway, Mountain View, CA, USA.
Terms of Service | Privacy Policy
Maybe we could move to RC3?
-Vincent
Begin forwarded message:
> From: Guillaume Laforge <glaforge(a)gmail.com>
> Date: February 9, 2009 2:54:57 PM CEST
> To: Groovy User <user(a)groovy.codehaus.org>, dev <dev(a)groovy.codehaus.org
> >, announce(a)groovy.codehaus.org, Grails Users <user(a)grails.codehaus.org
> >, Gant_Users <user(a)gant.codehaus.org>
> Subject: [ossgtp] Groovy 1.6-RC-3 is released,
> Reply-To: ossgtp(a)yahoogroups.com
>
> Hi all,
>
> A quick message to tell you we've just released our third release
> candidate for Groovy 1.6.
>
> Hopefully this will be the last one, unless we uncover anything
> critical.
> But that's where YOU can help, by testing this RC thouroughly and
> report anything odd you may find.
> Thanks in advance for your help.
>
> You can download Groovy 1.6-RC-3 at the usual place:
> http://groovy.codehaus.org/Download
>
> You can see the list of JIRA issues fixed since the last RC here:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10242&fi…
>
> The Jars will soon hit the Maven repositories -- but are already
> available on the Codehaus repository.
>
> Big thanks to all the developers and contributors for your hard work!
>
> --
> Guillaume Laforge