Hi,
When exporting the page into PDF displaying the following error.
How can solve this issue..?
org.dom4j.DocumentException: Error on line -1 of document : Premature end
of file. Nested exception: Premature end of file.
at org.dom4j.io.SAXReader.read(SAXReader.java:482)
at
com.xpn.xwiki.pdf.impl.PdfExportImpl.applyCSS(PdfExportImpl.java:332)
at
com.xpn.xwiki.pdf.impl.PdfExportImpl.applyCSS(PdfExportImpl.java:293)
at
com.xpn.xwiki.pdf.impl.PdfExportImpl.exportHtml(PdfExportImpl.java:202)
at
com.xpn.xwiki.pdf.impl.PdfExportImpl.export(PdfExportImpl.java:225)
at
com.xpn.xwiki.web.ExportAction.exportPDFOrRTF(ExportAction.java:198)
at com.xpn.xwiki.web.ExportAction.render(ExportAction.java:61)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:189)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Nested exception:
--
Prathap
Greetings
I finally completed my knowledge base. I separate the information in pages, and organize it by subject and
knowledge base. To do that I tag every page with a subject tag and a knowledge tag always started with "KB-".
If I want one page pesent in two knowledge bases I only nedd to tag it with the tags.
I send the example for you to see and say if it's worthy of being in the XWiki Code Zone?
Best regards
Bruno Neves
Hi,
I'd like to give the rights for the wikimodel project to reuse our
LocalEntityResolver class even though xwiki is under the LGPL 2.1
license and wikimodel under the Apache 2.0 license.
This is to fix http://code.google.com/p/wikimodel/issues/detail?id=37
I guess we need agreement from all contributors to this class. I guess
the main authors are Ludovic and myself.
So here's my +1
Thanks
-Vincent
Hi,
I just finished the implementation of full OpenID support for XWiki (see
http://jira.xwiki.org/jira/browse/XWIKI-2630). You can now create an user
account without password by using a OpenID from Yahoo, AOL, MyOpenID or any
other OpenID provider out there.
The other feature is that every XWiki user now gets a OpenID that he can use
on other OpenID sites to create an account without the need for yet another
username and password.
More infos about OpenID can be found on the official site:
http://www.openid.net/
Please test my work as much as you can. Thanks a lot
Have a nice weekend,
Markus
Hi,
We need to decide if we want our component implementations (the class
implementing the interface of a component) to be user-public or not.
By user-public I mean allowing user of the code to use them (for
composition, for inheritance). The alternative is to make them
internal and forbid users to import them. This means moving them to an
internal package (see http://www.eclipse.org/articles/
article.php?file=Article-API-Use/index.html) and telling
our users that they change anytime so they shouldn't use them. This
would also mean we wouldn't have to go through a deprecation stage to
make any change to our components.
My initial reaction to this was that they should be public but the
more I think about it the more I think making them internal might be
the best choice.
WDYT?
Thanks
-Vincent
Hi all,
I spent some time on completing ApplicationResources and replacing hard
coded messages in templates and would like now to discuss some issues
regarding translations.
In my opinion, the bundles became large, unclear, use different syntax rules
(sometimes simple keys, sometimes with prefixes and underscores, sometimes
built like node-structure...) and it’s difficult to find out if some of them
are not in use anymore and if some are missing.
I agree with http://jira.xwiki.org/jira/browse/XWIKI-918 - we need to clean
up the ApplicationResources and I think we could restructure/reorganize
resources files using nodes-structure and separate first of all separate XE
from other applications (in my opinion, every application should have its
own bundles – that would allow to manage translations easily) – just create
new AppRes with the clear-defined structure.
Perhaps there are the better solutions, but I find even the splitting inside
XE on xwiki-web (templates) and xwiki-wiki (default xar) would be already
helpful for insert the new keys and removing the wasted ones.
WDYT?
Best Regards,
Alla
--
View this message in context: http://n2.nabble.com/Internationalization-and-Localization-tp789607p789607.…
Sent from the XWiki- Dev mailing list archive at Nabble.com.