Trying to track down the source of some persistent performance issues under
load with 6.2 RC 1 (haven't had time to upgrade to 6.2 final yet). I'm
maxing out at about 30 or so users before dying on a system with 4GB of RAM.
The java interpreter is getting pegged to 100% of the CPU, and about 70% of
the calls in the stack trace are futex lock errors. A good chunk of the
remainder are gettimeofday calls.
Potentially useful info (sorry for formatting):
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
72.75 5361.592109 45075 118947 14045 futex
12.28 905.064191 466 1943354 gettimeofday
4.83 356.110745 3709487 96 45 restart_syscall
2.88 212.173358 836 253729 clock_gettime
2.71 199.867690 8802 22706 recvfrom
2.10 154.843342 37841 4092 poll
1.14 84.282371 580 145307 130153 stat
Any ideas?
thanks,
aaron
Hello XWiki Community,
while creating an App within a Minute I get groovy executing failures for each element of the form. It is possible to save and finish the process but I cannot access the editor for the content field. That means I cannot enter default entries.
You can see the full failure message at the end of the mail.
I googled the problem and found entries for Confluence. Maybe they can guide a way:
Now I added the "-XX:ReservedCodeCacheSize=64m" option into JAVA_OPTS. (https://bobswift.atlassian.net/browse/SCRP-129)
and
It worked for me, I just added XX:ReservedCodeCacheSize to my setenv.sh and until now everything is ok. (https://answers.atlassian.com/questions/13535/problem-with-the-script-runne…)
I am running version 5.4.5
Thank you for your time!
Best regards,
Peter
Here is the error which is displayed when I reenter the wizard page for step 2:
Failed to execute the [groovy] macro:
java.lang.VerifyError: (class: org/codehaus/groovy/runtime/ArrayUtil, method: createArray signature: ()[Ljava/lang/Object;) Illegal type in constant pool
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:190)
at Script89.run(Script89.groovy:41)
at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:346)
at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:146)
at org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.eval(AbstractJSR223ScriptMacro.java:292)
at org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluateBlock(AbstractJSR223ScriptMacro.java:226)
at org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluateBlock(AbstractJSR223ScriptMacro.java:177)
at org.xwiki.rendering.macro.script.AbstractJSR223ScriptMacro.evaluateBlock(AbstractJSR223ScriptMacro.java:57)
at org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:198)
at org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:59)
at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transformOnce(MacroTransformation.java:191)
at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transform(MacroTransformation.java:132)
at org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:87)
at org.xwiki.display.internal.DocumentContentDisplayer.display(DocumentContentDisplayer.java:252)
at org.xwiki.display.internal.DocumentContentDisplayer.display(DocumentContentDisplayer.java:125)
at org.xwiki.display.internal.DocumentContentDisplayer.display(DocumentContentDisplayer.java:55)
at org.xwiki.display.internal.DefaultDocumentDisplayer.display(DefaultDocumentDisplayer.java:80)
at org.xwiki.display.internal.DefaultDocumentDisplayer.display(DefaultDocumentDisplayer.java:38)
at org.xwiki.sheet.internal.SheetDocumentDisplayer.display(SheetDocumentDisplayer.java:253)
at org.xwiki.sheet.internal.SheetDocumentDisplayer.applySheet(SheetDocumentDisplayer.java:212)
at org.xwiki.sheet.internal.SheetDocumentDisplayer.maybeDisplayWithSheet(SheetDocumentDisplayer.java:164)
at org.xwiki.sheet.internal.SheetDocumentDisplayer.display(SheetDocumentDisplayer.java:102)
at org.xwiki.sheet.internal.SheetDocumentDisplayer.display(SheetDocumentDisplayer.java:50)
at org.xwiki.display.internal.ConfiguredDocumentDisplayer.display(ConfiguredDocumentDisplayer.java:67)
at org.xwiki.display.internal.ConfiguredDocumentDisplayer.display(ConfiguredDocumentDisplayer.java:41)
at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:997)
at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:976)
at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:1007)
at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:619)
at sun.reflect.GeneratedMethodAccessor343.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228)
at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:187)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:105)
at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluate(DefaultPrivilegedTemplateRenderer.java:125)
at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluateTemplate(DefaultPrivilegedTemplateRenderer.java:75)
at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1687)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1627)
at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:918)
at sun.reflect.GeneratedMethodAccessor165.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216)
at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311)
at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228)
at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:187)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:105)
at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluate(DefaultPrivilegedTemplateRenderer.java:125)
at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluateTemplate(DefaultPrivilegedTemplateRenderer.java:75)
at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1687)
at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:167)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:304)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:129)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:121)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:66)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:208)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:111)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:185)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:151)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:269)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Having been put off writing Java components a number of times I've decided to really tackle the problem head on. I would greatly appreciate any help in this.
I've been following the advice in http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingComponents and I have compiled a Jar identical to the Hello World example except that the class and method names differ, hopefully consistently. I've placed the jar in XE_WAR_HOME/WEB-INF/lib and written a page, which consists only of
{{velocity}}
$services.mycomponent.greet()
{{/velocity}}
The output when viewed is simple "$services.alertdb.greet()", so nothing seems to have happened. However, if I restart Tomcat (and then wait a minute or so for XWiki to restart) the output is "Hello", as desired.
So is a restart of Tomcat always required? This wasn't mentioned in the guide. And since extensions can be added via the extension manager without a restart, is there a sneaky trick to doing the same with my own components.
Also, is a restart necessary when I update the Jar, either with fixed methods or modified interface?
I am a satisfied user XWiki, but I carried on porting XWiki nuodb (jdbc
driver exists). If you are a developer, Who is able to do this, please
contact me, I can be a sponsor of this small activity (some dollars up to $
100 for this small task).
After successfull work, the code changes will be published to public xwiki
repository for all other users (open source, it's have to request, not
private development).
Testing capacity I can deliver for testing portation, license of NuoDB is
free for developers (www.nuodb.com). Platform: native linux 64 (Centos)
If you are interested, please contact me.
PS: Some new features and changes of existing I have in long wishlist....
could be long term cooperation. Work off site, no on site needed (You
provide changes as source code package of xwiki, we test it in our
environment).
Petr Šimbera
psimbera(a)seznam.cz
(native czech language, Czech Republic), english is ok ...
What's the preferred way to deal with errors occuring in Java components? Is it OK to throw an exception from within the component, and can this be caught within the Velocity or Groovy code that calls it?
What's the right way to get the current user from the execution context within a Java component?
Taking the example from the guide (http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingComponents) I thought it would be something like the following, which won't compile for me due to the getLocalUser symbol not being found.
import org.xwiki.context.Execution;
import org.xwiki.context.ExecutionContext;
...
@Inject
private Execution execution;
@Override
public String sayHello()
{
ExecutionContext context = execution.getContext();
String user = context.getLocalUser();
return "Hello " + user;
}
I note that in http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/or… the getLocalUser() method is deprecated in lieu of getUserReference() but I'd really rather deal with a String if at all possible.
Hi,
in our company we used the standalone version of XWiki for testing and are
very satisfied with it so we want to migrate to the new version and a more
robust setup.
The setup is Windows Server 2003 R2 (sadly only 32 bits) with Apache 2.4,
MySQL 5 and Tomcat 7.
XWiki 6.3 is setup now including a Wiki Template so I'd like to migrate the
data I exported as XAR from the 5.4.5 standalone instance.
My approach was exporting data from 5.4.5, creating the Wikis using the
template and importing the spaces and pages from the XAR export.
The issue I'm facing is Java heap size which constantly gets in my way. As
we're on a 32 bits system I can only assign ~1.2 GB of memory (the server
has 4GB).
This limitation makes it impossible to import the data into the new setup.
I tried general export/import via administration page and the various
options using the Admin Tools Application but on one of both ends I always
get the out of memory error.
- Using normal export/import: Export works but import throws the error
- Admin Tools - Export pages and spaces: Export works but import throws the
error
- Admin Tools - Large Export on Disk: the heap size error is thrown
Do you have any suggestions/hints on how I can migrate the spaces and pages
I have in the 5.4.5 setup to the 6.3 one?
Thanks in advance,
Dennis
On Mon, Nov 24, 2014 at 9:46 AM, Gerritjan Koekkoek
<gerritjankoekkoek(a)gmail.com> wrote:
Hi,
I'm trying to understand the new SOLR search (i did not understand the old
Lucene very well)
My use-case is the following.
We have a special FAQ application where the object has, amongst others, the
following attributes:
- Subject
- Topic-group
- Language
- Question
- Answer
he default search returns page-title/name, but this is in our case a
non-informational, generated by the system code. So instead of Page name we
would like to show: Subject
You have 3 options:
(1) Use Velocity to output the value of the subject property in the
FAQ title. See
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
Gerritjan: Thanks this is helpful but see below....
(2) I doesn't make sense to have a separate String property to store
the subject when you can store it in the document title.
The designer of our FAQ has opted to store multiple objects of same class
in one page. (because XWiki does not support "multiple locales
(language-country)" on a object level. So the title must pick the subject
name of the object of the current language-country combination. When we
just display the subject we do not need to solve this challenge.
(3) Customize the entire search page just to change the way the search
results are displayed
Yes I fear there is no way around this?
As facets we would like to show Topic-group and Language,
Default (on entering the page with search box) we would like to set the
context-language as a search filter... So when reader is reading french the
result only shows french FAQ (with a french subject title) if english only
english.
By checking and unchecking languages in the facets the user could extend or
reduce the search.
This is already the case with the default search. The context language
is checked by default in the locale facet. See
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
.
It looks the context language is only looking at language attribute of page.
We need to compare with attribute in object.
I think it would be useful if some explanation is how the object-based
facets can be defined.
A challenge is the topic field, this is a list with translation key. So if
user is french-language the list will show french topics, but if he/she
check english as well in facets things get complicated.
We have a business-rule that the english collection of FAQ's is the
baseline, and most comprehensive. The other languages are only translations
of the same. So another languages can not have a question not translated.
So my question is:
How to define the search
http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Applicatio…http://design.xwiki.org/xwiki/bin/view/Design/SolrSchemahttp://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Query+APIhttp://lucene.apache.org/solr/
How to modify the output so page-title is no longer showing
How to modify facets so only the two fields can be set
See
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
.This helps...
Hope this helps,
Marius
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
To folks who have the "Mocca Calendar"[1] application installed in their XWiki instances:
I have just released a new version 2.2.1 to which you might want to update to, as it contains quite a few bugfixes and improvements, thanks to patches send in by several contributors.[2]
However the new release does not show up when you try to update via the "Extension Updater" in your wiki admin; instead the latest version found there will be 2.1.9.
This happened due to a glitch when reorganizing the code which changed the Extension-Id for that application.
Instead please go to "Add extensions", search for "Mocca Calendar" and when the search result comes up, the extension manager should propose you to update to the correct version 2.2.1
Also while upgrading at least in my test instances I got a few spurious conflicts.
If you get them too, even while you have made no modifications to the "code" part of the calendar, please choose to keep the new version to get all updates installed property.
Best regards and sorry for the hiccup,
Clemens
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/MoccaCalendar
[2] http://jira.xwiki.org/browse/MOCCACAL-32?filter=13491
Many thanks, I'll give that a go.
________________________________________
From: Thomas Mortagne [thomas.mortagne(a)xwiki.com]
Sent: 27 November 2014 23:14
To: Bryn Jeffries
Subject: Re: [xwiki-users] Registering components
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
is a good up to date (we changed several time the mocking system to
use in XWiki by default, it's Mockito currently) example of how to
manipuated a mock of DocumentAccessBridge in a component oriented unit
test.
On Thu, Nov 27, 2014 at 11:42 AM, Bryn Jeffries
<bryn.jeffries(a)sydney.edu.au> wrote:
> Useful to know, thanks. Incidentally, are there any useful mocks, etc, for
> unit testing xwiki component code ( to avoid frequently restarting tomcat)?
> Like a mock execution context, for instance?
>
> Thanks,
>
> Bryn
>
>
>
> ----- Reply message -----
> From: "Thomas Mortagne" <thomas.mortagne(a)xwiki.com>
> To: "XWiki Users" <users(a)xwiki.org>
> Subject: Re: [xwiki-users] Registering components
> Date: Thu, Nov 27, 2014 18:38
>
> On Thu, Nov 27, 2014 at 8:36 AM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com> wrote:
>> What you have in XE_WAR_HOME/WEB-INF/lib is loaded by Tomcat at
>> startup, there is not much XWiki can do about it.
>>
>> But you can install your jar as an extension using Extension Manager
>> as long as it's on some supported repository (which mean a Maven
>> repository or XWiki repository, see
>>
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository+Application
>> for this last one) and you indicate your repository in
>> xwiki.properties.
>
> Note that Extension Manager is not the best fit right now to test
> snapshot jars since it does not have the required special handling of
> SNAPSHOT needed to update to a new version of the same SNAPSHOT
> version.
>
>>
>> On Thu, Nov 27, 2014 at 5:20 AM, Bryn Jeffries
>> <bryn.jeffries(a)sydney.edu.au> wrote:
>>> Having been put off writing Java components a number of times I've
>>> decided to really tackle the problem head on. I would greatly appreciate any
>>> help in this.
>>>
>>> I've been following the advice in
>>> http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingComponents and I
>>> have compiled a Jar identical to the Hello World example except that the
>>> class and method names differ, hopefully consistently. I've placed the jar
>>> in XE_WAR_HOME/WEB-INF/lib and written a page, which consists only of
>>> {{velocity}}
>>> $services.mycomponent.greet()
>>> {{/velocity}}
>>>
>>> The output when viewed is simple "$services.alertdb.greet()", so nothing
>>> seems to have happened. However, if I restart Tomcat (and then wait a minute
>>> or so for XWiki to restart) the output is "Hello", as desired.
>>>
>>> So is a restart of Tomcat always required? This wasn't mentioned in the
>>> guide. And since extensions can be added via the extension manager without a
>>> restart, is there a sneaky trick to doing the same with my own components.
>>>
>>> Also, is a restart necessary when I update the Jar, either with fixed
>>> methods or modified interface?
>>> _______________________________________________
>>> users mailing list
>>> users(a)xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne