Re: [xwiki-users] Problems with installation on Tomcat6 & MySQL
On Thu, Jul 8, 2010 at 08:03, Igor Popov wrote: > Hi! > > I'm trying to install XWiki Enterprise 2.3.1 on Tomcat 6.0.20 with > MySQL 5.0.32 (installing as WAR). > I've deployed WAR, set up the database but when I connect to XWiki I > get the following exception trace: > (sorry if the message is big, but I'd better post the full trace) > > > > com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not > initialize main XWiki context > Wrapped Exception: Error number 3201 in 3: Exception while saving > document xwiki:XWiki.XWikiGroupTemplate > Wrapped Exception: Failed to commit or rollback transaction. Root cause [] > at com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:369) > at com.xpn.xwiki.XWiki.getXWiki(XWiki.java:430) > 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(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:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:129) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:152) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:304) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) > at java.lang.Thread.run(Thread.java:619) > > > Wrapped Exception: > > com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while > saving document xwiki:XWiki.XWikiGroupTemplate > Wrapped Exception: Failed to commit or rollback transaction. Root cause [] > at > com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:643) > at > com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:182) > at > com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:175) > at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1358) > at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1320) > at com.xpn.xwiki.XWiki.getGroupClass(XWiki.java:3239) > at com.xpn.xwiki.XWiki.initializeMandatoryClasses(XWiki.java:824) > at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:792) > at com.xpn.xwiki.XWiki.(XWiki.java:713) >
[xwiki-users] Problems with installation on Tomcat6 & MySQL
Hi! I'm trying to install XWiki Enterprise 2.3.1 on Tomcat 6.0.20 with MySQL 5.0.32 (installing as WAR). I've deployed WAR, set up the database but when I connect to XWiki I get the following exception trace: (sorry if the message is big, but I'd better post the full trace) com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3201 in 3: Exception while saving document xwiki:XWiki.XWikiGroupTemplate Wrapped Exception: Failed to commit or rollback transaction. Root cause [] at com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:369) at com.xpn.xwiki.XWiki.getXWiki(XWiki.java:430) 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(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:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:152) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:304) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) Wrapped Exception: com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document xwiki:XWiki.XWikiGroupTemplate Wrapped Exception: Failed to commit or rollback transaction. Root cause [] at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:643) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:182) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:175) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1358) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1320) at com.xpn.xwiki.XWiki.getGroupClass(XWiki.java:3239) at com.xpn.xwiki.XWiki.initializeMandatoryClasses(XWiki.java:824) at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:792) at com.xpn.xwiki.XWiki.(XWiki.java:713) at com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:350) at com.xpn.xwiki.XWiki.getXWiki(XWiki.java:430) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:135) at
[xwiki-users] Controlling not only contents but also page titles in class instances
Hello!
My experience with classes in XWiki is obtained after creating a Todo
application. The tutorial is published here:
http://www.theserverside.com/news/1363830/XWiki-A-Platform-for-Collaborative-Apps
It is obsoleted, but I've got the basics.
There is a class fabric at XWiki.XWikiClasses. It is straightforward to
create a Class, a Sheet and a Template using this fabric. Sheet is being
used to hold control over presentation of increasing number of class
instances and Template injects a reference to Sheet in new instances.
Everything is fine, but I don't understand how to hold control over page
titles. That is, if once in a blue moon I will want to change title
format from $doc.getObject('SomeSpace.SomeClass').get('SomeField') to
something different, every class instance must be affected (except those
ones which have their title edited manually).
My naive tries don't work as expected. Is it ever possible?
--
If you want to get to the top, you have to start at the bottom
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] {{html wiki="true"}}
On Wed, Jul 7, 2010 at 19:33, Ivan Levashew wrote: > Thomas Mortagne wrote: >>> The main issue is that wiki link syntax [[ ]] does not support enough >>> things which leads use to use html macro where we should not. See >> >> Forgot the link: http://jira.xwiki.org/jira/browse/XWIKI-3611 > > No, this is not a primary concern IMHO. At least, in places where I was > applying fixes the problem is wider. XWiki syntax lacks s, >
Re: [xwiki-users] {{html wiki="true"}}
Thomas Mortagne wrote: >> The main issue is that wiki link syntax [[ ]] does not support enough >> things which leads use to use html macro where we should not. See > > Forgot the link: http://jira.xwiki.org/jira/browse/XWIKI-3611 No, this is not a primary concern IMHO. At least, in places where I was applying fixes the problem is wider. XWiki syntax lacks s,
Re: [xwiki-users] {{html wiki="true"}}
On 07/07/2010 06:03 PM, Thomas Mortagne wrote:
> Yes there are (sadly common) bugs and feel free to report any one you can
> find.
>
> The main issue is that wiki link syntax [[ ]] does not support enough
> things which leads use to use html macro where we should not. See
>
> For the workaround, the easiest and most effective solutions currently are:
> 1) make sure you really need that "wiki=true"
> 2) make sure you can't write this link using wiki syntax
> 2) if you can't get rid of it put a sub {{html}} macro around the link like in
> {{html wiki=true}}
> * some list item with a {{html}} href="http://another.space.toom.su/";>link{{/html}}
> {{/html}}
You can also escape XWiki syntax special characters if you have access
to the source:
href="http:~/~/another.space.toom.su/"
Hope this helps,
Marius
>
> On Wed, Jul 7, 2010 at 16:52, Ivan Levashew wrote:
>> Ivan Levashew wrote:
>>> Does anybody had this idea before?
>>>
>>> I'd like to establish the mapping as follows:
>>>
>>> http://something.metrolace.ru/Page ->
>>>http://metrolace.ru/bin/view/Something/Page/
>>>
>>> http://something.another.metrolace.ru/ ->
>>>http://metrolace.ru/bin/view/SomethingAnother/WebHome/
>>>
>>> That is, the whole domain is a collaborative wiki with
>>> pretty short URLs. New domains are being created on demand
>>> because they are essentially good old Spaces.
>>>
>>> I'm going to use url_rewrite in Squid (in particular, because I
>>> don't know why it's so difficult to get rid of /bin/) and custom
>>> XWikiURLFactory implementation.
>>>
>>> Any advices? Did somebody already write custom URLFactory before?
>>>
>>
>> If anyone is wondering about this, it was almost enough to rewrite
>> ServletURLFactory.
>>
>> Bad news is that XWiki pages often misbehave when URLs are not relative.
>> This is due to {{html wiki="true"}} being commonly used everywhere.
>> Things like remains unchanged after applying wiki parser.
>> However,http://another.space.toom.su/";> gets messed because> href="http://another.space.toom.su/";> turns into> class="wikiexternallink">> href="http://another.space.toom.su/";>> class="wikigeneratedlinkcontent">http://another.space.toom.su/
>>
>> Another bad news is that tricks like
>> didn't work. They are also being changed by XWiki parser, this time it
>> creates tag which again messes everything.
>>
>> I've done my best to make most troublesome URLs relative. E. g. "get"
>> URLs are always relative due to AJAX crossdomain restrictions. Still
>> there are some dark corners where the problem can't be workarounded by
>> just tweaking my servlet URL factory implementation without completely
>> sacrificing multidomain illusion. This bug (it is, isn't it?) looks like
>> this:
>>
>> http://www.peeep.us/2aded8d0
>>
>> Should it be fixed?
>>
>> When I was fixing Main.Spaces I thought there should be something like
>> {{wiki}} or better in html mode. is better because
>> xmlescape encodes<> in Velocity output.
>>
>> Having both systems in effect is glitches-prone. Not having makes
>> proper introducing wiki fragments annoying. In the Main.Spaces wiki
>> engine is only used to reference WebHome of every space. I've got to put
>> {{html wiki="false"}} in several places instead of putting in
>> just one.
>>
>> --
>> If you want to get to the top, you have to start at the bottom
>>
>> ___
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>>
>
>
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] {{html wiki="true"}}
Yes there are (sadly common) bugs and feel free to report any one you can find.
The main issue is that wiki link syntax [[ ]] does not support enough
things which leads use to use html macro where we should not. See
For the workaround, the easiest and most effective solutions currently are:
1) make sure you really need that "wiki=true"
2) make sure you can't write this link using wiki syntax
2) if you can't get rid of it put a sub {{html}} macro around the link like in
{{html wiki=true}}
* some list item with a {{html}}http://another.space.toom.su/";>link{{/html}}
{{/html}}
On Wed, Jul 7, 2010 at 16:52, Ivan Levashew wrote:
> Ivan Levashew wrote:
>> Does anybody had this idea before?
>>
>> I'd like to establish the mapping as follows:
>>
>> http://something.metrolace.ru/Page ->
>> http://metrolace.ru/bin/view/Something/Page/
>>
>> http://something.another.metrolace.ru/ ->
>> http://metrolace.ru/bin/view/SomethingAnother/WebHome/
>>
>> That is, the whole domain is a collaborative wiki with
>> pretty short URLs. New domains are being created on demand
>> because they are essentially good old Spaces.
>>
>> I'm going to use url_rewrite in Squid (in particular, because I
>> don't know why it's so difficult to get rid of /bin/) and custom
>> XWikiURLFactory implementation.
>>
>> Any advices? Did somebody already write custom URLFactory before?
>>
>
> If anyone is wondering about this, it was almost enough to rewrite
> ServletURLFactory.
>
> Bad news is that XWiki pages often misbehave when URLs are not relative.
> This is due to {{html wiki="true"}} being commonly used everywhere.
> Things like remains unchanged after applying wiki parser.
> However, http://another.space.toom.su/";> gets messed because href="http://another.space.toom.su/";> turns into class="wikiexternallink"> href="http://another.space.toom.su/";> class="wikigeneratedlinkcontent">http://another.space.toom.su/
>
> Another bad news is that tricks like
> didn't work. They are also being changed by XWiki parser, this time it
> creates tag which again messes everything.
>
> I've done my best to make most troublesome URLs relative. E. g. "get"
> URLs are always relative due to AJAX crossdomain restrictions. Still
> there are some dark corners where the problem can't be workarounded by
> just tweaking my servlet URL factory implementation without completely
> sacrificing multidomain illusion. This bug (it is, isn't it?) looks like
> this:
>
> http://www.peeep.us/2aded8d0
>
> Should it be fixed?
>
> When I was fixing Main.Spaces I thought there should be something like
> {{wiki}} or better in html mode. is better because
> xmlescape encodes <> in Velocity output.
>
> Having both systems in effect is glitches-prone. Not having makes
> proper introducing wiki fragments annoying. In the Main.Spaces wiki
> engine is only used to reference WebHome of every space. I've got to put
> {{html wiki="false"}} in several places instead of putting in
> just one.
>
> --
> If you want to get to the top, you have to start at the bottom
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Thomas Mortagne
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] {{html wiki="true"}}
On Wed, Jul 7, 2010 at 17:04, Thomas Mortagne wrote:
> On Wed, Jul 7, 2010 at 17:03, Thomas Mortagne
> wrote:
>> Yes there are (sadly common) bugs and feel free to report any one you can
>> find.
>>
>> The main issue is that wiki link syntax [[ ]] does not support enough
>> things which leads use to use html macro where we should not. See
>
> Forgot the link: http://jira.xwiki.org/jira/browse/XWIKI-3611
>
>>
>> For the workaround, the easiest and most effective solutions currently are:
>> 1) make sure you really need that "wiki=true"
>> 2) make sure you can't write this link using wiki syntax
>> 2) if you can't get rid of it put a sub {{html}} macro around the link like
>> in
>> {{html wiki=true}}
>> * some list item with a {{html}}> href="http://another.space.toom.su/";>link{{/html}}
>> {{/html}}
It's obviously not a good example of the use of wiki=true in html
macro, it's just a simple sub html macro example ;)
>>
>> On Wed, Jul 7, 2010 at 16:52, Ivan Levashew
>> wrote:
>>> Ivan Levashew wrote:
Does anybody had this idea before?
I'd like to establish the mapping as follows:
http://something.metrolace.ru/Page ->
http://metrolace.ru/bin/view/Something/Page/
http://something.another.metrolace.ru/ ->
http://metrolace.ru/bin/view/SomethingAnother/WebHome/
That is, the whole domain is a collaborative wiki with
pretty short URLs. New domains are being created on demand
because they are essentially good old Spaces.
I'm going to use url_rewrite in Squid (in particular, because I
don't know why it's so difficult to get rid of /bin/) and custom
XWikiURLFactory implementation.
Any advices? Did somebody already write custom URLFactory before?
>>>
>>> If anyone is wondering about this, it was almost enough to rewrite
>>> ServletURLFactory.
>>>
>>> Bad news is that XWiki pages often misbehave when URLs are not relative.
>>> This is due to {{html wiki="true"}} being commonly used everywhere.
>>> Things like remains unchanged after applying wiki parser.
>>> However, http://another.space.toom.su/";> gets messed because >> href="http://another.space.toom.su/";> turns into >> class="wikiexternallink">>> href="http://another.space.toom.su/";>>> class="wikigeneratedlinkcontent">http://another.space.toom.su/
>>>
>>> Another bad news is that tricks like
>>> didn't work. They are also being changed by XWiki parser, this time it
>>> creates tag which again messes everything.
>>>
>>> I've done my best to make most troublesome URLs relative. E. g. "get"
>>> URLs are always relative due to AJAX crossdomain restrictions. Still
>>> there are some dark corners where the problem can't be workarounded by
>>> just tweaking my servlet URL factory implementation without completely
>>> sacrificing multidomain illusion. This bug (it is, isn't it?) looks like
>>> this:
>>>
>>> http://www.peeep.us/2aded8d0
>>>
>>> Should it be fixed?
>>>
>>> When I was fixing Main.Spaces I thought there should be something like
>>> {{wiki}} or better in html mode. is better because
>>> xmlescape encodes <> in Velocity output.
>>>
>>> Having both systems in effect is glitches-prone. Not having makes
>>> proper introducing wiki fragments annoying. In the Main.Spaces wiki
>>> engine is only used to reference WebHome of every space. I've got to put
>>> {{html wiki="false"}} in several places instead of putting in
>>> just one.
>>>
>>> --
>>> If you want to get to the top, you have to start at the bottom
>>>
>>> ___
>>> users mailing list
>>> users@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/users
>>>
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] {{html wiki="true"}}
On Wed, Jul 7, 2010 at 17:03, Thomas Mortagne wrote:
> Yes there are (sadly common) bugs and feel free to report any one you can
> find.
>
> The main issue is that wiki link syntax [[ ]] does not support enough
> things which leads use to use html macro where we should not. See
Forgot the link: http://jira.xwiki.org/jira/browse/XWIKI-3611
>
> For the workaround, the easiest and most effective solutions currently are:
> 1) make sure you really need that "wiki=true"
> 2) make sure you can't write this link using wiki syntax
> 2) if you can't get rid of it put a sub {{html}} macro around the link like in
> {{html wiki=true}}
> * some list item with a {{html}} href="http://another.space.toom.su/";>link{{/html}}
> {{/html}}
>
> On Wed, Jul 7, 2010 at 16:52, Ivan Levashew wrote:
>> Ivan Levashew wrote:
>>> Does anybody had this idea before?
>>>
>>> I'd like to establish the mapping as follows:
>>>
>>> http://something.metrolace.ru/Page ->
>>> http://metrolace.ru/bin/view/Something/Page/
>>>
>>> http://something.another.metrolace.ru/ ->
>>> http://metrolace.ru/bin/view/SomethingAnother/WebHome/
>>>
>>> That is, the whole domain is a collaborative wiki with
>>> pretty short URLs. New domains are being created on demand
>>> because they are essentially good old Spaces.
>>>
>>> I'm going to use url_rewrite in Squid (in particular, because I
>>> don't know why it's so difficult to get rid of /bin/) and custom
>>> XWikiURLFactory implementation.
>>>
>>> Any advices? Did somebody already write custom URLFactory before?
>>>
>>
>> If anyone is wondering about this, it was almost enough to rewrite
>> ServletURLFactory.
>>
>> Bad news is that XWiki pages often misbehave when URLs are not relative.
>> This is due to {{html wiki="true"}} being commonly used everywhere.
>> Things like remains unchanged after applying wiki parser.
>> However, http://another.space.toom.su/";> gets messed because > href="http://another.space.toom.su/";> turns into > class="wikiexternallink">> href="http://another.space.toom.su/";>> class="wikigeneratedlinkcontent">http://another.space.toom.su/
>>
>> Another bad news is that tricks like
>> didn't work. They are also being changed by XWiki parser, this time it
>> creates tag which again messes everything.
>>
>> I've done my best to make most troublesome URLs relative. E. g. "get"
>> URLs are always relative due to AJAX crossdomain restrictions. Still
>> there are some dark corners where the problem can't be workarounded by
>> just tweaking my servlet URL factory implementation without completely
>> sacrificing multidomain illusion. This bug (it is, isn't it?) looks like
>> this:
>>
>> http://www.peeep.us/2aded8d0
>>
>> Should it be fixed?
>>
>> When I was fixing Main.Spaces I thought there should be something like
>> {{wiki}} or better in html mode. is better because
>> xmlescape encodes <> in Velocity output.
>>
>> Having both systems in effect is glitches-prone. Not having makes
>> proper introducing wiki fragments annoying. In the Main.Spaces wiki
>> engine is only used to reference WebHome of every space. I've got to put
>> {{html wiki="false"}} in several places instead of putting in
>> just one.
>>
>> --
>> If you want to get to the top, you have to start at the bottom
>>
>> ___
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>>
>
>
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] {{html wiki="true"}}
Ivan Levashew wrote:
> Does anybody had this idea before?
>
> I'd like to establish the mapping as follows:
>
> http://something.metrolace.ru/Page ->
> http://metrolace.ru/bin/view/Something/Page/
>
> http://something.another.metrolace.ru/ ->
> http://metrolace.ru/bin/view/SomethingAnother/WebHome/
>
> That is, the whole domain is a collaborative wiki with
> pretty short URLs. New domains are being created on demand
> because they are essentially good old Spaces.
>
> I'm going to use url_rewrite in Squid (in particular, because I
> don't know why it's so difficult to get rid of /bin/) and custom
> XWikiURLFactory implementation.
>
> Any advices? Did somebody already write custom URLFactory before?
>
If anyone is wondering about this, it was almost enough to rewrite
ServletURLFactory.
Bad news is that XWiki pages often misbehave when URLs are not relative.
This is due to {{html wiki="true"}} being commonly used everywhere.
Things like remains unchanged after applying wiki parser.
However, http://another.space.toom.su/";> gets messed because http://another.space.toom.su/";> turns into http://another.space.toom.su/";>http://another.space.toom.su/
Another bad news is that tricks like
didn't work. They are also being changed by XWiki parser, this time it
creates tag which again messes everything.
I've done my best to make most troublesome URLs relative. E. g. "get"
URLs are always relative due to AJAX crossdomain restrictions. Still
there are some dark corners where the problem can't be workarounded by
just tweaking my servlet URL factory implementation without completely
sacrificing multidomain illusion. This bug (it is, isn't it?) looks like
this:
http://www.peeep.us/2aded8d0
Should it be fixed?
When I was fixing Main.Spaces I thought there should be something like
{{wiki}} or better in html mode. is better because
xmlescape encodes <> in Velocity output.
Having both systems in effect is glitches-prone. Not having makes
proper introducing wiki fragments annoying. In the Main.Spaces wiki
engine is only used to reference WebHome of every space. I've got to put
{{html wiki="false"}} in several places instead of putting in
just one.
--
If you want to get to the top, you have to start at the bottom
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Error when building new xwiki component
Hi Vincent, vmassol wrote: > > Yes it needs to be declared in a META-INF/components.txt file. > See the doc at > http://code.xwiki.org/xwiki/bin/view/Modules/ComponentModule > After some tries, I finally succeed to use the HelloWorld component with groovy and velocity in my wiki !! Like you said, I declared it in a META-INF/components.txt. I also added all the annotations as described in http://code.xwiki.org/xwiki/bin/view/Modules/ComponentModule (without being stupid and forgetting the "import org.xwiki.component.annotation.*;" !!). So, thank you Anca, Marius and Vincent for your help. -- View this message in context: http://xwiki.475771.n2.nabble.com/Error-when-building-new-xwiki-component-tp5259941p5265235.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Error when building new xwiki component
Hi Marine,
On Jul 7, 2010, at 11:50 AM, Marine Julian wrote:
>
> Hi Marius,
>
> Marius Dumitru Florea wrote:
>>
>> The required dependency should have been found at
>> http://maven.xwiki.org/releases/org/xwiki/platform/xwiki-core-component/2.3.1/
>>
>> but as you can see there's no jar there. The reason is that the
>> xwiki-core-component module was split in multiple submodules. You need
>> to edit you pom and change the dependency from xwiki-core-component to
>> xwiki-core-component-api like this:
>>
>>
>> org.xwiki.platform
>> xwiki-core-component-api
>> ${pom.version}
>>
>>
>
> You're totally right. In fact, I just replace "xwiki-core-component" by
> "xwiki-core-component-api" and the build succeeded. So, I finally can have
> my jar ! Thanks.
>
> Now, i'm facing that my component can't be caledl by groovy or velocity. I
> hope that you can help me again. My first thought was wondering if the
> component needs to be declared somewhere, but it seems not.
Yes it needs to be declared in a META-INF/components.txt file.
See the doc at
http://code.xwiki.org/xwiki/bin/view/Modules/ComponentModule
Thanks
-Vincent
>
> Neither
> {{groovy wiki="false"}}
> def greeter =
> com.xpn.xwiki.web.Utils.getComponent(org.xwiki.essai.component.HelloWorld.class);
> println greeter.sayHello();
> {{/groovy}}
> or
> {{velocity}} $greeter.sayHello(); {{/velocity}}
> works.
>
> The groovy code throws the following error :
> org.xwiki.rendering.macro.MacroExecutionException: Failed to evaluate Script
> Macro for content [def greeter =
> com.xpn.xwiki.web.Utils.getComponent(org.xwiki.essai.component.HelloWorld.class);
> println greeter.sayHello();]
>at
> org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluate(AbstractJSR223ScriptMacro.java:201)
>
>at
> org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluate(AbstractJSR223ScriptMacro.java:50)
>at
> org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:200)
>
>at
> org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.execute(AbstractJSR223ScriptMacro.java:137)
>
>at
> org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.execute(AbstractJSR223ScriptMacro.java:50)
>
>[...]
>at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
>at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
>at
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> Caused by: javax.script.ScriptException: javax.script.ScriptException:
> java.lang.RuntimeException: Failed to load component
> [org.xwiki.essai.component.HelloWorld] for hint [default]
>at
> org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:117)
>
>at
> org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.eval(AbstractJSR223ScriptMacro.java:260)
>
>at
> org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluate(AbstractJSR223ScriptMacro.java:191)
> ... 79 more
> Caused by: javax.script.ScriptException: java.lang.RuntimeException: Failed
> to load component [org.xwiki.essai.component.HelloWorld] for hint [default]
>at
> org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:317)
>
>at
> org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:111)
>
>... 81 more
> Caused by: java.lang.RuntimeException: Failed to load component
> [org.xwiki.essai.component.HelloWorld] for hint [default] at
> com.xpn.xwiki.web.Utils.getComponent(Utils.java:614)
>at com.xpn.xwiki.web.Utils.getComponent(Utils.java:635)
>at com.xpn.xwiki.web.Utils$getComponent.call(Unknown Source)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
>
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
>
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
>
>at Script7.run(Script7.groovy:1)
>at
> org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:314)
>... 82 more
> Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find
> descriptor for the component [role = [org.xwiki.essai.component.HelloWorld]
> hint = [default]]
>at
> org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:356)
>
>at
> org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109)
>
>at
> org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:85)
>
>at com.xpn.xwiki.web.Utils.getComponent(Utils.java:612)
>... 89 more
>
> What is the descriptor for the component ?
> Besides, like I know the tutorial outdated, I tried to modify the code of
> the component by adding annotations and a components.txt, but the build
> failed cause th
Re: [xwiki-users] Error when building new xwiki component
Hi Marius,
Marius Dumitru Florea wrote:
>
> The required dependency should have been found at
> http://maven.xwiki.org/releases/org/xwiki/platform/xwiki-core-component/2.3.1/
>
> but as you can see there's no jar there. The reason is that the
> xwiki-core-component module was split in multiple submodules. You need
> to edit you pom and change the dependency from xwiki-core-component to
> xwiki-core-component-api like this:
>
>
>org.xwiki.platform
>xwiki-core-component-api
>${pom.version}
>
>
You're totally right. In fact, I just replace "xwiki-core-component" by
"xwiki-core-component-api" and the build succeeded. So, I finally can have
my jar ! Thanks.
Now, i'm facing that my component can't be caledl by groovy or velocity. I
hope that you can help me again. My first thought was wondering if the
component needs to be declared somewhere, but it seems not.
Neither
{{groovy wiki="false"}}
def greeter =
com.xpn.xwiki.web.Utils.getComponent(org.xwiki.essai.component.HelloWorld.class);
println greeter.sayHello();
{{/groovy}}
or
{{velocity}} $greeter.sayHello(); {{/velocity}}
works.
The groovy code throws the following error :
org.xwiki.rendering.macro.MacroExecutionException: Failed to evaluate Script
Macro for content [def greeter =
com.xpn.xwiki.web.Utils.getComponent(org.xwiki.essai.component.HelloWorld.class);
println greeter.sayHello();]
at
org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluate(AbstractJSR223ScriptMacro.java:201)
at
org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluate(AbstractJSR223ScriptMacro.java:50)
at
org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:200)
at
org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.execute(AbstractJSR223ScriptMacro.java:137)
at
org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.execute(AbstractJSR223ScriptMacro.java:50)
[...]
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: javax.script.ScriptException: javax.script.ScriptException:
java.lang.RuntimeException: Failed to load component
[org.xwiki.essai.component.HelloWorld] for hint [default]
at
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:117)
at
org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.eval(AbstractJSR223ScriptMacro.java:260)
at
org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluate(AbstractJSR223ScriptMacro.java:191)
... 79 more
Caused by: javax.script.ScriptException: java.lang.RuntimeException: Failed
to load component [org.xwiki.essai.component.HelloWorld] for hint [default]
at
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:317)
at
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:111)
... 81 more
Caused by: java.lang.RuntimeException: Failed to load component
[org.xwiki.essai.component.HelloWorld] for hint [default] at
com.xpn.xwiki.web.Utils.getComponent(Utils.java:614)
at com.xpn.xwiki.web.Utils.getComponent(Utils.java:635)
at com.xpn.xwiki.web.Utils$getComponent.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at Script7.run(Script7.groovy:1)
at
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:314)
... 82 more
Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find
descriptor for the component [role = [org.xwiki.essai.component.HelloWorld]
hint = [default]]
at
org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:356)
at
org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109)
at
org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:85)
at com.xpn.xwiki.web.Utils.getComponent(Utils.java:612)
... 89 more
What is the descriptor for the component ?
Besides, like I know the tutorial outdated, I tried to modify the code of
the component by adding annotations and a components.txt, but the build
failed cause the annotations was unknown (at least, they seems to be
unknown).
Can anybody give me some ideas that I can use the HelloWorld component
through velocity in my xwiki pages ?
--
View this message in context:
http://xwiki.475771.n2.nabble.com/Error-when-building-new-xwiki-component-tp5259941p5264413.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
u
Re: [xwiki-users] Need clarity: programming rights
Ivan Levashew wrote: > Hello! > > I am thinking about the purpose of this extension: > > http://code.xwiki.org/xwiki/bin/view/Extensions/ProgrammingRightTestGreasemonkeyExtension > >> It is easy to forget and save pages with programming permission I wrote that extension because it is very easy and it isn't obvious. I wanted it so I could do auditing to make sure pages which didn't need PR didn't have it. > > It is not only easy but also unobvious. I don't understand how to turn > on and off programming privilledges on a particular Page. I guess, this > is per-page 'programming' right. Currently a user has PR and any page which they save is then a PR page. I use 2 usernames so I don't save anything with PR unless it needs it. There has been some discussion of making PR only exist for snippets which are cryptographically signed. With this change, non administrators will be able to avail themselves of PR code and it will decrease surprises. Caleb > It can't be set via Rights Management > UI but rights can be edited as object. However, I'm not sure. I'd like > someone experienced enough to describe and put some references here: > > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Access%20Rights > http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement > http://platform.xwiki.org/xwiki/bin/view/DevGuide/Scripting > http://code.xwiki.org/xwiki/bin/view/Extensions/ProgrammingRightTestGreasemonkeyExtension > > That's where I was looking for answers. > ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] colibri menu icons revised
+1, Raluca. On Wed, Jul 7, 2010 at 10:43 AM, Ciprian Amaritei wrote: > Hello. > As you probably noticed some of the colibri menu icons recently modified, > especially the ones which have white as a base color, doesn`t look nice at > all on a white background. That`s why I added a light gray border in order > to make them look nice on white bg. Here you can see the result: > http://incubator.myxwiki.org/xwiki/bin/view/Ciprian/Icons > You will notice that their aspect is also changed a little, for darker > backgrounds but it shouldn`t be that visually disturbing. They are still > 16x16 px. > If everyone agree I will make a patch with the new version. > > Thanks. > > -- > Ciprian, > Designer > XWiki > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] colibri menu icons revised
On Jul 7, 2010, at 9:43 AM, Ciprian Amaritei wrote: > Hello. > As you probably noticed some of the colibri menu icons recently modified, > especially the ones which have white as a base color, doesn`t look nice at > all on a white background. That`s why I added a light gray border in order > to make them look nice on white bg. Here you can see the result: > http://incubator.myxwiki.org/xwiki/bin/view/Ciprian/Icons > You will notice that their aspect is also changed a little, for darker > backgrounds but it shouldn`t be that visually disturbing. They are still > 16x16 px. > If everyone agree I will make a patch with the new version. +1 thanks Ciprian. -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] colibri menu icons revised
+1 On Wed, Jul 7, 2010 at 10:43, Ciprian Amaritei wrote: > Hello. > As you probably noticed some of the colibri menu icons recently modified, > especially the ones which have white as a base color, doesn`t look nice at > all on a white background. That`s why I added a light gray border in order > to make them look nice on white bg. Here you can see the result: > http://incubator.myxwiki.org/xwiki/bin/view/Ciprian/Icons > You will notice that their aspect is also changed a little, for darker > backgrounds but it shouldn`t be that visually disturbing. They are still > 16x16 px. > If everyone agree I will make a patch with the new version. > > Thanks. > > -- > Ciprian, > Designer > XWiki > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] state of xwiki concerto
On 07/07/2010 07:32 AM, Thomas Hoeschele wrote: > Hi, > > yeah but i thought the database would handle any conflicts, beside a read > only mode is enough for enterprise environment. It would allow employees to > access all the information needed offline, changes could be code only like > XEclipse, which get solved once online again. E.G. in the company I'm working > most of our handbooks, guidelines should get accessed through XWiki; often > employees go to meetings on buildings sites where there is no internet > connection, which means they have to access all the handbooks via filesystem, > which is slow as they need to scroll through a foldersystem with ~1000 guides. > I think here would be the real advantage of an offline XWiki. This could be done with offline browser storage (HTML5). > > >> Well this is not really enough, as this locks you in read-only mode. >> Concerto was meant to provide offline, but you need some additional code >> and storage on both the server and the client to run the replication >> model. >> The replication model is what guarantees solutions to conflicts.. >> >> Now conflict are very very rare when you look at the use cases, and a >> much simpler replication model which could fail on conflicts would be >> probably largely enough for most cases. >> >> Concerto is quite overkill for the simple replication scenario. The >> power of Concerto is P2P replication just using a relay network which >> does not store anything. But in this world this scenario does not have a >> big future. >> >> Ludovic >> This sounds kind of like Concerto also sharing the Advantages and the Disadvanges However, some mid way would be nice in future (the sooner the better) >> simple rendering and maybe search in XEclipse would be great. >>> Yes, XEclipse does need some love. We'll see. >>> >>> Thanks, >>> Eduard Regards -Ursprüngliche Nachricht- Von: users-boun...@xwiki.org [mailto:users-boun...@xwiki.org] Im >> Auftrag von Eduard Moraru Gesendet: Dienstag, 6. Juli 2010 16:46 An: users@xwiki.org Betreff: Re: [xwiki-users] state of xwiki concerto Hi, On 07/06/2010 04:07 PM, Thomas Hoeschele wrote: > Just jumping in here, as I have to ask this: is there any Possilibity >> to > Use XWiki Offline apart from Concerto? I consider this a crucial >> feature for a lot of enterprise where employees have to work outside or have no >> internet in meetings. > Btw, I thing something like XEclipse with Page preview would suffice. > > thank ! > > Well, XEclipse was originally part of the XWiki Concerto research project as well. AFAIK, there is currently no XWiki Offline standalone project. So there are basically 2 options for offline work with xwiki: Concerto and XEclipse. - Concerto involves having a local (in offline work context) xwiki installation that replicates completely or partially a remote xwiki. - Advantage: full featured XWiki experience. - Dissadvantage: big footprint, possibly instable due to current >> status. - XEclipse involves downloading a set of pages (or entire spaces) and working in an Eclipse environment. - Advantage: light, syntax highlighting, suggestions, etc. - Disadvantage: only wiki syntax mode is supported and partial rendering (since you don't have the wiki's entire contents with you). Both options synchronize with remote XWiki when internet is available. Hope this helps. Thanks, Eduard > Original-Nachricht > > >> Datum: Tue, 6 Jul 2010 09:06:41 +0100 >> Von: Ponder Muse >> An: XWiki Users >> Betreff: Re: [xwiki-users] state of xwiki concerto >> >> > >> Hi Eduard, >> >> >> >> >>> I have fixed the build issues and now Concerto should be building >>> without problems. >>> >>> Please make sure to follow the steps described at >>> http://concerto.xwiki.org/xwiki/bin/view/Main/Tutorial >>> >>> >>> >> Thanks for your efforts in making Concerto available again. >> >> >> >> >>> On the other hand, if you can wait a couple of hours, I am sure I >> will >>> find a place to host the 80mb jar installer build of Concerto that I >>> remade and fix the link available at >>> http://concerto.xwiki.org/xwiki/bin/view/Main/DownloadAndInstall >>> Please check the page for updates in about 12 hours. >>> >>> >>> >> I will give the built installer a go once its available at the above >> link. >> >> Thank you for your interest in Concerto and I would greatly >> appreciate >> >> >>> your feedback on it, even though the development on this project is >>> currently suspended. >>> >>> >>> >> Sure thing, I'll do
[xwiki-users] colibri menu icons revised
Hello. As you probably noticed some of the colibri menu icons recently modified, especially the ones which have white as a base color, doesn`t look nice at all on a white background. That`s why I added a light gray border in order to make them look nice on white bg. Here you can see the result: http://incubator.myxwiki.org/xwiki/bin/view/Ciprian/Icons You will notice that their aspect is also changed a little, for darker backgrounds but it shouldn`t be that visually disturbing. They are still 16x16 px. If everyone agree I will make a patch with the new version. Thanks. -- Ciprian, Designer XWiki ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
