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

[xwiki-devs] [discussion] Remove XWatch modules for building standalone distribution
by Anca Luca 16 Sep '10

16 Sep '10

Hi devs, I updated locally XWiki Watch trunk to work with XWiki Enterprise 2.3.2 (right now it's 1.8.4 version) and I would like to commit this in the Watch trunk. There is a little issue though, with the modules for building the standalone distribution(s) (distribution, database, installers, web), which need to be handled, for which there are 3 options: 0/ update the distribution related modules to make them compatible with 2.3 and the process is not straightforward due to Watch particularities (this would mean extra work and since I don't know when I will be able to do it, it means not commit right away) 1A/ remove the distribution related modules from the watch trunk and leave it installable as a .xar + component (as described at http://watch.xwiki.org/xwiki/bin/view/Main/Installation#HXWikiWatchoveranex… ) drawback is that users installing it need to edit the web.xml which is not that easy for everyone. 1B/ leave the distribution related modules, just exclude them from the default build since they will fail, until 0/ can be fixed right. I would go for 1B since I think partial update to 2.3 is better than nothing (current version on 1.8.4 is not really useful in most cases) and earlier is better than later. WDYT? Thanks, Anca

5 6

[xwiki-devs] [VOTE] Move component related events to their own project
by Thomas Mortagne 15 Sep '10

15 Sep '10

Hi devs, For http://jira.xwiki.org/jira/browse/XWIKI-5490 I need to make ObservationManager itself listen to ComponentDescriptorAddedEvent events. There is two issue here: - currently ComponentDescriptorAddedEvent is in the same project than the component manager implemenation which is pretty much the same thing as behing internal since there is no reason to force to depends on a specific implementation of component manager just to listen on some generic events that has nothing to do with it - i can move them to component-api because that would produce a circular dependency with observation project which depends on component-api So the only technical solution I can see is to create a new project with theses events. I propose to name it xwiki-core-component-observation and to move ComponentEventManager from component-api to it too. Note: i took ObservationManager here because it's a core one but a lot of other components will probably have the exact same need to support properly installed/uninstalled extensions WDYT ? -- Thomas Mortagne

4 4

[xwiki-devs] XEclipse part of URL to xwiki is hardcoded
by Andriy Vovchyna 15 Sep '10

15 Sep '10

Hi, We meet one unpleasant issue with current XEclipse (standalone version <http://forge.objectweb.org/project/download.php?group_id=170&file_id=11944> xwiki-eclipse-rcp-win32-win32-x86-1.2-rc-1.zip) We tried to use XEclipse for our xwiki based application browsing. But when we are trying to find some object stored in a page we are getting error "This data manager is connected to an XWiki that does not support object management." After deep investigation we found problem place in XEclipse code. There is hardcoded "expectation" of "xwiki" string in URL of connection in DataNamager.Connect() http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse. core/src/main/java/org/xwiki/eclipse/core/DataManager.java. public void connect() throws XWikiEclipseException, CoreException { ..... if (serverInfo.getBaseUrl().contains("xwiki")) { ...... } else { /* We are talking to a confluence server */ .... supportedFunctionalities.remove(Functionality.OBJECTS); ..... } .... } So, simple fixing of problem is renaming of web context on xwiki web server (e.g. war file renaming) with adding "xwiki" string. Are there plans to move this "hardcoding" on the connection configuration level (UI options like version selections - xwiki, confluence etc.)? Thanks, Andriy V.

1 0

15 Sep '10

On 09/15/2010 06:34 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2010-09-15 17:34:58 +0200 (Wed, 15 Sep 2010) > New Revision: 31119 [snip] > Property changes on: platform/web/branches/xwiki-web-2.4/standard > ___________________________________________________________________ > Added: svn:mergeinfo > + /platform/web/trunk/standard:31118 > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/icons/silk > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/prototype/prototype.js > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/scriptaculous > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/xwiki/accordion/accordion.js > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/xwiki/chartwizard/chwSampleBarChart.png > ___________________________________________________________________ > Deleted: svn:mergeinfo > - ..do you know how can we get rid of this? It makes the diff almost unreadable. Thanks, Marius

1 0

[xwiki-devs] [VOTE] Separate observation API and implementation
by Thomas Mortagne 15 Sep '10

15 Sep '10

Hi devs, Following "[VOTE] Move component related events to their own project" I also need to separate api and implementation in observation project because component-observation depends on observation api and i need to make observation manager listen to component events which mean depending on component-observation. Here is my +1 Thanks, -- Thomas Mortagne

6 5

Re: [xwiki-devs] [foaf-protocols] DNS problem with foafssl.org -> myxwiki
by Henry Story 14 Sep '10

14 Sep '10

I seem to have DNS problems on myxwiki. I can't yet tell if this is a problem with foafssl.org or with myxwiki.org, but I think it is with xwiki. Below is an extract of what Dirk (Chief Architect of the BBC) has to say On 14 Sep 2010, at 21:08, Dirk-Willem van Gulik wrote: > Op 14 sep 2010, om 21:59 heeft Henry Story het volgende geschreven: > >> That has not been updated for a while it seems, since 2000 at least >> http://sourceforge.net/projects/dnswalk/files/ > > I suspect that DNS has not changed that much since then. > >> # dig ns myxwiki.org >> >> ; <<>> DiG 9.3.3rc2 <<>> ns myxwiki.org > > Ok. > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 > > So an answer; but whatever answers is not authoritive. >> >> myxwiki.org. 8 IN NS lanai.xpertnet.biz. >> myxwiki.org. 8 IN NS maui.xpertnet.biz. >> myxwiki.org. 8 IN NS ns-fr.xpertnet.biz. >> > These should be auhtoriative. >> >> # dig -t any @maui.xpertnet.biz > > So you are asking these. > >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 > > And no answer. > >> ;; AUTHORITY SECTION: >> . 518400 IN NS A.ROOT-SERVERS.NET. >> > And defers you to the root servers. And it is sure of that. > > -> conclusion - this guy is not configured as your dns server; i.e. it does not know your zone. > >> # dig -t any @ns-fr.xpertnet.biz >> [[ AT THIS POINT IT HANGS FOR A WHILE]] >> ; <<>> DiG 9.3.3rc2 <<>> -t any @ns-fr.xpertnet.biz >> ; (1 server found) >> ;; global options: printcmd >> ;; connection timed out; no servers could be reached > > And this guy is not running at all. Or in other words - your entire domain is foobar - but luckily not with huge TTL's or anything - so it is not hard to recover; either have the authoritive servers fixed - or move it somewhere else. If you are stuck - let me know - happy to run some zones over here or pull zones from SVN/hidden-master. If I run this from a server in Ireland I get $ dig -t any @ns-fr.xpertnet.biz ; <<>> DiG 9.6.0-APPLE-P2 <<>> -t any @ns-fr.xpertnet.biz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 55036 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; Query time: 39 msec ;; SERVER: 188.165.123.33#53(188.165.123.33) ;; WHEN: Tue Sep 14 22:31:55 2010 ;; MSG SIZE rcvd: 17 Which sounds like the problem is the same here. > > Dw. Social Web Architect http://bblfish.net/

1 0

[xwiki-devs] I'd like to block clierr from breaking the build (Re: [xwiki-notifications] r31093 - in platform/core/trunk/xwiki-core: . src/main/java/com/xpn/xwiki/api)
by Caleb James DeLisle 14 Sep '10

14 Sep '10

I removed a method which was inaccessible to any code which might use it: protected BaseProperty getBaseProperty() and made final a field which is not altered anywhere. Assuming nobody has extended c.x.x.api.* these are not api breaks. I would like to block clierr from breaking the build rather than merging out this change. WDYT? Caleb cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-09-14 12:03:32 +0200 (Tue, 14 Sep 2010) > New Revision: 31093 > > Modified: > platform/core/trunk/xwiki-core/pom.xml > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Element.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Property.java > Log: > [cleanup] Documented c.x.x.api.Property, removed an unnecessary override and an unusable method, and made an un-reassignable field final. > > Modified: platform/core/trunk/xwiki-core/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-core/pom.xml 2010-09-14 09:14:38 UTC (rev 31092) > +++ platform/core/trunk/xwiki-core/pom.xml 2010-09-14 10:03:32 UTC (rev 31093) > @@ -896,7 +896,6 @@ > **/api/Document.java, > **/api/DocumentSection.java, > **/api/Object.java, > - **/api/Property.java, > **/api/Util.java, > **/api/XWiki.java, > **/atom/lifeblog/LifeblogServices.java, > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Element.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Element.java 2010-09-14 09:14:38 UTC (rev 31092) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Element.java 2010-09-14 10:03:32 UTC (rev 31093) > @@ -33,7 +33,7 @@ > public class Element extends Api > { > /** The internal element which this wraps. */ > - protected BaseElement element; > + protected final BaseElement element; > > /** > * The Constructor. > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Property.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Property.java 2010-09-14 09:14:38 UTC (rev 31092) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Property.java 2010-09-14 10:03:32 UTC (rev 31093) > @@ -18,28 +18,33 @@ > * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > * > */ > + > package com.xpn.xwiki.api; > > import com.xpn.xwiki.XWikiContext; > import com.xpn.xwiki.objects.BaseProperty; > > +/** > + * Property is a single attribute of an XWiki {@link com.xpn.xwiki.api.Object}. > + * > + * @version $Id$ > + */ > public class Property extends Element > { > + /** > + * The Constructor. > + * > + * @param property the internal {@link com.xpn.xwiki.objects.BaseProperty} to wrap. > + * @param context the XWikiContext which may be used to get information about the current request. > + */ > public Property(BaseProperty property, XWikiContext context) > { > super(property, context); > } > > - protected BaseProperty getBaseProperty() > - { > - return (BaseProperty) element; > - } > - > - public String getName() > - { > - return element.getName(); > - } > - > + /** > + * @return the internal {@link com.xpn.xwiki.objects.BaseProperty} which this Property wraps. > + */ > public BaseProperty getProperty() > { > if (hasProgrammingRights()) { > @@ -49,8 +54,12 @@ > } > } > > + /** > + * @return the actual value of the property, as a String, Number or List. > + */ > public java.lang.Object getValue() > { > + // This is evil, any property which happens to be called 'password' will be masked. TODO fix. > if (element.getName().equals("password") > && !getXWikiContext().getWiki().getRightService().hasProgrammingRights( > getXWikiContext())) { > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications >

2 1

[xwiki-devs] [vote] Integrate CSRF protection into XWiki 2.5
by Alex Busenius 14 Sep '10

14 Sep '10

Hi devs, I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs. JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed. The steps to do would be: 1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages). Here is my +1 WDYT? Thanks, Alex

5 6

[xwiki-devs] Extension Manager first working POC !
by Thomas Mortagne 14 Sep '10

14 Sep '10

Hi xwikiers, Since May and actively since end of August I'm working on a POC for the future (long awaited) Extension Manager. It's now in a state where you can play with it a bit ! So here is a quick advertisement. You can find it on http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-extension/ What it does already: - display remote extension and its dependencies as a tree - install remote extension and its dependencies from repositories - framework support any kind of extension using ExtensionInstaller component interface but only jar installer is implemented right now - framework support any kind of repository using RepositoryFactory component interface but only maven is implemented right now - load installed application when XWiki starts Critical features not yet supported: - miscellaneous rights protections in extension manager script service - uninstall/upgrade support: need to find a way to remove a jar from classloader. Note that you can remove an extension from local repository and restart. - xar installer: just need to provide a ExtensionInstaller implementation with role hint "xar" since this needs access to the whole model the first version will probably be implemented with old APIs (XWikiDocument, etc.) on xwiki-core side - install extension not coming from a repository: the current API is very repository centric but you can do it "by hand" by putting directly the extension jar file in the local repository. - real descriptors in local repository for installed extensions (to store in a repository independent way extension information as well as some local only metadas like the fact that an extension as been installed as a dependency of another etc.) - others on http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-extension/README.t… I'm preparing some design documentation that will go on http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerProposal but i don't have much time right now so it will probably be tomorrow (GMT). The current state is not final at all but it still introduce a lot of APIs and design, lets call it an over designed POC. It needs to be discussed in all it's aspects before having its experimental tag removed. The plan is to distribute it with XE coming with 2.5 whatever it's state (when it does not represent a risk for XE obviously) as an experimental playground with all the required warnings in the UI and promote it when we are happy with a first version. Thanks, -- Thomas Mortagne

3 3

Re: [xwiki-devs] [xwiki-notifications] r31088 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources
by Vincent Massol 14 Sep '10

14 Sep '10

Although this makes sense from a code and organisation POV, I don't think it makes sense from a user POV. Personally I'd prefer to keep the old style since it's less confusing for users and more logical. I know there's a risk of namespace clash but it's very small and can be solved by changing property names if need be. What do others think? I'm not too hung up on this but I want to make it as easy as possible for users and prevent the "WTF?" feeling (aka as the "don't make me think" feeling) :) Thanks -Vincent On Sep 14, 2010, at 9:00 AM, mflorea (SVN) wrote: > Author: mflorea > Date: 2010-09-14 09:00:57 +0200 (Tue, 14 Sep 2010) > New Revision: 31088 > > Modified: > platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm > Log: > XTCONFRES-50: Add configuration for including image dimensions in the image URL and for limiting image dimensions > * Changed "rendering." prefix to "rendering.xwiki." for XWiki-specific rendering configuration properties > > > Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm > =================================================================== > --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm 2010-09-14 06:58:39 UTC (rev 31087) > +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm 2010-09-14 07:00:57 UTC (rev 31088) > @@ -68,7 +68,7 @@ > #-# downloaded, improving thus the page loading speed. > #-# > #-# Default value is true. > -# rendering.includeImageDimensionsInImageURL = true > +# rendering.xwiki.imageDimensionsIncludedInImageURL = true > > #-# [Since 2.5M2] > #-# One way to improve page load speed is to resize images on the server side just before rendering the page. The > @@ -79,13 +79,13 @@ > #-# The default value is -1 which means image width is not limited by default. Use a value greater than 0 to limit the > #-# image width (pixels). Note that the aspect ratio is kept even when both the width and the height of the image are > #-# limited. > -# rendering.imageWidthLimit = 1024 > -# rendering.imageWidthLimit = -1 > +# rendering.xwiki.imageWidthLimit = 1024 > +# rendering.xwiki.imageWidthLimit = -1 > > #-# [Since 2.5M2] > #-# See rendering.imageWidthLimit > -# rendering.imageHeightLimit = 768 > -# rendering.imageHeightLimit = -1 > +# rendering.xwiki.imageHeightLimit = 768 > +# rendering.xwiki.imageHeightLimit = -1 > > #------------------------------------------------------------------------------------- > # Cache >

3 2