xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] adding a new jsr-223 scripting language to xwiki (clojure)

by Niels Mayer

In http://code.xwiki.org/xwiki/bin/view/Snippets/DisplayFormatedCodeAttachment… > VincentMassol | 2009/05/05 20:03 > >> Niels, no there's no plan but we can now support any language using macros > so feel free to provide a clojure macro if you're interested. Shouldn't be > too hard to do, especially if there's a JSR-223 implementation (in which > case simply dropping the jar in WEB-INF/lib should be enough - you'd then > use it using the script macro). Clojure <http://groups.google.com/group/clojure> has aJSR-223 implementation according to: http://github.com/pmf/clojure-jsr223/tree/master http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages http://sayspy.blogspot.com/2009/03/interacting-between-jvm-lang-here-and.ht… Are there any examples, documentation, or suggestions of writing a "script macro" to call a new jar in WEB-INF/lib ? Any other special magic I should know? Does anything from the above suggest that Clojure couldn't be used as an Xwiki scripting language, replacing cases where Groovy scripting might normally be employed? Niels http://nielsmayer.com PS: Here's examples of easy "scripted java" programming you can do in Clojure (note the helpful parallelism constructs): http://travis-whitton.blogspot.com/2009/07/network-sweeping-with-clojure.ht… http://travis-whitton.blogspot.com/2009/06/clojures-agents-scientists-monke… It could be very useful to employ massive parallelism via such Clojure scripts, which could achieve a xwiki-based web portal performance akin to Yahoo's, Google's, etc. For example, the following describes how Yahoo works -- and would be quite easy to implement this kind of processing "for free" in Clojure with very little code: http://research.yahoo.com/files/pnuts.pdf The component responsible for multi-record requests is called the > scatter-gather engine, and is a component of the router. > The scatter-gather engine receives a multi-record request, > splits it into multiple individual requests for single records > or single tablet scans, and initiates those requests in parallel. > As the requests return success or failure, the scatter-gather > engine assembles the results and then passes them to the > client. In our implementation, the engine can begin streaming > some results back to the client as soon as they appear. > We chose a server-side approach instead of having the client > initiate multiple parallel requests for several reasons. First, > at the TCP/IP layer, it is preferable to have one connection > per client to the PNUTS service; since there are many clients > (and many concurrent processes per client machine) opening > one connection to PNUTS for each record being requested > in parallel overloads the network stack. Second, placing this > functionality on the server side allows us to optimize, for > example by grouping multiple requests to the same storage > server in the same web service call. > > Range queries and table scans are also handled by the > scatter gather engine. Typically there is only a single client > process retrieving the results for a query. The scatter gather > engine will scan only one tablet at a time and return results > to the client; this is about as fast as a typical client can > process results. In the case of a range scan, this mecha- > nism simplifies the process of returning the top-K results > (a frequently requested feature), since we only need to scan > enough tablets to provide K results. After returning the > first set of results, the scatter-gather engine constructs and > returns a continuation object, which allows the client to re- > trieve the next set of results. The continuation object con- > tains a modified range query, which, when executed, restarts > the range scan at the point the previous results left off. Con- > tinuation objects allow us to have cursor state on the client > side rather than the server. In a shared service such as > PNUTS, it is essential to minimize the amount of server- > side state we have to manage on behalf of clients. >

15 years, 5 months

[xwiki-devs] good reading for the future regarding Software Transactional Memory (STM) and Clojure

by Niels Mayer

The concepts, as well as the Clojure implementation, presented in this article, may be useful for those designing and implementing some of the "distributed wiki" and "load-balancing" capabilities of 2.X; also for "realtime group editing" features I've seen mentioned in the survey. Also, the concepts here could help in designing finer-grained, yet "federalized/distributed" locking for concurrent access e.g. which might be needed for "collaborative" or simultaneous editing of xwiki documents, as well as load-balanced wikis. This also isn't just "starry eyed theory" -- via JSR223, these features could be integrated into the Xwiki Java API, giving a "concurrent scripting face" to the Xwiki API running on multiple wiki hosts. (see http://groups.google.com/group/clojure/msg/ad811b69d448e3db re JSR-223 status of Clojure). Software Transactional Memory <http://java.ociweb.com/mark/stm/article.html> - Overview <http://java.ociweb.com/mark/stm/article.html#Overview> - Lock-based Concurrency<http://java.ociweb.com/mark/stm/article.html#Locks> - Actor-based Concurrency<http://java.ociweb.com/mark/stm/article.html#Actors> - Transactional Memory <http://java.ociweb.com/mark/stm/article.html#TM> - Software Transactional Memory<http://java.ociweb.com/mark/stm/article.html#STM> (STM) - Persistent Data Structures<http://java.ociweb.com/mark/stm/article.html#PersistentDataStructures> - STM Implementations<http://java.ociweb.com/mark/stm/article.html#STMImplementations> - Clojure Overview<http://java.ociweb.com/mark/stm/article.html#ClojureOverview> - Clojure Reference Types<http://java.ociweb.com/mark/stm/article.html#ClojureReferenceTypes> - Clojure Validators and Watchers<http://java.ociweb.com/mark/stm/article.html#ClojureValidatorsAndWatchers> - Clojure STM - High Level<http://java.ociweb.com/mark/stm/article.html#ClojureSTMHigh> - Clojure STM - Low Level<http://java.ociweb.com/mark/stm/article.html#ClojureSTMLow> - Conclusion <http://java.ociweb.com/mark/stm/article.html#Conclusion> - References <http://java.ociweb.com/mark/stm/article.html#References> Clojure has built-in support for Concurrency: ( http://java.ociweb.com/mark/clojure/article.html#Concurrency ) > Managing concurrency with locks is hard. It requires determining which > objects need to be locked and when they need to be locked. These decisions > need to be reevaluated when the code is modified or new code is added. If a > developer forgets to lock objects that need to be locked or locks them at > the wrong times, bad things can happen. These include deadlocks<http://en.wikipedia.org/wiki/Deadlock> > and race conditions <http://en.wikipedia.org/wiki/Race_condition>. If > objects are locked unnecessarily, there is a performance penalty. Support for concurrency is one of the main reasons why many developers > choose to use Clojure. All data is immutable unless explicitly marked as > mutable by using the reference types Var<http://java.ociweb.com/mark/clojure/article.html#Vars> > , Ref <http://java.ociweb.com/mark/clojure/article.html#Refs>, Atom<http://java.ociweb.com/mark/clojure/article.html#Atoms> > and Agent <http://java.ociweb.com/mark/clojure/article.html#Agents>. > These provide safe ways to manage shared state and are described in the next > section titled "Reference Types<http://java.ociweb.com/mark/clojure/article.html#ReferenceTypes> > ". Niels http://nielsmayer.com

15 years, 5 months

[xwiki-devs] Blog Plugin Proposal

by Andreas Schaefer

Now that the Blog Upgrade to 2.0 wiki syntax comes soon to a close I want to focus on the improving its performance and ease of use. As suggested beforehand I think creating a Blog Plugin would probably the best way to accomplish that. For that I would suggest that all methods in "Code" documents in the blog (BlogCode2, CategoryCode and if needed RssCode) become part of that plugin. Beside that I am also wondering if that plugin should become part of the Core (xwiki-core) like the Feed Plugin or a regular plugin like the Scheduler Plugin which I think would be the best. Cheers Andreas Schaefer

15 years, 5 months

Re: [xwiki-devs] [Issue] Commented: (XABLOG-63) Create a Blog Plugin and Adjust the Blog Application to use it

by Andreas Schaefer

As you might have seen I uploaded the Blog Application XAR file as well as the Blog Plugin (including the source). Let me know what you think. Hopefully this could start a good discussion about it. Anyway I am going to upgrade my own Blog using the Plugin this weekend to see how it works out. Cheers - Andy On Aug 29, 2009, at 10:50 AM, Vincent Massol (JIRA) wrote: > > [ http://jira.xwiki.org/jira/browse/XABLOG-63?page=com.atlassian.jira.plugin.… > ] > > Vincent Massol commented on XABLOG-63: > -------------------------------------- > > Note that the start of a discussion on this was started on the list > and so far we're not sure we want to do it. Sergiu is against it and > I'm not sure either. There are some problems. I think we need to all > agree first before we implement this. > >> Create a Blog Plugin and Adjust the Blog Application to use it >> -------------------------------------------------------------- >> >> Key: XABLOG-63 >> URL: http://jira.xwiki.org/jira/browse/XABLOG-63 >> Project: XWiki Blog Application >> Issue Type: Improvement >> Affects Versions: 1.10 >> Reporter: Andreas Schaefer >> Fix For: Future >> >> >> Currently the entire Blog Application is powered by Velocity code. >> We should extract the non-UI code into a blog plugin to present a >> more stable API to the blog applications. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the > administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >

15 years, 5 months

[xwiki-devs] Not allowing the code macro in inline mode when there are NL inside

by Vincent Massol

Hi, Right now we support code macro in both inline and standalone modes. However the style isn't nice if the macro is inline and on several lines. For ex: This is {{code language="java"}} public class LoggingEventListener implements EventListener { } {{/code}} inline I'm proposing to test in the code macro if there are NL in the macro content and if so and if the macro is inline then generate an error explaining that the macro but not be inline to use multi line content. WDYT? Thanks -Vincent

15 years, 5 months

[xwiki-devs] toc in some dev.xwiki.org pages -> enforcing structure

by [Ricardo Rodriguez] Your EPEC Network ICT Team

Hi, Some pages in dev.xwiki.org have a table of content. For instance, http://dev.xwiki.org/xwiki/bin/view/Community/Building I guess if to add this simple table of content to pages like Building XWiki in Eclipse will ease the understanding of the whole process to newcomers like me myself. It will result something similar to the Building page. Something like http://tinyurl.com/mc6e8d. Generalizing the question, must all and every documents on dev.xwiki.org have a TOC? Is it possible, in this virtual wiki or any other hosted locally, or in a given space, enforce a structure? Something like: any document is created in DummySpace must have a heading1 followed some paragraphs, then a TOC, then any number of heading2, paragraph, heading3, paragraph and so on, so forth. Thanks! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

15 years, 5 months

[xwiki-devs] [Proposal] Staging Period?

by Vincent Massol

Hi everyone, I was thinking about the regression found on the 2.0M4 release yesterday. I think we should have an official testing period between the code freeze and the release (called the staging period) when everyone who want to help could test the release before we make it official. Something like a 2 days period for a 2 or 3 weeks release. This could be done easily with Nexus (which we have installed already - it needs to be configured). We could set it up and try it for the next release (2.1 onwards). Since it needs 2-3 days per release this would mean accounting for it in the roadmaps/timelines. That said, since a release should always be done on a branch, the devs can continue to work on the next release while the staged release is being tested. It would affect the amount of things we put in a release if we keep the same period of 2 weeks for RCs and 3 weeks for milestones but I don't think this is a problem. It just means we need to be careful not to overcommit in general. Obviously the ideal is still to have as many automated functional tests as possible and to reduce this period to the minimum. WDYT? Thanks -Vincent

15 years, 5 months

Re: [xwiki-devs] [xwiki-users] XWiki 2 ML 4 .xar import error

by Andreas Schaefer

On a side note I checked what is in SVN and built the entire application from scratch. The generic installer is failing there the same way. In addition the built from 2 days ago (8/25/09) does work fine meaning the error was introduced in the last two days. - Andreas Schaefer On Thursday, August 27, 2009, at 04:00PM, "Andreas Schaefer" <schaefera(a)me.com> wrote: >I downloaded the Generic Installer, installed it and when showing the XWiki Dashboard I get an exception from the menuview.vm caused by the DB upgrade. This is what I see first in the console: > >009-08-27 15:47:21,258 [http://localhost:8080/xwiki/bin/view/Main/] [http://localhost:8080/xwiki/bin/view/Main/?null] INFO .AbstractXWikiMigrationManager - New storage version is now [15429] >org.hibernate.MappingException: Unknown entity: com.xpn.xwiki.plugin.activitystream.impl.ActivityEventImpl > at org.hibernate.impl.SessionFactoryImpl.getEntityPersister(SessionFactoryImpl.java:550) > at org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1338) > at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187) > at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172) > at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) > >Cheers > >Andreas Schaefer >CEO of Madplanet.com Inc. >EMail: andreas.schaefer(a)madplanet.com > schaefera(a)me.com >Twitter: andy_mpc >AIM: schaefera(a)me.com > > >On Wednesday, August 26, 2009, at 06:29PM, "Dilipkumar Jadhav" <jadhav.dilipkumar(a)gmail.com> wrote: >>Hello everyone, >> >>Tried setting up XWiki 2 ML4 as a fresh installation on a test machine. >> >>The installation went fine. However, importing the .xar file for XWiki 2 ML >>4 throws the following error: >> >> >> >>Wrapped Exception: >> >> >> >>org.apache.velocity.exception.MethodInvocationException: Invocation of >>method 'save' in class com.xpn.xwiki.api.Document threw exception >>com.xpn.xwiki.XWikiException: Error number 9001 in 9: Access denied in edit >>mode on document XWiki.XWikiPreferences at /templates/admin.vm[line 58, >>column 26] >> >> at >>org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException( >>ASTMethod.java:337) >> >>. >> >> >> >>When I tried again, it takes me to the XWiki preferences page but the page >>says it is locked in edit mode by XWiki.Guest. Clicking force edit throws >>the above mentioned error again. >> >>Is anyone else too facing the same issue. Did I miss out on anything >>critical during setup. >> >>The machine is the same where a test version of XWiki 2 ML 3 works just >>fine. >> >>_______________________________________________ >>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 > >

15 years, 5 months

[xwiki-devs] m2eclipse 0.9.9 setup

by Vincent Massol

Hi everyone, Just setup m2eclipse 0.9.9. I have modified the top level pom.xml to configure it properly ie support incremental build + use a different target dir (I've chosen target-eclipse/). I'll add svn ignores to all modules for target-eclipse Let me know if you see a problem. Thanks -Vincent

15 years, 5 months

Re: [xwiki-devs] [xwiki-notifications] r22829 - in platform: core/trunk/xwiki-core/src/main/resources xwiki-applications/trunk/scheduler/src/main/resources/Scheduler xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-08-21 22:46:51 +0200 (Fri, 21 Aug 2009) > New Revision: 22829 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties > platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPlugin.java > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPluginApi.java > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPluginException.java > Log: > XASCH-35 : Allow to manually trigger a job (execute it once) > XASCH-36 : Provide a getPreviousFireTime method in the API > > Modified: platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml > =================================================================== > --- platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml 2009-08-21 20:34:10 UTC (rev 22828) > +++ platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml 2009-08-21 20:46:51 UTC (rev 22829) > @@ -205,6 +205,16 @@ > #set($deleteRedirect = $xwiki.getURL($jobObj.getName(),"delete")) > $response.sendRedirect($deleteRedirect)) > #end > + #elseif($request.do=="trigger") > + ## > + ## Trigger a job (execute it now) > + ## > + #set($ok=$scheduler.triggerJob($jobObj)) > + #if($ok==false) > + #error("$context.get('error')") > + #else > + #info("Job ~~$jobObj.get('jobName')~~ *$msg.get('xe.scheduler.triggered')*") > + #end > #end > #end > 1 $msg.get('xe.scheduler') > @@ -235,6 +245,7 @@ > #set( $ok = $!actions.put("unschedule",$doc.getURL("view","do=unschedule&amp;which=${jobHolder.fullName}")) ) > #end > #set($ok = $!actions.put("delete",$doc.getURL("view","do=delete&amp;which=${jobHolder.fullName}")) ) > + #set($ok = $!actions.put("trigger",$doc.getURL("view","do=trigger&amp;which=${jobHolder.fullName}")) ) > $job.get("jobName")|$status|$firetime| *$msg.get('xe.scheduler.jobs.infos')* : [view>$jobHolder.fullName] #if($jobHolder.hasAccessLevel("programming")) <a href="${jobHolder.getURL('inline')}">$msg.get("edit")</a> #end *$msg.get("job")* : #foreach($action in $actions.keySet()) <a href="${actions.get($action)}">$action</a> #end > > #end Some quick velocity performance tests: #set($y = "abc") #foreach($i in [0..4000000]) #set($x = "$y") #end ~~2.7s #set($y = "abc") #foreach($i in [0..4000000]) #set($x = $y) #end ~~1.8s Here, the quotes around "$y" are completely unneeded. Similarly, "abc" is more costly than 'abc'. Please think of the penguins before using so many double quotes... -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs