Hi,
Some comments:
* I don't think the Import space name is a good one for the office
importer. I'd rather not create a new space and move the 2 pages in
the XWiki space (my preference right now, otherwise users will be able
to edit the pages by default unless we provide a WebPreferences and it
makes securing the wiki harder) or use something like OfficeImporter
(less good IMO).
* Navigating to the Importer page shows error messages. I think that
page should not be shown and be hidden so that users don't navigate to
it. It could also be moved to the XWiki space for now.
* We need a link from the top menu. It think that should be real quick
to add for 1.8M1
* it's a little buggy right now but I have commented why in the jira
issue: http://jira.xwiki.org/jira/browse/XWIKI-3083
WDYT?
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
On Sat, Jan 10, 2009 at 4:45 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
> tmortagne (SVN) wrote:
>
>> Added: platform/core/branches/xwiki-core-1.7/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/DefaultAttachement.java
>> ===================================================================
>> --- platform/core/branches/xwiki-core-1.7/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/DefaultAttachement.java (rev 0)
>> +++ platform/core/branches/xwiki-core-1.7/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/DefaultAttachement.java 2008-12-27 15:58:45 UTC (rev 14929)
>> @@ -0,0 +1,69 @@
>> +/*
>> + * See the NOTICE file distributed with this work for additional
>> + * information regarding copyright ownership.
>> + *
>> + * This is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU Lesser General Public License as
>> + * published by the Free Software Foundation; either version 2.1 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This software is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with this software; if not, write to the Free
>> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>> + * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>> + */
>> +package org.xwiki.rendering.listener;
>> +
>> +/**
>> + * Default implementation of {@link Attachment}.
>> + *
>> + * @version $Id$
>> + * @since 1.7.1
>> + */
>> +public class DefaultAttachement implements Attachment
>> +{
>> + /**
>> + * The name of the document containing the attachment.
>> + */
>> + private String documentName;
>> +
>> + /**
>> + * The name of the attachment.
>> + */
>> + private String attachmentName;
>> +
>> + /**
>> + * @param documentName the name of the document containing the attachment.
>> + * @param attachmentName the name of the attachment.
>> + */
>> + public DefaultAttachement(String documentName, String attachmentName)
>> + {
>> + this.documentName = documentName;
>> + this.attachmentName = attachmentName;
>> + }
>> +
>> + /**
>> + * {@inheritDoc}
>> + *
>> + * @see org.xwiki.rendering.listener.Attachment#getDocumentName()
>> + */
>> + public String getDocumentName()
>> + {
>> + return this.documentName;
>> + }
>> +
>> + /**
>> + * {@inheritDoc}
>> + *
>> + * @see org.xwiki.rendering.listener.Attachment#getAttachmentName()
>> + */
>> + public String getAttachmentName()
>> + {
>> + return this.attachmentName;
>> + }
>> +}
>
> Shouldn't this one be in an internal package, like the
> DefaultAttachmentParser?
DefaultAttachement is not a component so you need to know it to be
able to use it and it's more the default implementation anyone could
use to represent an attachment. It's here as a toolkit and not just
the implementation used by DefaultAttachmentParser.
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
tmortagne (SVN) wrote:
> Added: platform/core/branches/xwiki-core-1.7/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/DefaultAttachement.java
> ===================================================================
> --- platform/core/branches/xwiki-core-1.7/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/DefaultAttachement.java (rev 0)
> +++ platform/core/branches/xwiki-core-1.7/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/DefaultAttachement.java 2008-12-27 15:58:45 UTC (rev 14929)
> @@ -0,0 +1,69 @@
> +/*
> + * See the NOTICE file distributed with this work for additional
> + * information regarding copyright ownership.
> + *
> + * This is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU Lesser General Public License as
> + * published by the Free Software Foundation; either version 2.1 of
> + * the License, or (at your option) any later version.
> + *
> + * This software is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this software; if not, write to the Free
> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
> + */
> +package org.xwiki.rendering.listener;
> +
> +/**
> + * Default implementation of {@link Attachment}.
> + *
> + * @version $Id$
> + * @since 1.7.1
> + */
> +public class DefaultAttachement implements Attachment
> +{
> + /**
> + * The name of the document containing the attachment.
> + */
> + private String documentName;
> +
> + /**
> + * The name of the attachment.
> + */
> + private String attachmentName;
> +
> + /**
> + * @param documentName the name of the document containing the attachment.
> + * @param attachmentName the name of the attachment.
> + */
> + public DefaultAttachement(String documentName, String attachmentName)
> + {
> + this.documentName = documentName;
> + this.attachmentName = attachmentName;
> + }
> +
> + /**
> + * {@inheritDoc}
> + *
> + * @see org.xwiki.rendering.listener.Attachment#getDocumentName()
> + */
> + public String getDocumentName()
> + {
> + return this.documentName;
> + }
> +
> + /**
> + * {@inheritDoc}
> + *
> + * @see org.xwiki.rendering.listener.Attachment#getAttachmentName()
> + */
> + public String getAttachmentName()
> + {
> + return this.attachmentName;
> + }
> +}
Shouldn't this one be in an internal package, like the
DefaultAttachmentParser?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes
used only for this purpose. So I would prefer to to add it directly in
xwiki-core-rendering module, plus I don't like to have anything about
xwiki 1.0 in the core-rendering module.
But if we have XWiki 1.0 parser in it's own module, it would be
cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering
- xwiki-core-rendering-api
- xwiki-core-rendering-macros
- xwiki-core-rendering-macro-toc
- ...
- xwiki-core-rendering-parsers
- xwiki-core-rendering-parser-xwiki10
- xwiki-core-rendering-parser-wikimodel
- xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the
context of making xwiki rendering framework an independent open source
project latter. And better sooner than latter.
Here is my +1.
--
Thomas Mortagne
To implement the wiki configuration source in the configuration
component, we need to retrieve the list of properties of the
XWiki.XWikiPreferences class.
For this, I would like to add the following method in the
DocumentAccessBridge :
List<String> getPropertyNames(String className) throws Exception;
My +1,
Jerome
Hi,
We need to decide if we want to keep the "\\" syntax since now
newlines are significant.
There are two use cases I can see:
1) If we want to allow users to enter empty paragraphs (using \\):
some para
\\
still the same para
another para
2) Using \\ in scripts
For example:
#set ($var = "hello\\world")
$var
note that a possibility is to use the following which is less nice IMO:
#set ($var = "hello${xwiki.nl}world")
So here's my +1 to keep "\\" syntax.
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi,
I'm
trying to embed the Wiki in a portal application. When editing a Wiki
page, the
Wiki takes over the browser window, which is not wanted. is there some
option
to turn off fullscreen editing in the normal Wiki editor? Or do I need
to change
the skin for that?
Thanks,
J.L.Simon
The signature would be :
public String getXWikiPreference(String prefname, String fallback_param,
String default_value);
The underlaying method already exists in the non API XWiki.java (was
added for http://jira.xwiki.org/jira/browse/XWIKI-2569).
What this method exactly do is : "Obtain a preference value for the
wiki, looking up first in the XWiki.XWikiPreferences document, then
fallbacking on a config parameter when the first lookup gives an empty
string, then returning the default value if the config parameter
returned itself an empty string."
My +1:
+1
Jerome.
PS: I've created a JIRA for it: http://jira.xwiki.org/jira/browse/XWIKI-3086
In the following screenshot (XE 1.6.1), I've had hard time to understand
what those fields are dedicated to... (Fields "anonymous/registered"
repeated three times in a row)Thanks for your help...
manickaraj wrote:
>
> Hey guys,
>
> I am trying to run the XWiki 1.6 stable version in Tomcat
> 6.0.18 on Windows2000 m/c.
> For that I've done setup for MySQL DB. I included "mysqlconnector" jar in
> place. But when I start the server it started well, but while hitting the
> xwiki url "http://localhost:8080/appname" it gives the following error.
>
> message
>
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
>
> exception
>
> javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number
> 3 in 0: Could not initialize main XWiki context
> Wrapped Exception: Unable to build interceptor chain
>
> 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:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>
> com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94)
>
> com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287)
>
> 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: Unable to build interceptor chain
> com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:325)
> com.xpn.xwiki.XWiki.getXWiki(XWiki.java:386)
> com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:135)
> com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
>
> 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:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>
> com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94)
>
> com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287)
>
> com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
>
> note The full stack trace of the root cause is available in the Apache
> Tomcat/6.0.18 logs.
>
>
> Please Note : I checked the same setup for XWiki1.5.war. It works.
>
> I am using windows 2000 for XWiki 1.6
>
> It seems really odd to me.. and stuck with this.. Please help anybody
>
>
> Thanks in advance
>
Hi!
I'm sorry this is not a reply but a case of similar nature
I am getting a similar exception :Unable to build interceptor chain
but with jboss
I just installed XWiki enterprise on my system
Thats all i did
When some of my friends seem to get the Homepage via MyWiki shortcut, i get
an exception
Here are the logs:
org.jboss.cache.config.ConfigurationException: Unable to build interceptor
chain
at
org.jboss.cache.factories.InterceptorChainFactory.construct(Intercept
orChainFactory.java:136)
at
org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(Comp
onentRegistry.java:284)
at
org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(Com
ponentRegistry.java:245)
at
org.jboss.cache.factories.ComponentRegistry$Component.injectDependenc
ies(ComponentRegistry.java:911)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:221)
at
org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.jav
a:129)
at
org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory
.java:115)
at
org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.j
ava:94)
at
org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.j
ava:79)
at
org.xwiki.cache.jbosscache.internal.JBossCacheCache.initialize(JBossC
acheCache.java:101)
at
org.xwiki.cache.jbosscache.internal.JBossCacheCacheFactory.newCache(J
BossCacheCacheFactory.java:78)
at
com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:99
)
at
com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:84
)
at
com.xpn.xwiki.store.XWikiCacheStore.<init>(XWikiCacheStore.java:64)
at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:679)
at com.xpn.xwiki.XWiki.<init>(XWiki.java:655)
at com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:315)
at com.xpn.xwiki.XWiki.getXWiki(XWiki.java:386)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:135)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
at
org.apache.struts.action.RequestProcessor.processActionPerform(Reques
tProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.ja
va:236)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:119
6)
at
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428
)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:830)
at
com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(Convers
ionFilter.java:94)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:821)
at
com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRes
torerFilter.java:287)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:821)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEnc
odingFilter.java:112)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati
onHandler.java:471)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5
68)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication
Context.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
at org.mortbay.http.HttpServer.service(HttpServer.java:954)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:
244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Caused by: java.lang.TypeNotPresentException: Type
net.jcip.annotations.ThreadSa
fe not present
at
sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(Core
ReflectionFactory.java:98)
at
sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.
java:107)
at
sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignatur
e.java:31)
at
sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.jav
a:351)
at
sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationPar
ser.java:175)
at
sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationP
arser.java:69)
at
sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationPa
rser.java:52)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:2998)
at java.lang.Class.getAnnotation(Class.java:2958)
at java.lang.Class.isAnnotationPresent(Class.java:2970)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:218)
at
org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(Comp
onentRegistry.java:291)
at
org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(Com
ponentRegistry.java:245)
at
org.jboss.cache.factories.ComponentRegistry$Component.injectDependenc
ies(ComponentRegistry.java:911)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:221)
at
org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(Comp
onentRegistry.java:291)
at
org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(Com
ponentRegistry.java:245)
at
org.jboss.cache.factories.ComponentRegistry$Component.injectDependenc
ies(ComponentRegistry.java:911)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:221)
at
org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(Comp
onentRegistry.java:291)
at
org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(Com
ponentRegistry.java:245)
at
org.jboss.cache.factories.ComponentRegistry$Component.injectDependenc
ies(ComponentRegistry.java:911)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:221)
at
org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(Comp
onentRegistry.java:291)
at
org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(Com
ponentRegistry.java:245)
at
org.jboss.cache.factories.ComponentRegistry$Component.injectDependenc
ies(ComponentRegistry.java:911)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:221)
at
org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(Comp
onentRegistry.java:291)
at
org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(Com
ponentRegistry.java:245)
at
org.jboss.cache.factories.ComponentRegistry$Component.injectDependenc
ies(ComponentRegistry.java:911)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:221)
at
org.jboss.cache.factories.ComponentRegistry.getOrCreateComponent(Comp
onentRegistry.java:291)
at
org.jboss.cache.factories.ComponentRegistry.invokeInjectionMethod(Com
ponentRegistry.java:245)
at
org.jboss.cache.factories.ComponentRegistry$Component.injectDependenc
ies(ComponentRegistry.java:911)
at
org.jboss.cache.factories.ComponentRegistry.registerComponent(Compone
ntRegistry.java:221)
at
org.jboss.cache.factories.InterceptorChainFactory.createInterceptor(I
nterceptorChainFactory.java:41)
at
org.jboss.cache.factories.InterceptorChainFactory.buildInterceptorCha
in(InterceptorChainFactory.java:56)
at
org.jboss.cache.factories.InterceptorChainFactory.construct(Intercept
orChainFactory.java:132)
... 45 more
Caused by: java.lang.ClassNotFoundException: net.jcip.annotations.ThreadSafe
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:239)
at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:193)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at
sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(Core
ReflectionFactory.java:95)
... 82 more
Can someone please help me on this?
Thanks
--
View this message in context: http://n2.nabble.com/XWikiException-Unable-to-build-interceptor-chain-tp131…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Devs,
We plan to include office importer functionality for 1.8M1 release and for
that we need to move the respective projects to trunk.
I propose the following locations for the projects:
1. xwiki-core-officeimporter
This is the core officeimporter component and it's currently in
/sandbox/xwiki-officeimporter/
proposed location : /platform/core/trunk/xwiki-officeimporter
2. xwiki-application-officeimporter
The front-end application for officeimporter, currently under
/sandbox/xwiki-application-officeimporter/
proposed location : /platform/xwiki-applications/trunk/officeimporter
3. xwiki-enterprise-tests-officeimporter
Functional tests for officeimporter, currently under
/sandbox/officeimporter-tests/
proposed location :
/enterprise/trunk/distribution-test/officeimporter-tests/
Here's my +1 for all of above.
Thanks.
- Asiri
Hi,
I'm writing an indexer plugin for XWiki and recently found a problem
when trying to obtain the external document url:
java.lang.NullPointerException
at com.xpn.xwiki.XWiki.getServletPath(XWiki.java:4317)
at
com
.xpn
.xwiki
.web.XWikiServletURLFactory.addServletPath(XWikiServletURLFactory.java:
208)
at
com
.xpn
.xwiki
.web.XWikiServletURLFactory.createURL(XWikiServletURLFactory.java:178)
at
com
.xpn
.xwiki
.web
.XWikiServletURLFactory.createExternalURL(XWikiServletURLFactory.java:
273)
at com.xpn.xwiki.doc.XWikiDocument.getExternalURL(XWikiDocument.java:
925)
at
com
.kontrast
.vodafone
.portal
.xwiki.plugins.indexer.IndexUpdater.runMainLoop(IndexUpdater.java:180)
at
com
.kontrast
.vodafone
.portal.xwiki.plugins.indexer.IndexUpdater.run(IndexUpdater.java:116)
I updated to XWiki version 1.7-SNAPSHOT recently. Before that I didn't
experience this. Can anyone shed some light on this?
Thanks,
J.L.Simon
To test... and fix hacks we had to introduce to see if they can now be
removed.
-Vincent
Begin forwarded message:
> From: John Casey <jdcasey(a)apache.org>
> Date: January 5, 2009 9:25:04 PM CEST
> To: announce(a)maven.apache.org, Maven Users List <users(a)maven.apache.org
> >
> Subject: [ANN] Maven Assembly Plugin 2.2-beta-3 Released
> Reply-To: "Maven Users List" <users(a)maven.apache.org>
>
> The Maven team is pleased to announce the release of the Maven
> Assembly Plugin, version 2.2-beta-3
>
> This plugin is used to create custom archives using the build
> output, dependencies, and other files owned by a Maven project. You
> can find more information, including instructions and examples, at:
>
> http://maven.apache.org/plugins/maven-assembly-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <version>2.2-beta-3</version>
> </plugin>
>
>
> Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-3
>
> ** Sub-task
> * [MASSEMBLY-361] - Fix MASSEMBLY-285 default behaviour to be the
> correct behaviour
>
> ** Bug
> * [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file
> mode nor uid/gid
> * [MASSEMBLY-165] - Test error on Windows XP + Cygwin
> * [MASSEMBLY-190] - Problem with dependency conflict resolution
> on multi-module project
> * [MASSEMBLY-196] - use of repository assembly is no longer working
> * [MASSEMBLY-201] - classifier not included in name of dependency
> set
> * [MASSEMBLY-211] - assembly plugin and jar plugin disagree about
> whether to use uniqueVersion snapshot names
> * [MASSEMBLY-213] - jar-with-dependencies and signed jars issue
> again
> * [MASSEMBLY-217] - <outputFileNameMapping> needs to report
> collision.
> * [MASSEMBLY-230] - <fileset> not filtering resources, but
> <files> does filter
> * [MASSEMBLY-236] - assembly:assembly resolves excluded artifacts
> * [MASSEMBLY-237] - lineEnding ignored in a child project
> * [MASSEMBLY-238] - Assembly plugin removes file permissions
> * [MASSEMBLY-241] - Multiple includes in dependencySet
> * [MASSEMBLY-242] - transitive dependencies do not get included
> * [MASSEMBLY-245] - Manifest Section configuration does not work
> properly
> * [MASSEMBLY-251] - NullPointer wehn using scope system in a
> dependencySet
> * [MASSEMBLY-256] - Regression: pom properties are no longer
> expanded in descriptor.
> * [MASSEMBLY-264] - Filtering in Assembly Generates Blank Files
> in the Archive
> * [MASSEMBLY-270] - Assembly does not resolved managed
> dependencies correctly
> * [MASSEMBLY-280] - Regression: Dependency resolution for
> dependencySets does broken things
> * [MASSEMBLY-284] - regression: line ending setting is not honoured
> * [MASSEMBLY-285] - regression: duplicate files added to the
> assembly
> * [MASSEMBLY-287] - Unable to pass -DskipAssembly=true through
> the command line to skip the assembly plugin.
> * [MASSEMBLY-291] - attach the resulting assembly not working as
> expected
> * [MASSEMBLY-293] - <fileSets> not filtered in multimodule build,
> but <files> are
> * [MASSEMBLY-294] - Regression - dependency is skipped?
> * [MASSEMBLY-297] - Assembly broke on GNU/Linux -
> NullPointerException
> * [MASSEMBLY-298] - Includes/Excludes within <unpackOptions> are
> ignored
> * [MASSEMBLY-300] - Regression: outputFileNameMapping variable
> resolution
> * [MASSEMBLY-301] - assembly:attach wrongly renames/overwrites
> assemblies to the primary artifact
> * [MASSEMBLY-302] - Maven assembly plugin should use plexus-
> archiver version
> * [MASSEMBLY-306] - Dependency resolution fails with an NPE for a
> provided dependency with a fixed version
> * [MASSEMBLY-308] - Syntax Problem in Example Doco
> * [MASSEMBLY-309] - outputFileNameMapping fails and includes
> parent's name
> * [MASSEMBLY-312] - outputFileNameMapping not respected when the
> unpack=true
> * [MASSEMBLY-314] - Multiple inclusion of dependencies in binary
> assembly
> * [MASSEMBLY-318] - Example to attach assembly to package incorrect
> * [MASSEMBLY-319] - Cannot bind to lifecycle with multiple modules
> * [MASSEMBLY-322] - Filtering in filesets in multimodule build
> does not work
> * [MASSEMBLY-328] - When assembly is attached to pom with
> appendAssemblyId disabled, it won't be installed or deployed
> * [MASSEMBLY-331] - assembly descriptor doesn't seem to property
> substitute properties
> * [MASSEMBLY-340] - Filtering doesn't work for multimodule
> assembly builds
> * [MASSEMBLY-341] - Fat JAR assemblies may result in JARs with
> duplicate files
> * [MASSEMBLY-342] - NPE when filtering fileSet
> * [MASSEMBLY-345] - a"ppxml attribute is required" error when
> making ears with the assembly plugin
> * [MASSEMBLY-351] - ${project.xxxx} is not interpolated in the
> descriptor
> * [MASSEMBLY-354] - useTransitiveFiltering does NOT include
> artifacts whose dependency trail matches one of the include patterns
> when it has wildcards
> * [MASSEMBLY-355] - I get duplicate files in my "-jar-with-
> dependencies.jar"
> * [MASSEMBLY-375] - Leading slash in Windows when including one
> file in archive.
>
> ** Improvement
> * [MASSEMBLY-76] - [assembly plugin] improve or clarify
> inheriting/reusing descriptors
> * [MASSEMBLY-159] - Add FAQ about building multi-module
> assemblies from the top using Maven 2.0
> * [MASSEMBLY-216] - archive element in assembly descriptor
> * [MASSEMBLY-239] - In format dir, be able to create a dir
> without the suffix .dir
> * [MASSEMBLY-366] - DependencySet info message should be changed
> to debug level
>
>
>
> Enjoy,
>
> -The Maven team
Would be better next time to have a jira issue associated with commits
like this one, especially since you're changing something visible to
the user. Didn't you open a jira issue already when you made those
changes to DefaultDocumentAccessBridge earlier on?
BTW shouldn't this be i18ned? Are we doing that for other save messages?
Thanks
-Vincent
On Jan 7, 2009, at 7:28 AM, asiri (SVN) wrote:
> Author: asiri
> Date: 2009-01-07 07:28:11 +0100 (Wed, 07 Jan 2009)
> New Revision: 15118
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java
> Log:
> Addressing review comments.
>
> * Improced javadoc comemnts.
> * Added an editComments when changing document syntaxId
> * Prevented re-saving the XWikiDocument after calling
> doc.saveAttachmentContent()
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> doc/DefaultDocumentAccessBridge.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java 2009-01-06 23:15:02 UTC (rev 15117)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java 2009-01-07 06:28:11 UTC (rev 15118)
> @@ -116,8 +116,10 @@
> {
> XWikiContext xcontext = getContext();
> XWikiDocument doc =
> xcontext.getWiki().getDocument(documentName, xcontext);
> + String oldSyntaxId = doc.getSyntaxId();
> doc.setSyntaxId(syntaxId);
> - xcontext.getWiki().saveDocument(doc, xcontext);
> + xcontext.getWiki().saveDocument(doc,
> + String.format("Changed document syntax from [%s] to
> [%s].", oldSyntaxId, syntaxId), xcontext);
> }
>
> /**
> @@ -241,8 +243,6 @@
> attachment.setAuthor(xcontext.getUser());
> attachment.setDoc(doc);
> doc.saveAttachmentContent(attachment, xcontext);
> - xcontext.getWiki().saveDocument(doc,
> - String.format("Added attachment [%s].",
> AttachmentName), xcontext);
> }
>
> /**
> @@ -326,6 +326,8 @@
> }
>
> /**
> + * Utility method for checking access rights of the current
> user on a target document.
> + *
> * @param documentName The name of the document.
> * @param right Access right requested.
> * @return True if the current user has the given access right,
> false otherwise.
Hi there,
I've just noticed that we have the following in distribution-test/
pom.xml:
<!-- Used only in xml-rpc tests -->
<property>
<name>pathToXWikiXar</name>
<value>com/xpn/xwiki/products/xwiki-enterprise-wiki/$
{pom.version}/xwiki-enterprise-wiki-${pom.version}.xar</value>
</property>
I don't think this is in the right place. It should be in the the
XMLRPC test's pom.xml file.
Fabio could you look into this?
Thanks
-Vincent
On Jan 6, 2009, at 5:05 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2009-01-06 17:05:57 +0100 (Tue, 06 Jan 2009)
> New Revision: 15098
>
> Modified:
> platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/xpn/
> xwiki/wysiwyg/client/plugin/table/TablePlugin.java
> Log:
> XWIKI-3068 : Builtin firefox table features (add row, add col)
> messes up tables in the WYSIWYG
>
> Fixed by disabling builtin firefox table features. Merged from trunk.
>
>
>
> Modified: platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/
> com/xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java
> ===================================================================
> --- platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/
> xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java 2009-01-06
> 16:02:23 UTC (rev 15097)
> +++ platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/
> xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java 2009-01-06
> 16:05:57 UTC (rev 15098)
> @@ -85,6 +85,10 @@
> addFeature(rta, new InsertColAfter(this));
> addFeature(rta, new DeleteCol(this));
> addFeature(rta, new DeleteTable(this));
> +
> + // Disable the standard table editing features of Firefox.
> + // See XWIKI-3068 for more info.
I don't think we should put JIRA references in our code and not for
describing a solution. Rationale: we can move to another issue tracker
in the future, the issue can be moved/deleted/replace, etc.
It's better to have all the information in the source file IMO.
>
> + rta.getDocument().execCommand("enableInlineTableEditing",
> "false");
>
> getUIExtensionList().add(toolBarExtension);
> }
Thanks
-Vincent
http://xwiki.comhttp://massol.nethttp://xwiki.org