- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] How to deploy a new jar bundle

by lequan.moon

The problem i'm having is when i'm developing an application in xwiki, normally, I just have to send my friends a xar file if all my sources are in pages. But when i use an external jar bundle, I have to put it into WEB-INF/lib. Is there anyway to deploy my application without put the external jar file by hand into WEB-INF/lib -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-deploy-a-new-jar-bundle-tp7588210.… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 9 months

3
8
0 0

[xwiki-devs] [Proposal] New dates (again) for 5.3RC1 and final

by vincent＠massol.net

We’re getting there! New proposal: - 5.3RC1: tomorrow (5th) - 5.3 final: 10th of Dec Note: originally we were supposed to release on 25th of Nov. Thanks -Vincent

11 years, 9 months

1
0
0 0

[xwiki-devs] French translation: congratulations!

by xrichard

Hi, I want to personnaly congratulate "raluca moisa" for the big work and the top quality of the french translation he is currently doing on http://l10n.xwiki.org. There are now less than 50 strings to translate in french. I'm confident we could together reach 100% in the coming week. Thanks again ;-). PS: I hope "raluca moisa" has subscried to this mailing list because I have no other way to contact and congratulate him for the hard work done -- View this message in context: http://xwiki.475771.n2.nabble.com/French-translation-congratulations-tp7588… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 9 months

2
1
0 0

[xwiki-devs] [Feedback] Extension Manager (+ Distribution Wizard)

by Ecaterina Moraru (Valica)

Hi, I'm gathering feedback about our Extension Manager [1] and implicitly about Distribution Wizard [2]. The purpose of this feedback request targets: - Acknowledgment that the features are working as expected and they solve the initial problems; - Raising new use cases and feature requests for them in order to improve productivity, usability, performance, etc.; - Any other problems/issues/feedback related to these topics. I will gather some conclusions on this page http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensionManagerUseCases Thanks, Caty [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Manager+Appl… [2] http://platform.xwiki.org/xwiki/bin/view/Features/DistributionWizard

11 years, 9 months

2
2
0 0

[xwiki-devs] How to load VelocityEngine in Java for a custom macro

by Matthias Wegner

Hello Devs, i try to use a custom template in a macro and didn't get the template loaded. I tried System.getProperty("user.dir") with "webapps/xwiki/templates/custom.vm". I always get the message "unable to find resouce in resource loader". Can you give me a hint how i load a correct VelocityEngine to load a template in the "templates"-directory. Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-load-VelocityEngine-in-Java-for-a-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 9 months

2
1
0 0

[xwiki-devs] XWiki MSQL Support

by Richard Hierlmeier

most of our customers use MSSQL as database system. From time to time we have the opportunity to establish XWiki in customer projects. However it is difficulty and risky to recomment XWiki on a database system that is not supported by XWiki.org. What are the reasons for not supporting MSSQL? Is it simply a license or resource problem? Can we contribute here something? Richard

11 years, 9 months

2
2
0 0

[xwiki-devs] Preliminary memory analysis of xwiki.org dump of 2013-12-01

by vincent＠massol.net

