xwiki-devs May 2008

xwiki-devs@xwiki.org

53 participants
158 discussions

Re: [xwiki-devs] [xwiki-notifications] r9958 - xwiki-platform/web/trunk/gwt/src/main/java/com/xpn/xwiki/gwt/api/client/app

by Vincent Massol

Hi Anca, A possible improvement below. On May 28, 2008, at 12:47 PM, lucaa (SVN) wrote: > Author: lucaa > Date: 2008-05-28 12:47:56 +0200 (Wed, 28 May 2008) > New Revision: 9958 > > Modified: > xwiki-platform/web/trunk/gwt/src/main/java/com/xpn/xwiki/gwt/api/ > client/app/XWikiGWTDefaultApp.java > Log: > XWIKI-2408: Default XWikiService URL not created correctly in hosted > mode in XWikiGWTDefaultApp > > * added a test for the ending character of the module base URL > returned by GWT > > > Modified: xwiki-platform/web/trunk/gwt/src/main/java/com/xpn/xwiki/ > gwt/api/client/app/XWikiGWTDefaultApp.java > =================================================================== > --- xwiki-platform/web/trunk/gwt/src/main/java/com/xpn/xwiki/gwt/api/ > client/app/XWikiGWTDefaultApp.java 2008-05-28 10:40:44 UTC (rev 9957) > +++ xwiki-platform/web/trunk/gwt/src/main/java/com/xpn/xwiki/gwt/api/ > client/app/XWikiGWTDefaultApp.java 2008-05-28 10:47:56 UTC (rev 9958) > @@ -181,10 +181,15 @@ > if (serviceInstance == null) { > serviceInstance = (XWikiServiceAsync) > GWT.create(XWikiService.class); > String defaultXWikiService; > - if (GWT.isScript()) > + if (GWT.isScript()) { > defaultXWikiService = > XWikiGWTAppConstants.XWIKI_DEFAULT_BASE_URL + > XWikiGWTAppConstants.XWIKI_DEFAULT_SERVICE; > - else > - defaultXWikiService = GWT.getModuleBaseURL() + > XWikiGWTAppConstants.XWIKI_DEFAULT_SERVICE; > + } else { > + String moduleBaseURL = GWT.getModuleBaseURL(); > + if (moduleBaseURL.endsWith("/")) { > + moduleBaseURL = moduleBaseURL.substring(0, > moduleBaseURL.length() - 1); > + } // Here, explain why we need to remove the last "/" if it's there and why it's not deterministic String moduleBaseURL = StringUtils.chomp(GWT.getModuleBaseURL(), "/"); > > + defaultXWikiService = moduleBaseURL + > XWikiGWTAppConstants.XWIKI_DEFAULT_SERVICE; > + } > ((ServiceDefTarget) > serviceInstance).setServiceEntryPoint(getParam("xwikiservice" , > defaultXWikiService)); > } > return serviceInstance; Thanks -Vincent

16 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r9956 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki

by Vincent Massol

Thomas, does this mean it's now set in 2 places? If so I think that's not correct. Thanks -Vincent On May 27, 2008, at 10:58 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-05-27 22:58:40 +0200 (Tue, 27 May 2008) > New Revision: 9956 > > Modified: > xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java > Log: > XWIKI-2367: Makes ComponentManager getable without the XWikiContext > * Reset ComponentManager in XWiki.initXWiki as shared-test can't > call Utils.setComponentManager > > Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/ > xwiki/XWiki.java > =================================================================== > --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-05-27 19:37:05 UTC (rev 9955) > +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-05-27 20:58:40 UTC (rev 9956) > @@ -737,6 +737,11 @@ > public void initXWiki(XWikiConfig config, XWikiContext context, > XWikiEngineContext engine_context, boolean noupdate) throws > XWikiException > { > + // Statically store the component manager in {@link Utils} > to be able to access it without > + // the context. > + Utils.setComponentManager((ComponentManager) context > + .get(ComponentManager.class.getName())); > + > setEngineContext(engine_context); > context.setWiki(this);

16 years, 3 months

[xwiki-devs] Choosing a JIRA issue ...

by Asiri Rathnayake

Hi Devs, I've gone through xwiki-core JIRA list and i selected following three issues out of which i wish to pick a one. But before jumping in, i need some guidance on which one to select. I thought it's best to ask from the list since i might not be aware of the severity of these issues. * XWIKI-2191 <http://jira.xwiki.org/jira/browse/XWIKI-2191> - (When user logout, his pages locks should be removed - Reported by Thomas Mortagne) * XWIKI-1538 <http://jira.xwiki.org/jira/browse/XWIKI-1538> - (Improve performance by efficiently using synchronized code - Reported by Sergiu Dumitriu) * XWIKI-671 <http://jira.xwiki.org/jira/browse/XWIKI-671> - (Refactor the code using deprecated API - Reported by Sergiu Dumitriu) Thank you very much for your time. - Asiri

16 years, 3 months

[xwiki-devs] XWiki crashes on high load?

by Squirrel

Hi guys, Some days ago may server got some high CPU load and was unavailable to any web-request. When I checked what causes it I found out it was Tomcat5.5. So I did run some benchmark tests with ab (Apache Benchmark) and found out that I can repeatedly crash Tomcat5.5 with some 'high' concurrent values (ab -n 400 -c 100 http://domain.com/xwiki/bin/view/Main/). In some posts it was hinted that not Tomcat itself crashs, but the webapp itself and the developers may be able to track what causes the loop. Are you able to reproduce that? Is it really a XWiki issue or is it indeed a Java/Tomcat issue? Can I help in someway? Cheers My system ---------------- Dedicated Server running Debian 4 1024MB RAM 100Mbit/s Tomcat5.5 Java JDK 1.5 Apache2 XWiki 1.3.1.8931

16 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r9945 - xwiki-extensions/xwiki-eclipse/trunk

by Vincent Massol

Hi Fabio, In the new instructions below I don't see how we can build the RCP version. Thanks -Vincent On May 27, 2008, at 5:25 PM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2008-05-27 17:25:07 +0200 (Tue, 27 May 2008) > New Revision: 9945 > > Modified: > xwiki-extensions/xwiki-eclipse/trunk/README > Log: > Updated build instructions > > Modified: xwiki-extensions/xwiki-eclipse/trunk/README > =================================================================== > --- xwiki-extensions/xwiki-eclipse/trunk/README 2008-05-27 15:07:43 > UTC (rev 9944) > +++ xwiki-extensions/xwiki-eclipse/trunk/README 2008-05-27 15:25:07 > UTC (rev 9945) > @@ -1,6 +1,39 @@ > The directory structure may appear strange but it's required by the > Maven PDE plugin. > See http://mojo.codehaus.org/pde-maven-plugin/usage.html for more > details. > > +A new, refactored and improved version of XWiki Eclipse is now > available in the repository. > +This version has a new architecture and a better integration with > the Eclipse platform. > + > +This new version is made of the following plugins and features: > + * org.xwiki.eclipse.core > + * org.xwiki.eclipse.ui > + * org.xwiki.eclipse.xmlrpc > + * org.xwiki.eclipse.feature > + > +In order to build: > + > +1) Checkout the trunk: "svn co http://svn.xwiki.org/svnroot/xwiki/xwiki-extensions/xwiki-eclipse/trunk/ > " > +2) cd to trunk/features/org.xwiki.eclipse.feature. > +3) Do a "mvn -DeclipseInstall=/AbsolutePath/To/Your/Eclipse/ > Installation" compile. > +4) You should now have a > org.xwiki.eclipse.feature_1.2.0.SNAPSHOT.bin.dist.zip file in this > directory. > + > +In order to install: > + > +1) Unzip org.xwiki.eclipse.feature_1.2.0.SNAPSHOT.bin.dist.zip into > your Eclipse directory. > +2) Run Eclipse. > +2.1) If XWiki Eclipse doesn't show up anywhere (for example when > you open the Window->Show view->Other... dialog) > + then you might need to re-run Eclipse by specifying the -clean > switch on the command line. > + > +You can start using XWiki Eclipse by creating a connection using > the File->New->Other... menu command. > +XWiki connections will be accessible from the Project Explorer and > XWiki Navigator. > + > +Enjoy. > + > + > + > + > ------------------------------------------------------------------------------------------------------------------------ > +* This refers to the previous version of XWiki Eclipse still > available on the SVN but deprecated. > + > ------------------------------------------------------------------------------------------------------------------------ > There are 2 builds: > > * The plugin build which generates an Eclipse plugin for XEclipse. > It's located in plugins/org.xwiki.eclipse

16 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r9932 - xwiki-platform/web/trunk/standard/src/main/webapp/templates

by Vincent Massol

On May 27, 2008, at 3:10 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-05-27 15:10:39 +0200 (Tue, 27 May 2008) > New Revision: 9932 > > Modified: > xwiki-platform/web/trunk/standard/src/main/webapp/templates/ > historyinline.vm > Log: > XWIKI-2405: The history page displays dates in the 12 hours format > > > Modified: xwiki-platform/web/trunk/standard/src/main/webapp/ > templates/historyinline.vm > =================================================================== > --- xwiki-platform/web/trunk/standard/src/main/webapp/templates/ > historyinline.vm 2008-05-27 11:20:25 UTC (rev 9931) > +++ xwiki-platform/web/trunk/standard/src/main/webapp/templates/ > historyinline.vm 2008-05-27 13:10:39 UTC (rev 9932) > @@ -66,7 +66,7 @@ > <td><input type="radio" name="rev2" value="$version" /></td> > <td><a href="$tdoc.getURL("viewrev","rev=$version")"> > $version</a></td> > <td>$xwiki.getLocalUserName($revinfo.author)</td> > - <td>$xwiki.formatDate($revinfo.date, "dd/MM/yyyy hh:mm")</ > td> > + <td>$xwiki.formatDate($revinfo.date, "dd/MM/yyyy HH:mm")</ > td> Shouldn't this use the default format instead? public String formatDate(Date date) This format is defined in the wiki preferences. Thanks -Vincent

16 years, 3 months

[xwiki-devs] XEclipse committed to trunk

by Fabio Mancinelli

Dear all, I have just committed the new XEclipse infrastructure to the trunk. For building and installation instruction you can go to http://svn.xwiki.org/svnroot/xwiki/xwiki-extensions/xwiki-eclipse/trunk/REA… As I have said in a previous message this version has a new architecture and a better integration with the Eclipse platform and has a more stable and flexible caching system that can be easily extended. It is almost feature equivalent with the previous one: I only need to figure out how to integrate Eclipse working sets and to re-integrate RCP (so at the moment the new XEclipse is only available as a platform plugin). I am working on this. The most important new feature, though, is object edition. XEclipse works fine with both Eclipse 3.3.x and 3.4Mx and can be compiled with one of these two platforms. I encourage you to install and try it. For GSoCers: 1) Malaka, editors are located in the org.xwiki.eclipse.ui plugins in the org.xwiki.eclipse.ui.editors.* packages. As you will notice these are full fledged editors that are not configured for any content- assist, syntax highlighting support (which you are going to write soon :)) At some point you will need to plug your infrastructure to the org.xwiki.eclipse.ui.editors.PageEditor and org.xwiki.eclipse.ui.editors.propertyEditors.TextAreaPropertyEditor. We will talk about this later. 2) As far as I understood, Enygma is working on the Eclipse-offline project that eventually will be integrated into XWiki Eclipse. It could be interesting for him to have a look at the org.xwiki.eclipse.core.storage.IDataStorage interface. This is an interface that is currently used by the DataManager for handling data exchange between a "master" and "slave" XWiki storages (i.e., a remote XWiki and a local Cache). The DataManager should be fully configurable so, for example, it should be possible to use two remote XWikis as master and slave. The only problem, right now, is that the slave data storage semantics should preserve the version number at each save, and the RemoteXWikiDataStorage does not have such a semantics right now. Cheers, Fabio

16 years, 3 months

Re: [xwiki-devs] XEclipse odd behaviour.

by Enygma

I thought of removing every MouseEnter or MouseHover event by removing listeners attached to those events for the browser object but I have stumbled upon a very weird thing in SWT: There is no getListeners method for a Control/Widget. I googled it and found out that only from 3.4M Eclipse thought of adding this method. The only mechanism orientated in this direction I found is the ListenerList class which is for handling listeners but that implies that you subclass every control you need to have the getListeners method which is very lame. I can not imagine how SWT lived so far without such a basic functionality. I know it is not very commonly required to remove a listener, but I for one used it a couple of times. Anyway, does anyone have a solution for this or is it just the wrong approach? P.S.: Keep in mind that I am experiencing this anomaly only in Fedora 9, from what I see.

16 years, 3 months

Re: [xwiki-devs] [proposal] Enable some commons-lang classes as velocity tools

by Jean-Vincent Drean

> Sergiu Dumitriu wrote: > > Hi devs, > I'd like to enable some classes from the commons-lang library as velocity tools. > [snip] > Another issue is the name of the velocity variables for these. Isn't escapetool a bit too long? I'd drop the tool part where the remaining name does not cause conflicts, so that we would have: > $escape $escapeUtils $alternator $iterator $sort $math $arrayUtils $booleanUtils $numberUtils $stringUtils $wordUtils $dateUtils $dateFormatUtils $durationFormatUtils $randomStringUtils $randomNumberUtils Generally +1. About the naming : * I'd prefer to stick to $sometool (or even better $someTool) since it allow to differentiate user defined velocity variables from velocity tools easily, * I'd like capitalization ($someTool instead of $sometool) and it seems that we don't have a convention about this (see xwikivars.vm for example) for the moment. -- Jean-Vincent Drean

16 years, 3 months

[xwiki-devs] Cache needs

by Vincent Massol

Hi Thomas, I know you're working on the new cache component (btw would be nice if you could send an email with your planned architecture/api so that it can be reviewed - like show the APIs) so I thought I should give you some needs/ideas I have on this topic. * We need several types of local caches. I can see at least the following types: - a timed cache. I need this for example to cache macros - a cache with a fixed given capacity and expiring the oldest entries (not really sure where we need this right now but it looks common enough) - a cache with a fixed given capacity and expiring the least accessed entries (not really sure where we need this right now but it looks common enough) - a cache with unlimited capacity and bound only by the memory available. The way to implement this is using PhantomReference. Basically it's the JVM that calls back the reference to tell it it needs memory. I was told that the new google collections api have some code that do this (I think FinalizablePhantomReference). This cache is the one I would use to save wiki pages' AST in memory. Of course we shouldn't implement anything ourselves and we should use existing framework(s) underneath our own API for the Cache API. WDYT? Links: * http://www.realjenius.com/node/377 * http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=918224… Thanks -Vincent

16 years, 3 months

← Newer
1
2
3
4
5
6
7
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2008