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

Re: [xwiki-devs] [GSoC] Responsive Skin
by Jonathan Solichin 24 May '12

24 May '12

Hello Friends, Here is a new set of mockup. [] http://jssolichin.com/public/4/1.%20Home.png [] http://jssolichin.com/public/4/2.%20Home-comm.png [] http://jssolichin.com/public/4/3.%20Home-navhover.png [] http://jssolichin.com/public/4/4.%20mobile.png [] http://jssolichin.com/public/4/5.%20mobile-menu.png What do you guys think? The idea is that the sidebar would be replicated, but hidden in the mobile (except for the hint that it's there. Everything non-content is combined. I think that if you are looking at the comments/attachment/other sections, you are not thinking about navigating away from the page so the nav section is not that needed. So this consolidates/saves space. Let me know if this is the wrong mentality. Thanks! Jonathan Solichin

3 3

[xwiki-devs] Fwd: [CVE-2012-2098] Apache Commons Compress and Apache Ant denial of service vulnerability
by Vincent Massol 23 May '12

23 May '12

Funny that this should arrive today in my inbox… ;) -Vincent Begin forwarded message: > From: Stefan Bodewig <bodewig(a)apache.org> > Subject: [CVE-2012-2098] Apache Commons Compress and Apache Ant denial of service vulnerability > Date: May 23, 2012 4:00:48 PM GMT+02:00 > To: dev(a)commons.apache.org, user(a)commons.apache.org, dev(a)ant.apache.org, user(a)ant.apache.org, announce(a)apache.org, security(a)apache.org, full-disclosure(a)lists.grok.org.uk, bugtraq(a)securityfocus.com, David Jorm <djorm(a)redhat.com> > > CVE-2012-2098: Apache Commons Compress and Apache Ant denial of service > vulnerability > > Severity: Low > > Vendor: > The Apache Software Foundation > > Versions Affected: > Apache Commons Compress 1.0 to 1.4 > Apache Ant 1.5 to 1.8.3 > > Description: > The bzip2 compressing streams in Apache Commons Compress and Apache Ant > internally use sorting algorithms with unacceptable worst-case > performance on very repetitive inputs. A specially crafted input to > Compress' BZip2CompressorOutputStream or Ant's <bzip2> task can be used > to make the process spend a very long time while using up all available > processing time effectively leading to a denial of service. > > Mitigation: > Commons Compress users should upgrade to 1.4.1 > Ant users should upgrade to 1.8.4 > > Credit: > This issue was discovered by David Jorm of the Red Hat Security Response > Team. > > References: > http://commons.apache.org/compress/security.html > http://ant.apache.org/security.html > > Stefan Bodewig

2 1

[xwiki-devs] [VOTE] Stop bundling legacy .jar files in enterprise and manager.
by Caleb James DeLisle 23 May '12

23 May '12

Hi, I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this. I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them. Why: #1. Not removing API is obviously unsustainable in the long term. #2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion. #3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file. Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing. Caleb

5 8

[xwiki-devs] Read-only DB and XWiki.getUserClass()
by Alexander Pokahr 23 May '12

23 May '12

Dear XWiki developers, the last couple of days I tried setting up two redundant XWiki servers using MySQL master/slave replication. Unfortunately MySQL replication produced errors, because the slave wiki also wrote on the DB. Thus, I revoked update privileges from the xwiki DB user on the slave. Now replication worked, but the slave XWiki failed to start and instead always threw an exception in XWiki.getUserClass(). Unlike mentioned in previous findings by others (http://lists.xwiki.org/pipermail/devs/2011-January/045992.html) currently XWiki seems to be unable to operate on a read-only DB. I think I tracked the issue to the following code in XWiki.getUserClass() (lines 3000ff, shown below). As you can see, the if block only operates on a local string builder, but does not change the page. Nevertheless, needsUpdate is set to true, thus forcing XWiki to save the document, which doesn't work on a read-only DB. This happens every time XWiki starts. // Email field custom display (email obfuscation). PropertyClass emailProperty = (PropertyClass) bclass.get("email"); if (!emailProperty.isCustomDisplayed(context)) { StringBuilder builder = new StringBuilder(); builder.append("{{velocity}}\n"); builder.append("#if ($xcontext.action == 'edit' || $xcontext.action == 'inline')\n"); // Line broken in 2 because it was too long. builder.append(" {{html}}<input id='$prefix$name' type='text'"); builder.append(" name='$prefix$name' value='$value' />{{/html}}\n"); builder.append("#else\n"); builder.append(" ## Allow $obfuscateEmail to be set in some other place.\n"); builder.append(" #if(\"$obfuscateEmail\" == 'false')\n"); builder.append(" $value\n"); builder.append(" #else\n"); builder.append(" $value.replaceAll('@.*', '@ xxxxxx')\n"); builder.append(" #end\n"); builder.append("#end\n"); builder.append("{{/velocity}}"); needsUpdate = true; } ... if (needsUpdate) { saveDocument(doc, context); } Without the 'needsUpdate = true;' the slave xwiki now starts fine and seems to work properly. Note, that i tried setting 'xwiki.readonly=yes' in xwiki.cfg as also recommended in the previous thread, but that had no effect on the above issue. I would prefer being able to use the official xwiki distribution instead of my own fixed build. Is there any chance that a fix to the above issue (given my evaluation is indeed correct) will make it into some upcoming release/milestone? Unfortunately, I do not understand the intention of the email obfuscation code above, otherwise I maybe would have been able to supply a patch myself. Kind regards and thanks in advance, Alex

3 2

[xwiki-devs] [Proposal] Move location of HSQLDB database files to the XWiki Permanent Directory
by Vincent Massol 23 May '12

23 May '12

8 7

[xwiki-devs] [proposal] New way to make sure temp files are deleted.
by Caleb James DeLisle 22 May '12

22 May '12

Hi, In order to fix XWIKI-7748 and XWIKI-7749, we need a plan for deleting temporary file. XWikiAttachmentContent uses File.deleteOnExit(), but in Sun's implementation, deleteOnExit() only deletes on a *clean* exit, in a crash it can't delete the files but it doesn't tag them so they can be deleted in the next run either. Since temp files are usually pseudo-randomly named, they are impossible to find and delete later. I propose that we create a subdirectory, `java.io.tmpdir`/xwiki/ which will be removed on application exit. If the jvm crashes, the files will be removed next time around. Then alter ApplicationContext.getTemporaryDirectory() to yield this directory. WDYT? Caleb

4 11

[xwiki-devs] [GSOC] First coding period started
by Eduard Moraru 22 May '12

22 May '12

Hello students, As you all probably know, the community bonding period is over and the first coding period has just started. I hope you enjoyed the bonding period and had the chance to get up to speed with XWiki's way of doing things and the code. According to the timeline [1], you have 7 weeks of work available until the mid-term evaluation. Please make sure you have the conditions for success [2] in mind throughout all of the 12 total weeks of GSoC coding. As a reminder: For the ones that filled in the 'Progress' field on your project's page, please remember to update it periodically, as instructed [3] and, for the ones that did not fill it, please do so ASAP. Happy coding! - Eduard ---------- [1] http://www.google-melange.com/gsoc/events/google/gsoc2012 [2] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HConditionsf… [3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr…

1 0

[xwiki-devs] [Discussion] Should we re-think the way we determine what is user-public code ?
by Jerome Velociter 22 May '12

22 May '12

Hi devs, Following a thread on github, here's a mail to start a discussion about the way we determine what is API or not. Our current rule is : 1) "Non user-public code must be located in an internal package just after the module name." c.f. [1] (implied that what is not in internal is public) 2) What is public has to go through the deprecation strategy described at [2]). I think the rule is good but there is a problem in its enforcement right now, mainly because : * There is some legacy code where 1) does not make much sense because it "arrived too late at the party" (for example in oldcore) * There is some "new code" where some classes/interfaces hasn't been made internal when they likely should have been. For example I've been playing around with the WYSIWYG recently and in the client module, there are *only* user-public classes [3]. I'm sure we can find a lot of examples of such practice and I'm OK to work and list some if needed. The problem I see coming is that the cost of refactoring will increase for a lot of modules/classes/etc., while at the same time those modules should not have been API to begin with, and are probably not even being used as such by anybody. The risk is our progress being bogged down for no good reason. So what can we do to enforce a solid backward-compatibility policy for API code, while keeping flexibility in XWiki internals ? We could : A) Not do anything :) Maybe it's just me that sees this as a potential problem. B) Do the work to move everything that ought to be in an internal package to an internal package. But I don't believe we're reading to make that effort, so that's not going to happen IMHO C) Do the work to move what ought to be in an internal package "on the fly", when refactoring code. That would be on a case-by-case case, probably requiring a mail to announce it ; or more coercive, a VOTE. C) We change the rule. We could decide that instead of having everything be an API and enforce the "internal" status in a special package, we take it the other way around and Day everything is internal, and APIs needs to be in a special package (or be annotated with a special annotation). This could also be the opportunity to introduce another rule that says that such APIs should be referenced in their own module documentation on extensions.xwiki.org. What do you think ? Jerome. [1] http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HPackagenames [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar…) [3] https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi… -- Jérôme Velociter Winesquare http://www.winesquare.net/

3 5

Re: [xwiki-devs] [xwiki-notifications] [Issue] (XWIKI-7841) XWiki.DatePickerExtension does not work anymore
by Marius Dumitru Florea 22 May '12

22 May '12

Hi Guillaume, On Mon, May 21, 2012 at 6:47 PM, Guillaume Delhumeau (Deleted) (JIRA) <jira(a)xwiki.org> wrote: > > [ http://jira.xwiki.org/browse/XWIKI-7841?page=com.atlassian.jira.plugin.syst… ] > > Guillaume Delhumeau deleted XWIKI-7841: We have a rule of not deleting any JIRA issue. You should have closed it as Cannot Reproduce, Won't Fix or Duplicate instead. Thanks, Marius > --------------------------------------- > > >> XWiki.DatePickerExtension does not work anymore >> ----------------------------------------------- >> >> Key: XWIKI-7841 >> URL: http://jira.xwiki.org/browse/XWIKI-7841 >> Project: XWiki Platform >> Issue Type: Bug >> Reporter: Guillaume Delhumeau >> Labels: regression >> >> Create a new page and paste this code: >> { {velocity} } >> $xwiki.jsfx.use("js/scriptaculous/scriptaculous.js") >> $xwiki.jsx.use("XWiki.DatePickerExtension") >> $xwiki.ssx.use("XWiki.DatePickerExtension") >> { {html clean="false"} } >> <input type="text" name="mydate" id="mydate_id" /> >> <script type="text/javascript"> >> var dpicker = new DatePicker({ >> relative : 'mydate_id', >> language: "$context.language" >> }); >> </script> >> { {/html} } >> { {/velocity} } >> Note that if you click on the input, there is no DatePicker. >> Checked with Firefox 12 and Chromium 18 >> Documentation: http://extensions.xwiki.org/xwiki/bin/view/Extension/Date+Picker+Application > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA administrators: http://jira.xwiki.org/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

2 1

Re: [xwiki-devs] [GSoC] Responsive Skin
by Jonathan Solichin 22 May '12

22 May '12

Hello friends! > This kind of progressive disclosure mechanism that you've used for the > Desktop version is good for the mobile versions, when the space is > limited. > But on desktops I think is gonna be very disruptive for the user to > hide/show such large portions of UI, especially on hover events (which can > be triggered by accident). On desktop you have lots of space to use and > the > navigation/tools elements should be visible and accessible. So your > desktop > version would work better as a mobile version, but on landscape. Yea, I was debating that as well. Maybe a delayed response would serve better, or would the community rather have everything visible all the time? On the 'content is the king' note, I just wanted to state that XWiki is an > application wiki. So you need to have in mind that 'content' means not > just > text, but application content: forms, links, text, attachments, etc. The > 'content' thing is the hard part in representing it in a responsive > manner. Thank you for the link, it will definitely help when fleshing out the content. For a truly responsive skin, might be interesting to consider some > design alternatives to the traditional -- such as "windows metro" : > http://en.wikipedia.org/wiki/Metro_(design_language) Interestingly, that was the original inspiration for the project. That's why you have all those hidden mouse over events aha. It also takes some aspect of the charm bar as well (from windows 8)--where all the page navigation buttons are on the right. Also the huge fonts aha. Alternatley, the technique could also be used to break up a > traditional wiki document of linear sections, into a "metro style > panel" of horizontal pages. So in order to read within the section, > you'd swipe downward till you hit bottom of the section. But there'd > be a hint of the section header following and preceding to the right > and left. To go to the new section of a document, you'd therefore > sweep rightward; to go to previous you'd sweep left. I thought this was a great solution for mobile where gestures can be made. However, I think in a traditional desktop/mouse combo this would become an issue since if we account for the lowest common denominator (no do everything mouse), only one method of navigation is available--the scroll wheel. This means that only up and down or left to right can be chosen. I do agree that it is a very unique problem solution that they came up with though. If you have any idea on how to go about the limitation of the scroll wheel, i'd be interested! The following document talks about going from "website to metro-styled > app" but the same concept could be used to use a skin to transform > existing Wiki/Website layout to a mobile-friendly metro-styled design: > http://msdn.microsoft.com/en-us/library/windows/apps/hh868264.aspx Thank you for all the links, they are definitely very insightful. On a side note, I do like the explorations microsoft is doing (using windows phone myself atm). For mobiles, I think we need to test at least on WebKit and opera mini > on the devices we have (and IE if we can get hold on a windows phone). > For desktops, the usual bag. Yes, i think opera mini (with its limitation) is a good starting point. And webkit because of its pervasiveness. I do have a windows phone to test--this is the one that i'm worried about the most since they do some weird proprietary stuff. For example, fonts are changed by the browser itself to make it readable (i think) and some scripts do not work (even those that work on desktop ie). - The top menu/navigation is wrong IMO (c.f. Desktop4) Why not forget > about it and integrate its feature with the tools on the right ? (just > a suggestion) Originally I wanted to separate the two because the top navigation is a "global" navigation and serves as a bread crumb, where as the right is more page specific navigation. Do you think this is irrelevant? I will take this into account, and think about how to best integrate the two if any. - IMO you don't have to have "everything" on mobile. There are actions > that does not make much sense doing on a mobile, like print preview, > etc. "Responsive" or "Adaptive" should also be interpreted in terms of > feature I think. What do you think ? > BTW the GSoC title says "Responsive skin" ; but in terms of > implementation I have nothing against what LukeW calls "RESS" > (http://www.lukew.com/ff/entry.asp?1392) which basically says it's OK > to have some part of templates be device specific. I briefly touched upon this, iirc, in the proposal (not the RESS implementation specifically). You are right, some actions like print are unnecessary for mobile. In this specific instance, I should have used the more open term "export" for that oops. But in any regards, i myself am not very sure of how much should be specifically hidden and its value. Since unless we use RESS, the browser already have downloaded the files, it serves no advantage for data reasons or other to hide something downloaded. It might clean things up, but it doesn't add much beyond that. I was attempting to try and give the "full experience" as much as possible (unless it does hinder the experience). I know in most circumstance printing would not be available, but who knows someone out there may be able to (eg. google cloud print) and I don't want them to feel like this is a gimped down version of XWIKI. But I definitely do see your point, what does the community think about this? - What's the purpose of the combo boxes on your mobile design ? If > it's navigation, it's wrong, it won't scale with a lot of entries. I'm not exactly sure what you mean by combo boxes? If it's the drop down, it is to natively use the drop down chooser available on mobile devices to allow for more finger friendly interaction. implementation [1], examples [2] [3]. - You're missing the search box which I think is very central. I'd go > as far as saying the search box should be the one stop shop for > navigation when you're on a mobile. oops, i forgot about this. I am now making a check list of things needed to make sure this doesn't happen again. Finally, a revised timeline [4]. What does the community think? Thanks all! Such a learning experience, thanks again for having me. Jonathan Solichin [1] http://css-tricks.com/convert-menu-to-dropdown/ [2] http://open.blogs.nytimes.com/tag/ipad/ [3] http://qph.cf.quoracdn.net/main-qimg-047773f000eeb9037febd55aff32d10c [4] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin

1 0