Hi devs, Yesterday xwiki.org crashed and I had configured it to take a heap dump. I’ve done a quick analysis that I’m sharing here (I’ll continue to analyse): Memory retained: 1GB Main contenders: 1) Document cache: 178MB 2) Lucene WeightedSpanTermExtractor: 166MB 3) IRCBot Threads: 165MB 4) Velocity RuntimeInstance: 38MB 5) SOLR LRUCache (Lucene Document): 38MB 6) EM DefaultCoreExtensionRepository: 38MB 7) NamespaceURLClassLoader: 23MB I’ve started analyzing some below. 1 - Document Cache Analysis ======================= * There are 3552 XWikiDocument in memory for 195MB * The document cache size is 2000 on xwiki.org * Large documents (such as Test Reports) take 6MB each (XDOM caching) * So if we had only large documents in the wiki the cache would need 2000*6MB = 12TO * I don’t think this cache is memory aware, meaning it doesn’t free its entries when memory is low * 178MB for 2000 docs means average of 89K per document. Huge variation between docs with big content and docs with no or small content This means that when memory is low on xwiki.org it should be enough to call a few pages with some large content to get an OOM. 4 ideas to explore: Idea 1: Use a cache that evicts entries when some max threshold is reached ** Infinispan doesn’t support this yet: https://issues.jboss.org/browse/ISPN-863 and https://community.jboss.org/thread/165951?start=0&tstart=0 ** Guava seems to support size-based eviction with the ability to pass a weight function: http://code.google.com/p/guava-libraries/wiki/CachesExplained#Size-based_Ev… Idea 2: Another idea is a usage of a distributed cache such as memcached or elasticsearch. I wonder if the overhead of the network communication is too high to make it interesting vs not caching the XDOM and rendering it every time it’s needed. Idea 3: Try to reduce even more how the XDOM is stored in memory Idea 4: Don’t cache the XDOM and render every time and use a title cache for titles. Also do that for getting sections. I think they are the 2 main uses cases for getting the XDOM. As a short term action, I’d recommend to immediately reduce the document cache size from 2000 to 1000 on wiki.org or double the heap memory. 2 - Lucene WeightedSpanTermExtractor Analysis ===================================== I’m not sure what this is about yet but it looks strange. * There is 166MB stored in the Map<String,AtomicReaderContext> of WeightedSpanTermExtractor. * That map contains 192 instances * Example of map items: “doccontent_pt” (2.4MB), “title_ru” (1.8MB), “title_ro” (1.8MB), etc Any idea Marius? 3 - IRCBot Analysis =============== * We use 3 IRCBot threads. They take 55MB each! * The 55MB is taken by the ExecutionContext * More precisely the 55MB are held in 77371 org.apache.velocity.runtime.parser.node.Node[] objects I need to understand more why it’s so large since it doesn’t look normal. I also wonder if it keeps increasing or not. 5 - SOLR LRUCache Analysis ======================= * It’s map of 512 entries (Lucene Document objects). 512 is the cache size. * Entries are instances of DocSlice Looks ok and normal. 6 - EM DefaultCoreExtensionRepository Analysis ====================================== * 38MB in "Map<String, DefaultCoreExtension> extensions” * 33MB in org.codehaus.plexus.util.xml.Xpp3Dom instances (44844 instances) which I guess corresponds to the pom.xml of all our core extensions mostly. Looks normal even though 33MB is quite a lot. 7 - NamespaceURLClassLoader Analysis ================================ * 23MB in org.eclipse.jgit.storage.file.WindowCache * So this seems related to the XWiki Git Module used by the GitHubStats application installed on dev.xwiki.org This looks ok and normal according to http://download.eclipse.org/jgit/docs/jgit-2.0.0.201206130900-r/apidocs/org… Thanks -Vincent

11 years, 9 months

3
4
0 0

[xwiki-devs] About how to import the source code into eclipse.

by zhefangwu

I just want import the project to eclipse. But there are some errors during maven compile. Where can I find some help to do so? 发自我的 iPhone

11 years, 9 months

2
1
0 0

[xwiki-devs] HTML Cleaner and inline SVG

by Sergiu Dumitriu

Hi devs, Trying to fix http://jira.xwiki.org/browse/XWIKI-9753 I found 4 plausible solutions (other than switching to something better than HTMLCleaner): 1. Provide a PdfHTMLCleaner implementation which inherits DefaultHTMLCleaner but doesn't omit unknown tags 2. Change the DefaultHTMLCleaner so that it doesn't omit unknown tags 3. Instead of relying on org.htmlcleaner.DefaultTagProvider, use org.htmlcleaner.ConfigFileTagProvider with a custom tag configuration that allows all HTML5+SVG+MathML, which is a good idea if we want to switch to HTML5 in the future 4. Add another custom key for HTMLCleanerConfiguration for switching this unknown tags setting on or off Which do you prefer? 1 is quick to implement, but might introduce some other regressions in the PDF export if we're allowing all unknown tags 2 might be a dangerous change, which will break other things 3 is a clean fix, but involves some work 4 is also quick to implement, but it means adding another custom setting that limits the possible choices for the HTMLCleaner backend I vote for 4 as a quick fix, with 3 as a long term goal. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

11 years, 9 months

1
0
0 0

[xwiki-devs] [Reminder] BFD#46

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 46. We're currently at -127 bugs (we were at -127 bugs last week!) for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Bugs still seem to be winning ATM. Let's reduce this gap a bit... IMPORTANT: Since we're getting close to the end of the 5.x cycle and since this is RC time please be very careful about your commits and don't commit anything dangerous. Be on the safe side. It's better to do less bugs rather than commit regressions. We've been having issues of stability recently and they might have been added during BFD so we need to be careful. NOTE: Since we're again very late for 5.3 I think it's acceptable that some committers continue their work for 5.3 RC1 and final today instead of participating to this BFD. Here's the BFD#46 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11798 Thanks -Vincent

11 years, 9 months

2
2
0 0

[xwiki-devs] [Solr] What do we search for?

by Marius Dumitru Florea

Hi devs, This is a very important question so think carefully. Let me explain: In XWiki (model) we have a few entity types. There are *wikis* which have *spaces* which have *documents*. A document can have *objects* and *attachments*. A document can also define a *class*. At the same time we like to say that in XWiki "everything is a document" because everything revolves around documents. The document is the central notion. We can query the database (using HQL or XWQL) for any of the previously mentioned entities but what should a Solr query return (semantically)? In other words: * are you searching for an object without caring about the document that holds the object? Same for an object property. * how often are you searching for an attachment without caring about the document that holds the attachment? * are you searching for a class or for the document that defines that class? * are you searching for a wiki without caring about the documents it contains? Same for a space. IMO the result of a Solr query should be, semantically, a list of documents. But maybe I'm wrong. ----------------------- Technical Details ----------------------- Unlike a relational database, Solr/Lucene index has a single 'table'. So normally you index a single entity type. Each row in the index represents an entity of that type. As a consequence the result of a Solr query is semantically a list of entities of that type. In our case the entity type is (naturally) *document*. If you want to index more entity types (e.g. index attachments and objects _separately_, not as part of a document) then, since there is only one 'table' in the index, you need to add a 'type' column that specifies the type of entity you have on each row (e.g. type=document, type=attachment, type=object etc.). The result of a Solr query is now, semantically, a list of different entity types, unless you filter by a specific type. It smells like a hack to me. Let's imagine what happens if we want to search for blog posts that has a specific tag. With the first approach this is easy because all the (indexed) information is on a single row. With the second approach this is considerably more complex because the information is spread on multiple rows: * one row with type=document for the blog post document * one row with type=object for the blog post object * one row with type=object for the tab object In a relational database when you have the information spread in multiple places (tables) you do joins. Fortunately (you would says) Solr supports joins. In this particular case we would have to perform 2 joins which means: index X index X index where X represents the cartesian product. The document name would be the join key. Pretty complex even before trying to write this in Solr query syntax.. So basically the question becomes: is it worth indexing more entities _separately_ instead of indexing just documents (with info about their objects and attachments) considering the complexity that it brings in writing Solr queries? Do we search for objects and attachments alone as separate entities often enough to justify this complexity? My answer is no. Thanks, Marius

11 years, 9 months

6
15
0 0

[xwiki-devs] help

by 云水谣

hi，all： when I got help from xwiki.org,I can not find useful message about how to develop in xwiki pages. I describe what I want to do：I just has some information to write on xwiki on one page，because these information may change everyday,so I want to get these information from a http api,and then put it down in wiki,I can not find one complete example in xwiki.org website:how to use this scripts in xwiki and where should i put these scripts file in? how these script files cooperates？ thanks

11 years, 9 months

1
0
0 0

[xwiki-devs] Retrieve the list of users based on the selected group

by le bihan matthieu

Hello, I researched the forum to see if a subject could meet my need, but I have not found a solution. My need: I want to make a day depending on the user group selection list select from a list. For lists, I use the wiki groups and users of xwiki. I want to retrieve the list of xwiki users in the selected group. To create the list of groups I used the velocity, by cons I think to create the user must use javascript because every time we change the group must make days the list of users. This is the part I select the group name but how do I find the list of users in this group? Thank you in advance, I am at your disposal for any further information! Regards, Matthieu Le Bihan -- View this message in context: http://xwiki.475771.n2.nabble.com/Retrieve-the-list-of-users-based-on-the-s… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 9 months

3
4
0 0

[xwiki-devs] XWiki Rendering: WELD-001414 Bean name is ambiguous

by Gerry

Hi all, I'm new to XWiki development and trying to include XWiki rendering into my project. Unfortunately I'm getting the attached error message. Can anyone help me please? I'm using Maven 3, Glassfish 4.0, CDI1.1, JSF 2.2, and XWiki 5.2.1. Please let me know if you need any further information. Thanks for your help. Best regards, Gerry Error message: 2013-11-23T18:26:10.507+0100|SEVERE: Exception during lifecycle processing org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001414 Bean name is ambiguous. Name xwiki/2.1 resolves to beans [Managed Bean [class org.xwiki.rendering.internal.parser.xwiki21.XWiki21Parser] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxRendererFactory] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxBlockRenderer] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.reference.XWiki21ResourceReferenceTypeSerializer] with qualifiers [@Default @Named @Any]] at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:356) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534) at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224) at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544) at java.lang.Thread.run(Thread.java:724) Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name xwiki/2.1 resolves to beans [Managed Bean [class org.xwiki.rendering.internal.parser.xwiki21.XWiki21Parser] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxRendererFactory] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxBlockRenderer] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.reference.XWiki21ResourceReferenceTypeSerializer] with qualifiers [@Default @Named @Any]] at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:639) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:488) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216) ... 36 more 2013-11-23T18:26:10.509+0100|SEVERE: Exception while loading the app 2013-11-23T18:26:10.509+0100|SEVERE: Undeployment failed for context /jasp-webapp 2013-11-23T18:26:10.556+0100|SEVERE: Exception while loading the app : CDI deployment failure:WELD-001414 Bean name is ambiguous. Name xwiki/2.1 resolves to beans [Managed Bean [class org.xwiki.rendering.internal.parser.xwiki21.XWiki21Parser] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxRendererFactory] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxBlockRenderer] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.reference.XWiki21ResourceReferenceTypeSerializer] with qualifiers [@Default @Named @Any]] org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name xwiki/2.1 resolves to beans [Managed Bean [class org.xwiki.rendering.internal.parser.xwiki21.XWiki21Parser] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxRendererFactory] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.XWikiSyntaxBlockRenderer] with qualifiers [@Default @Named @Any], Managed Bean [class org.xwiki.rendering.internal.renderer.xwiki21.reference.XWiki21ResourceReferenceTypeSerializer] with qualifiers [@Default @Named @Any]] at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:639) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:488) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:356) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534) at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224) at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544) at java.lang.Thread.run(Thread.java:724) Relevant dependencies from pom.xml: <dependency> <groupId>org.xwiki.rendering</groupId> <artifactId>xwiki-rendering-syntax-xwiki21</artifactId> <version>5.2.1</version> </dependency> <dependency> <groupId>org.xwiki.commons</groupId> <artifactId>xwiki-commons-component-default</artifactId> <version>5.2.1</version> </dependency> <dependency> <groupId>org.xwiki.rendering</groupId> <artifactId>xwiki-rendering-macro-toc</artifactId> <version>5.2.1</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.0.13</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.7.5</version> </dependency> -- View this message in context: http://xwiki.475771.n2.nabble.com/XWiki-Rendering-WELD-001414-Bean-name-is-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 9 months

3
3
0 0

[xwiki-devs] [ANN] WebViewers, a way to view and edit attachments in XWiki (and other webapps!)

by Caleb James DeLisle

Hi guys, I am proud to announce WebViewers are now available for XWiki. As part of the Resilience research project, I and others have been working on a compatible solution for interfacing the variety of Javascript file viewers and editors with the many available web application frameworks. The first few WebViewers are available now on http://webviewers.org/ and as self-contained archive files, are installable on any system supporting the API. More interestingly, the first few WebViewers to be ported are now available as XWiki Extensions on http://extensions.xwiki.org/xwiki/bin/view/ExtensionCode/ExtensionSearch?sp… and while they are largely prototypes, one which is useful right now is the PDF WebViewer based on Mozilla's pdf.js. http://extensions.xwiki.org/xwiki/bin/view/Extension/pdf+webviewer This is of course installable with the Extension Manager and supports XWiki versions 5.1 or newer. With this you will be able to both view in a preview window and embed in a wiki page, the content of a PDF attachment. Viewing of the attachment is done by clicking on the magnifying glass shown next to the PDF attachment and embedding a PDF attachment in the page is done using the {{embed}} macro (part of the XWiki WebViewers extension). You can see the embedded viewers and example uses of the {{embed}} macro here: http://webviewers.org/xwiki/bin/view/Viewers/Demo And you can see the magnifying glass icons next to the attachments here: http://webviewers.org/xwiki/bin/view/Viewers/Demo#Attachments If anyone has any questions or comments about WebViewers or the XWiki Extensions, I'd love to hear them. Thanks, Caleb

11 years, 9 months

1
0
0 0

[xwiki-devs] [Proposal] Move xwiki-platform-wiki-manager and xwiki-platform-workspaces in contrib

by Guillaume "Louis-Marie" Delhumeau

Hi devs. Thomas has merged my pull request for the new wiki API. I'm happy! Now, xwiki-platform-wiki-manager and xwiki-platform-workspaces are obsoletes. We should delete them or move them to xwiki-contrib. Here is my +1 for the move! Thanks Louis-Marie

11 years, 9 months

6
18
0 0

[xwiki-devs] [Reminder] BFD#45

by Vincent Massol

Hi devs, Today is Bug Fixing Day 45. We're currently at -127 bugs (we were at -112 bugs last week!) for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Bugs seem to be winning ATM. Let's reduce this gap... IMPORTANT: Since we're getting close to the end of the 5.x cycle and since this is RC time please be very careful about your commits and don't commit anything dangerous. Be on the safe side. It's better to do less bugs rather than commit regressions. We've been having issues of stability recently and they might have been added during BFD so we need to be careful. NOTE: Since we're late for 5.3 (I'm going to send a new date proposal), I think it's acceptable that some committers continue their work for 5.3 RC1 and final today instead of participating to this BFD. Your decision ofc ;) Here's the BFD#45 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11796 Thanks -Vincent

11 years, 9 months

2
1
0 0

[xwiki-devs] Cannot get email value for XWikiUsers BaseObject

by Valdis Vītoliņš

I got stuck with customized validation for XWikiUsers class using XWiki 5.2. I have custom sheet with validation with following code excerpt: public class PersonValidation implements XWikiValidationInterface { public boolean validateDocument(XWikiDocument doc, XWikiContext context) { // Validation result def res = true; // User settings from the session context def session=context.getRequest().getSession(); def user = context.getUser(); def userObj=context.getWiki().getDocument(user, context).getObject('XWiki.XWikiUsers'); if(true) { XWikiValidationStatus.addErrorToContext('NMPDtools.UserClass', '', '', 'E-mail is '+userObj.getStringValue('email'), context); res = false; } return res; } public boolean validateObject(BaseObject object, XWikiContext context) { return true; } } In difference with first_name, last_name, phone, etc. This method doesn't return property value. I noted, that using passed XWiki context, BaseObject is retured in difference with Object for inline scripts, where get... methods works properly. If nothing else, is there is way to get Object from BaseObject? Any suggestions ar welcome! Valdis

11 years, 9 months

2
2
0 0

[xwiki-devs] [Proposal] Delaying the XWiki 5.3 release

by vincent＠massol.net

Hi devs, 5.3 was initially planned to be released on the 25th. However as you can see on http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome some important issues that were planned for 5.3 are still not done. Normally we'd do timeboxing (ie release and implement the rest in the next version) but since we’re getting close to the end of the cycle and since some important issues remain I’d like to propose to delay the release by 1 week in order to finish the maximum number of issues for 5.3 (those related to SOLR, Wiki creation and Confluence/Scalable import/export). That will also give more time to Sorin/Manuel for testing 5.3 before the release. This would mean: 5.3 RC1: 27th of November 5.3 Final: 4th of December WDYT? Thanks -Vincent

11 years, 9 months

5
4
0 0

[xwiki-devs] Improvement of XWiki search results to include keyword matches (Fine tuning!)

by Stuart Stephen

Hi, I spent some time making my XWiki instance show a more useful list of results from the search results, but there is a problem here as the freemarker code is unable to catch a rendering exception (by design of freemarker) on certain searches. If there is an exception, the user is greeted with a long wait, then no results show up at all. This isn't really good enough for my means. My happier solution, would be for the exception to happen and for nothing to be rendered in the preview for this search result. I wondered if there was a better way to achieve my goal than using the rendering mechanisms in the code below. If I can avoid or catch the exception and keep the same functionality that I have now, then I would be in a better position. Code below or on StackOverflow (http://stackoverflow.com/q/17038968/1247302). I'm using XWIKI ENTERPRISE 5.0-MILESTONE-1. I edited the page http://[servername:port]/xwiki/bin/edit/XWiki/Results and then added the code <div class="itemOthers"> #set($outputSyntax = $xwiki.getAvailableRendererSyntax('plain', '1.0')) #if ($outputSyntax) #set ($preview = $xwiki.getDocument($itemfullname).getRenderedContent($outputSyntax)) #set ($regex = $regextool.quote($request.text)) #set ($regex_summarize = "(?i)(?:((\w+)\W+){0,20})\b\w*$regex\w*\b(((\W+)\w+){0,20})") #set ($regex_highlight = "(?i)($regex)") #set ($pattern_summarize = $regextool.compile($regex_summarize)) #set ($matcher_summarize = $pattern_summarize.matcher($preview)) #foreach ( $match_loop in [0,1,2,3,4,5,6,7,8,9] ) #if ($matcher_summarize.find()) #if ($match_loop > 0) <strong> | </strong> #end $escapetool.html($matcher_summarize.group(0)).replaceAll($regex_highlight,'<span style="background-color:yellow;">$1</span>') #end #end #end </div> Thanks, Stuart Disclaimer: The contents of this E-mail plus any attachment is intended for the use of the addressee only and is confidential, proprietary and may be privileged. It will not be binding upon Trace Group or any group company (Trace). Opinions, conclusions, contractual obligations and other information in this message in so far as they relate to the official business of Trace must be specifically confirmed in writing by Trace. If you are not the intended recipient you must not copy this message or attachment, use or disclose the contents to any other person, but are requested to telephone or E-mail the sender and delete the message and any attachment from your system. Trace takes all reasonable precautions to ensure that no virus or defect is transmitted via this e mail, however Trace accepts no responsibility for any virus or defect that might arise from opening this E-mail or attachments.

11 years, 9 months

2
2
0 0

[xwiki-devs] [ANN] XWiki 5.3 Milestone 2 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 5.3 Milestone 2. This release comes with a new syntax quide, an improved faceted search and the ability to import content from Confluence wiki. Also, the wiki creation wizard has now support for creating wiki templates and for choosing the user scope (local, global or both). This release also includes a lot of bug fixes (33) and a few improvements (19) so you should definitely check it out. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki53M2 Thanks -The XWiki dev team

11 years, 9 months

1
0
0 0

[xwiki-devs] Set Mandatory field with AbstractMandatoryDocumentInitializer

by Matthias Wegner

Hello, i use AbstractMandatoryDocumentInitializer for creation of some classes and i want to set some fields mandatory. Is that possible? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Set-Mandatory-field-with-AbstractMandator… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 9 months

3
2
0 0

[xwiki-devs] Request commit rights for Holiday Request Application

by Andreea Popescu

Hello, I'd like to fix some issues and release a new version for Holiday Request Application. The github repos is https://github.com/xwiki-contrib/xwiki-application-holidayrequest and my username is PopescuAndreea (https://github.com/PopescuAndreea). Thank you, Andreea

11 years, 10 months

2
2
0 0

[xwiki-devs] Introducing Andreea Popescu

by Andreea Popescu

Hello all! My name is Andreea Popescu, I'm an intern at XWiki SAS since the begging of November. I want to help with improving existing apps and implementing new ones, testing them and writing documentation etc. Thank you!

11 years, 10 months

2
1
0 0

[xwiki-devs] [Vote] Creation of a design wiki and it's purpose

by Ecaterina Moraru (Valica)

Hi, *Short version* for voting: *A*. Creation of a new wiki on xwiki.org farm that will hold development process details about a specific feature. This wiki will deprecate dev.xwiki.org:Design and incubator.myxwiki.org *B*. Vote on naming alternatives for this new wiki: design.xwiki.org incubator.xwiki.org *C*. UI on how a Proposal will be displayed in this new wiki (example AppWithinMinutes): http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki ------------------------------------------------ *Long version: * Right now development process activities are located in multiple places: - Analysis + Architecture: http://dev.xwiki.org/xwiki/bin/view/Design/ - Analysis + User Interface: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ - Other: http://xwiki.markmail.org/, http://jira.xwiki.org, chats, git comments, etc. This process can be hard to optimize and information is hard to track if you are looking for specific information. And the worst part of it is that is hard to automatize and lots of the items need manual gathering or search. *Part A. * This mail is about combining http://dev.xwiki.org/xwiki/bin/view/Design/and http://incubator.myxwiki.org/ work in a single place. This has already been discussed several times before ( http://xwiki.markmail.org/thread/kc32dufsf7nyyt6s and http://xwiki.markmail.org/thread/izj6aiyodwqia4vl) and the vote was favorable in this direction. The proposal was to create a new wiki called design.xwiki.org that will contain the combined information and that will target developers. The new wiki will be used to gather only proposal's development process information: requirements, architecture, solutions alternatives, user interface variants, planning, etc. for a specific feature/idea/improvement. After the proposal is implemented it will be properly documented in the right location for users (ex platform.xwiki.org). It is acceptable to have CSS + JS code on this wiki in order to demonstrate the functionality of the proposals, but we should not add experimental/dangerous code (groovy scripts, jars, etc.). For this case it is advisable to use a test machine, share your own instance or use the contrib.xwiki.org repository for hosting. The version upgrades will be handle by a community admin and the wiki gardening by me. The data from incubator.myxwiki.org and dev.xwiki.org:Design will be moved gradually after the new wiki is created. *Part B. * You should state your opinion regarding which name is better for the new wiki: - design.xwiki.org - incubator.xwiki.org - we accept other proposals. *Part C.* I've made a proposal on how a proposal page would look like: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki The proposal page will gather all the information related to it, making it easier to track it's progress. The entries will be separated depending on 4 categories: Analysis, Architecture, User Interface and Implementation, each category having it's own status, participants, jiras and timeframe. Categories are not mandatory for all proposals, smaller proposals will have just the related pages for certain areas. Each proposal will store it's data in a dedicated space. The implementation of the proposal will be handled by me. Let me know what you think. Thanks, Caty

11 years, 10 months

9
23
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs