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

[xwiki-devs] [Proposal] Java logging best practices additions

by vincent＠massol.net

Hi devs, On http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HLoggingBestPra… we have some best practices defined for logging. I’d like to propose some additions. Best practices: * Use SLF4J * If you’re in a component get the logger injected using @Inject private Logger logger otherwise use: private static final Logger LOGGER = LoggerFactory.getLogger(My.class); * Use logger.info() when it’s absolutely necessary for the user to see the message in the logs. Usually only used at startup and we want to limit what the user sees to the absolute necessary to avoid swamping him. * Use logger.warning() when an error happens but it doesn’t compromise the stability and general working of an XWiki instance. A warning just shows the user that something has gone wrong and it should provide him with as much information as possible to solve the issue. Do not print a stack trace when you output a warning since stack traces fill the logs and should be reserved for errors. In the view of users stack traces are synonymous with errors. We want it to be easy for admins to visually check the log files and see important problems (ie errors). * Use logger.error() when there’s an important problem that compromises the stability of the XWiki instance or that prevent an important system from working and that should not have happened. Always pass a stack trace when logging errors since it’s something that shouldn’t have happened an a developer will need to debug the problem to fix it. * Always log as much information as possible to make it easier to understand what’s going on. * Surround parameters with “[]” in order to separate visually the text from the parameters and also clearly notice when leading/trailing spaces are located in parameters. * For improved performances, always use the vararg signature of SLF4J for logging parameters and do not concatenate them manually: this.logger.debug("Test message with [{}] and [{}]", param1, param2); vs this.logger.debug("Test message with [“ + param1 + "] and [“ + param2 + “]", param1, param2); * When logging a warning, we don’t want to log the full stack trace but it’s still interesting from time to time to display the root issue. If you do the following you won’t get the root issue: LOGGER.warn("Failed to determine if the index exists: [{}]. Trying to recreate the index..”, e.getMessage()); Instead use ExceptionUtils from commons lang: LOGGER.warn("Failed to determine if the index exists: [{}]. Trying to recreate the index..”, ExceptionUtils.getRootCauseMessage(e)); WDYT? Thanks -Vincent

11 years, 6 months

6
8
0 0

[xwiki-devs] [Proposal] XWiki 6.0 + 5.4.1 roadmaps

by vincent＠massol.net

Hi devs, XWiki 6.0 ======== As usual here’s a proposal resulting from discussions I’ve had with XWiki committers who work at XWiki SAS for 6.0. * Collaborative Applications (Meeting, Calendar, (new) Forum, Tasks, Doodle, Photo) - Caty to work on usability and design (she’s started already at http://design.xwiki.org if you wish to follow the work). Andrea who’s a contributor is helping on the test + implementation part. There might be another contributor joining too. This work is currently done inside xwiki-contrib. * New skin! Caty for the design and Guillaume Delhumeau for the implementation part. We’ve been dreaming about this skin for a while. Caty has whet our appetite with screenshots from Junco (http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin and http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin) and from Flamingo (http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x). The idea is to establish new strong foundations for new skins (like standardizing on bootstrap classes for example) + have a new L&F. Caty and Guillaume will make proposals on the list about this. * At last we agreed to work on identifying performances issues (especially page load times) and work to fix them! Thomas is in charge of leading this extra important domain. One idea is to establish some automated tests to measure current performances and get a baseline so that we can then monitor our progress and start fixing things (and ensure we keep getting better all the time in the future). Thomas will send some proposals on the list too on this to let us know how he plans to tackle performance improvements. * Of course we need to keep some time to fix any remaining issues we get on the major feature we developed in 5.x + some improvements. I’m thinking about our SOLR search, Multiwiki integration, EM/DW, scalable import/export, etc. Thomas needs to finish the scalable import feature which is already well under way (see below). * Marius agreed to lead an investigation on CKEditor to see if it would make sense for us to use it as a replacement of our homemade editor. The general issue is that maintaining a WYSIWYG editor takes time and this is not really our core business at xwiki. We have 2 choices basically: have someone constantly working on improving our WYSIWYG editor or integrate an existing one so that we can benefit from the work of others. In the past few years we haven’t added that many features to our editor so it’s time to evaluate the feasibility and cost of using an external editor such as CKEditor. * The way users develop applications in XWiki hasn’t changed much over the past 10 years. Since then there’s been an explosion in the area of JS frameworks. We want to make it super easy to develop modern applications using XWiki (read ajaxy applications with new dev models). Marius agreed to lead this investigation along with the help of Guillaume Delhumeau. Since it’s an important aspect of XWiki and a complex one, they’ll need to drive various discussions and brainstorming with everyone and make some proposals so that we all agree to the directions we wish to go towards and so that we can start implementing it in 6.1. * Denis is going to continue working on Script signing as way to replace the existing Programming Rights which has shown its limitations. Denis has committed a new Crypto API in 5.x which is a strong base for the script signing implementation. In addition, during those discussions some raised a list of JIRA they consider important and that would be interesting to tackle if we get the time: - Support 2 roles for users for app within minutes: application creator and data creator - XWIKI-8757 - xwiki.cfg & xwiki.properties merging - Add default column and sort choices in AppWithinMinutes livetable setting - XWIKI-9659 - Save & view a section should go to the section anchor instead of the top of the document - XE-1335 - Add a message for the Livetable's empty state - XWIKI-7821 - "Space Templates" should also create the space preferences page - XWIKI-9712 - The Wiki UIExtensions should check the rights before executing extension points - XWIKI-9156 - Add an explanation next to the fields in user profile - XWIKI-6307 - When creating a new sub-wiki, pages are listed with guest - XWIKI-9888 - Cannot remove all panels using the Panel Wizard for space preferences - XWIKI-9891 Please comment if anyone sees a concern or if I have forgotten something! XWiki 5.4.1 ========= In addition we identified the need for a 5.4.1 release to: - finish important issues for the 5.x cycle and any leftover from 5.4. Our idea is to have usable and stable implementation for the bug items we worked on in 5.x: SOLR search, multiwiki integration, EM/DW and scalable export (scalable import has been pushed to 6.0 since we considered it too dangerous to plug by default in the default import UI in 5.x). - implement support for IE11 (there are only a few issues open). Marius agreed to work on the IE11 fixes. The reason we wish to implement this support is because we’re seeing more and more users reporting issues and asking for this support. ATM we support IE till IE9 only. IE10&11 are currently not officially supported at http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy It would be nice that after 5.4.1 we could edit this doc and mark them supported! Dates ===== I’m proposing the date of 17 of Feb for the final release of 5.4.1, assuming 5.4 is released on the 3rd of Feb as currently planned (i.e. 2 weeks after the release of 5.4). For 6.0: - 5.0M1: 10th of March 2014 (ie 3 weeks) - 5.0M2: 31st of March 2014 (ie 3 weeks) - 5.0RC1: 14th of April 2014 (ie 2 weeks) - 5.0Final: 28th of April 2014 (ie 2 weeks) TOTAL: 10 weeks, ie 2.5 months. WDYT? Thanks -Vincent

11 years, 7 months

6
12
0 0

[xwiki-devs] XWiki download form feedback - Updated Feb 2014

by vincent＠massol.net

Hi devs, FYI when someone downloads XWiki from xwiki.org he/she has the option to fill a download form. I’ve created http://www.xwiki.org/xwiki/bin/view/Main/DownloadFormFeedback some time back to share the results of this form. I’ve just updated it for the last few months’ feedback. Make sure to read it since it’s very interesting and shows us areas where we need to improve. Thanks! -Vincent

11 years, 7 months

1
0
0 0

[xwiki-devs] [Proposal] XWiki Day for 20 Feb 2014: Deprecation Fixing Day

by vincent＠massol.net

Hi devs, I’d like to propose a Deprecation Fixing Day for the next XWiki Day, ie for the 20 Feb 2014. The rules I propose: * On that day, I send the reminder email with inside the # of deprecated calls found in Commons, Rendering and Platform. For example right now it’s: - Commons: 39 (http://sonar.xwiki.org/drilldown/issues/1?&rule=squid%3ACallToDeprecatedMet…) - Rendering: 3 (http://sonar.xwiki.org/drilldown/issues/915?&rule=squid%3ACallToDeprecatedM…) - Platform: (still being computed, I don’t have a link to give ATM ;)) * One goal is to replace calls to deprecated methods by new API calls * Another goal is to move deprecated methods and types to legacy modules * On that day, I'll prepare a Blog post on xwiki.org (not published) and everyone who participates to this day should edit the blog post with his score for the day (since it’s hard to compute automatically). There’ll be 2 scores for everyone: a score for removed deprecated calls (1 point per removal) and a score for types and methods moved to legacy modules (1 point per type and method moved). WDYT? Note that in the future I’d like to expand this to a more generic Violation Fixing Day which would be about fixing any type of violations as reported by Sonar but before we do this we need to decide which violations we consider important and configuration Sonar properly for that. I’ll try to propose something on this soon. Thanks -Vincent

11 years, 7 months

4
6
0 0

[xwiki-devs] [GSOC] XWiki is applying for GSoC 2014. Proposals and mentors needed ASAP!

by Ecaterina Moraru (Valica)

Hello fellow XWiki community members, This year XWiki is planning to participate once more at Google's Summer of Code [1]. I know this is very short termed, but the organization registration period has already started (3 Feb) and the deadline is tomorrow (14 Feb 19:00 UTC). 1. We need to provide a list of proposals and assign mentors for the students that are going to implement them. I would like to ask everybody that wants to participate as a mentor from the XWiki organization to review the proposals [3] list and add as many interesting proposals as possible. The proposals can be either new, or they can be revived from previous year proposals. Just navigate to the previous years [4], find the proposal you like and know about, go to its proposal page (click it) and press the "Clone to this year" link. Now you should assign yourself as lead for that project, update it's description if needed and wait for the student applications to start pouring [image: emoticon_smile] 2. We also need to submit the actual application [5] of the XWiki organization to participate to the GSoC 2014 project so I would also like to ask you to review it so that we have a better chance of being selected into the program. 3. If you feel that you would like to help on improving XWiki's GSoC guides and application forms, please find tips for students [6] on XWiki's GSoC page, the student application form [7] and the lessons learned [8] from previous years participations. Thanks for your help, Caty [1] http://www.google-melange.com/gsoc/homepage/google/gsoc2014 [2] http://www.google-melange.com/gsoc/events/google/gsoc2014 [3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects28… [4] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HPreviousGSo… [5] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicat… [6] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines [7] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/student+application+… [8] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/LessonsLearned

11 years, 7 months

2
1
0 0

[xwiki-devs] [Reminder] BFD#55

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day #55 and our last BFD for 5.x cycle according to http://markmail.org/message/avl4tl5xuefe7s7w We’ll need to decide what we do for next week. I’ll send another email about that. We're currently at -23 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#55 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12090 Happy BFD! -Vincent

11 years, 7 months

1
1
0 0

[xwiki-devs] [Investigation] Investigating using TeamCity

by vincent＠massol.net

Hi guys, Since we’ve been having stability issues with Jenkins for some time now, I’d like to investigate using TC for XWiki’s CI. I’m playing with it locally ATM and it’s very nice. My proposal would be: * Set up one instance at http://teamcity.xwiki.org * Keep both jenkins and TC running in // for a few months and learn how to use TC and verify it matches our needs * Take a decision after a few months on which one we wish to use Note that I’ve already noticed a lot of nice things that we would get with TC that we don’t have with Jenkins currently: * personal builds (and direct integration in intellij IDEA for those using it) * notion of investigations * job templates WDYT? Any other CI you think would be better than TC? Thanks -Vincent

11 years, 7 months

3
3
0 0

[xwiki-devs] [Contrib] Create a repository for the Newsletter Application

by Manuel Smeria

Hello devs, I would like a repository for the Newsletter Application on https://github.com/xwiki-contrib. The application is available on the extensions wiki here: http://extensions.xwiki.org/xwiki/bin/view/Extension/Newsletter+Application… version 1.0.1. Thanks, Manuel

11 years, 7 months

2
1
0 0

[xwiki-devs] [ANN] Move to Java 7 is now done

by Thomas Mortagne

I updated all Jenkins agents to use Java 7 to build master branch and moved all references from Java 6 to Java 7 in xwiki-commons root pom. What it means in practice is that you might have issues building XWiki with Java 6 from now on (and will probably be impossible in not long). We don't yet used much Java 7 API but if you don't build everything on your side you will probably have issues when building a project which download on maven repository jars built with Java 7. In short: update your Maven setup to use Java 7 when working with master branch. Thanks, -- Thomas Mortagne

11 years, 7 months

3
4
0 0

[xwiki-devs] [ANN] XWiki 5.4.1 released

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 5.4.1. This is a bugfix release fixing a security issue among other things. 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/ReleaseNotesXWiki541 Thanks -The XWiki dev team

11 years, 7 months

1
0
0 0

[xwiki-devs] [Brainstorming] How to define @since when the package changes?

by vincent＠massol.net

Hi devs, I always ask myself this question so I think we need a common agreement. So here’s the question: * I have added some code in version N and this I have a "@since N” in the code * In version M (M > N), I move the class/interface to a new package Question: Do I change the @since annotation to “@since M” or not? 2 possibilities: * Reasoning 1: it’s a new class/interface since the FQN of the class/interface has changed and thus we should use “@since M” * Reasoning 2: even though the FQN has changed it’s still the same code that was moved and from a user POV, it was still introduced in version N and thus we should keep “@since N" WDYT? I’m hesitating. The most technically correct answer is Reasoning 1 IMO but the most useful one is probably Reasoning 2 since the question we wish to answer is probably: “when was this code first introduced?”. Thus reasoning 2 seems slightly better to me. Thanks -Vincent

11 years, 7 months

4
9
0 0

[xwiki-devs] [Contrib] Reporting extensions issues

by Ecaterina Moraru (Valica)

Hi, This mail should be seen as feedback for improving our e.x.o ( extensions.xwiki.org) and our contributions process, while answering some of my questions :) Right now I am playing and testing some XWiki extensions from e.x.o. The problem that I have is that I don't know where is the best place to report bugs and issues. 1. First of all I think we should add a 'Issue Tracker' field in the repository application, where the developer should state where the issues should be reported (what is the preferred way of reporting and even if the developer is available for further iterations of the extension). 2. What issue tracker we should use and how? Right now there are several ways the users can give feedback for a certain extension: A. Direct e-mails to the developers: I've received couple of times e-mails with questions about the extensions I've developed. This approach is not recommended since we are doing open development and other users might have the same question. Usually I suggest to use the mailinglist ( http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists ) if there are additional questions, but an issue tracker could also solve the problem. B. Community mailinglist: We receive many questions about the extensions on the mailinglists. The problem is that the answers are very hard to track and share among other users (you need to know that the question has been asked before and than that an answer has been provided). An issue tracker would improve the process. C. Comments on the extension page: There are several extensions that have comments on their extension page. While this approach is the most accessible, it is hard to know what is the status of a comment and the responsible person for it (was it fixed already? in what version? is the comment still valid?). D. GitHub issue tracker: While some extensions contain just snippet code or local XARs, other have a repository attached to it. I know some extensions that track their issues on github. The advantages of this approach is that you keep total control of your extension and also you don't need approvals from xwiki community to have your repository created or help with the management of it (rights, etc.). You handle your own development while using e.x.o as a publishing platform. The above statements are in case you have a personal repository. The alternative is to have a repository on xwiki-contrib ( https://github.com/xwiki-contrib ), but these repository could also have the github issue tracker activated. E. jira.xwiki.org project: On jira.xwiki.org there is a whole section of Contributed Projects ( http://jira.xwiki.org/secure/BrowseProjects.jspa#all ). There is also a generic XWiki Contrib project ( http://jira.xwiki.org/browse/XCONTRIB ) " to be used by all projects till they achieve a first release or till they grow to a size significant enough to warrant a dedicated JIRA project" (quote taken from http://contrib.xwiki.org/ ) F. IRC: Even harder than mailinglist to reference. G. other? I've written all the ways in order to agree on the recommended way (which I guess is E.) while I don't think there is a way to force the others from happening. 3. Related extensions vs. Branched extensions vs. Forked extensions My problem is like this: Lets say I want to test the Forum Application. Currently there are 3 versions of the Forum application (read more at http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplication ). - First of all it was hard to know that we have 3 versions for the 'same' functionality. A feature like "Related extensions" would have been great to have on e.x.o. - Then it was difficult to find out where is the place to report issues for each of these applications (see the whole point of this mail). Currently there are 2 JIRA projects created for Forum (XAFORUM and XBB) but there is no place to report for SimpleForumApp. - It was hard to know what version still work and if there is still active development on it (especially if you have just an attached XAR and not a repository). - It is hard to know if the apps are completely different or if they are just forks of the same base code. Do they share the same functionality, do they want to be improved versions or are just completely different things? These questions are important because they give you an answer if the entries should have separate JIRA projects or we could solve the problem by creating just a COMPONENT in the same JIRA project. - Whose responsibility is it to create the issue tracker, to link to the related applications, etc? (the developer? the contrib managers? other members of the community?) The same questions apply for Calendar Application ( http://design.xwiki.org/xwiki/bin/view/Proposal/CalendarApplication ). I have 3 variants with other related extensions. The only extension that has a JIRA project associated with it is the older extension. So, as an user of the extension, where do I report issues? - Do I need to ask for the creation of a separate project? - Do I ask for the creation of a separate component in the existing project? - Do I report in the generic xcontrib project? - Do I need the permission of the developer to have the project created? - Should we enforce the creation of projects for the new extensions? - How we decide if an extension is big enough or important enough to have its own project? - Who should monitor these growth? (since we actually don't know if the extensions are used or downloaded?) Let me know what you think. Thanks, Caty

11 years, 7 months

2
4
0 0

[xwiki-devs] [ANN] Realtime Collaborative Plain WikiText Editor and WEBSOCKET!

by Caleb James DeLisle

Hi all, I'm very pleased to announce two new extensions to come out of XWikiSAS Research and the RESILIENCE Research project. Number One: WebSockets in XWiki! If you're an extension developer like me, you want events, you want stuff in the browser to be talking to stuff in the wiki and you don't want to be messing around with Jetty and Tomcat and all different kinds of libraries and configuration every time you need to write an application. You just want stuff that works. Here it is: http://extensions.xwiki.org/xwiki/bin/view/Extension/WebSocket Include this as a dependency for your extension and the Extension Manager will automatically include it when users install your extension. In just a few lines of code, your users can be chatting and collaborating through the websocket and it's based on Netty (Special thanks to the Atmosphere project for developing Nettosphere) so it works in all versions of Tomcat and Jetty and does not need any changes to the front-end server, just open a port on the JVM machine and you're done. Number Two: A new Realtime Collaborative WikiText Editor. Indeed this is not the first attempt at Realtime Collaborative editing but perhaps it is the most academically amusing. Really this is a prototype to get a handle on the technology before we make the leap into Realtime WYSIWYG. Whereas the previous Realtime Collaborative WikiText editor had performance issues and was unable to handle large pasted, the new editor uses a completely novel design which is intended to not only port well to WYSIWYG editing but is implemented entirely on the client with the server only relaying messages, making it portable to different web frameworks. Check out the Realtime Collaborative WikiText Editor here: http://extensions.xwiki.org/xwiki/bin/view/Extension/RealTime+Wiki+Editor or install it with the Extension Manager to give it a try for yourself. Disclamer: This is still new and might not work properly on all browsers, it certainly will not work without websocket support. Thanks, Caleb

11 years, 7 months

6
11
0 0

[xwiki-devs] [Proposal] Action Module revisited - take 2

by vincent＠massol.net

Hi devs, I’m currently revisiting the action module, see http://design.xwiki.org/xwiki/bin/view/Design/ActionModule Let me know what you think and if you have any other idea. I’m going to continue exploring this over the coming couple of days and write a first implementation that I’ll put in a branch in platform. Of course the earlier you can provide feedback the less I’ll have to rewrite ;) Context: I’m ready to commit support for webjars (see http://jira.xwiki.org/browse/XWIKI-9375) but I’d like to do it cleanly without implementing it as a Servlet Filter or as an oldcore XWikiAction… Thanks! -Vincent

11 years, 7 months

2
4
0 0

[xwiki-devs] [Reminder] Review and removal of @Unstable annotation for 6.x

by vincent＠massol.net

Hi guys, According to your rules since we’re starting a new cycle we need to review all existing @Unstable annotations and remove ones that have been there for at least one cycle (i.e. prior to the 5.x cycle). See http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#H40Unsta… It’s also the occasion to check @Unstable APIs that we can consider stable now. Thanks -Vincent

11 years, 7 months

4
9
0 0

[xwiki-devs] Problem with XWikiLDAPUtils class

by Eric Kimn

Hey all, I managed to view the code for this class by a google search. But i’m noticing a problem with the getGroupMembers logic and I’m experiencing it myself in my 5.4 install of xwiki. Some background: I am using Apple’s open directory as my ldap server. My ldap config is as such (using the LDAP application): Restrict to group: cn=mygroup LDAP base dn: dc=mycompany,dc=com LDAP UID Attribute name memberUid The symptom: When XWiki tries to locate the members of a group, it finds only one, typically the alphabetically first one, and not all. The source of the problem: The entry point is here: public Map<String, String> getGroupMembers(String groupDN, XWikiContext context) which calls with a new map of <String, String> for members, this line -> boolean isGroup = getGroupMembers(groupDN, members, new ArrayList<String>(), context); That method has this signature -> public boolean getGroupMembers(String groupDN, Map<String, String> memberMap, List<String> subgroups, XWikiContext context) which falls to if (searchAttributeList != null) { isGroup = getGroupMembers(fixedDN, memberMap, subgroups, searchAttributeList, context); } But of course there are search attributes, so it calls this-> public boolean getGroupMembers(String groupDN, Map<String, String> memberMap, List<String> subgroups, List<XWikiLDAPSearchAttribute> searchAttributeList, XWikiContext context) And this is where the problem is: It for loops through the search attributes and executes a query, if it gets a response that isn’t a group and the member map doesn’t already contain that key, it will add it: if (!memberMap.containsKey(groupDN)) { memberMap.put(groupDN.toLowerCase(), id == null ? "" : id.toLowerCase()); } But then it RETURNS isGroup, which is now true, And that flows back up the chain, except it never iterates through the rest of the entries. My logs show: 2014-02-08 17:45:22,858 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPUtils - Looks like [cn=mygroup] is not a DN, lets try filter or id 2014-02-08 17:45:22,858 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPConnection - LDAP search: baseDN=[dc=mycompany,dc=com] query=[cn=mygroup] attr=[[objectClass, uid, memberuid, memberUid]] ldapScope=[2] 2014-02-08 17:45:22,864 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPUtils - Found group [cn=mygroup] members [{cn=mygroup,cn=groups,dc=mycompany,dc=com=member1}] 2014-02-08 17:45:22,864 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPUtils - Found user dn in user group [null] 2014-02-08 17:45:22,865 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG u.i.L.XWikiLDAPAuthServiceImpl - Local LDAP authentication failed. com.xpn.xwiki.XWikiException: Error number 8001 in 8: LDAP user member2 does not belong to LDAP group cn=mygroup. Am I reading the logs or code wrong? If I am, then what am I doing wrong with my ldap configuration? I’m clearly part of mygroup but it consistently fails to find me. Best, Eric Kyungsuk Kimn 김경석 Senior Back End Developer ekimn(a)apple.com

11 years, 7 months

2
15
0 0

[xwiki-devs] [VOTE] Move to Java 7 as minimum supported version

by Thomas Mortagne

Hi devs, I would like to propose that we move to Java 7 as minimum version in XWiki 6.0. You can look at http://jira.xwiki.org/browse/XCOMMONS-432 for details on why and why not. The only cons basically is that Java 6 may still be used in production but we are talking about a version that won't be used in production before at least 3 months. WDYT ? Here is my +1 -- Thomas Mortagne

11 years, 7 months

11
12
0 0

[xwiki-devs] [Reminder] BFD#54

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 54. We're currently at -50 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#54 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12000 Happy BFD! -Vincent

11 years, 7 months

1
1
0 0

[xwiki-devs] [Proposal] WebJar integration in XWiki

by Vincent Massol

Hi devs, I'd like to make it easy in XWiki to use javascript frameworks required by extensions. I've found the webjars project (http://webjars.org) which packages javascript frameworks in JAR files available in Maven Central. They work out of the box if you drop them in WEB-INF/lib in a Servlet 3.0 container (like Jetty 7). It works because the 3.0 spec says that any files located in META-INF/resources/<path> will be made available by the servlet container as static resources (accessible as <path>). However the servlet 3.0 specs doesn't support adding those JAR dynamically outside of WEB-INF/lib so it doesn't work with our extension mechanism. Thus I'm proposing the following (which I have tested to work): * Add a new WebJarFilter filter to web.xml * The URL to access, for ex, angular.js packaged in the http://repo2.maven.org/maven2/org/webjars/angularjs/1.1.5-1/angularjs-1.1.5… jar would be: /xwiki/webjar/angularjs/1.1.5/angular.js This allows for example to have a dep on: <dependency> <groupId>org.webjars</groupId> <artifactId>angularjs</artifactId> <version>1.1.5-1</version> <scope>runtime</scope> </dependency> Then in a JSX object: require(["/xwiki/webjar/angularjs/1.1.5/angular.js"], function() { … }); WDYT? Thanks -Vincent

11 years, 7 months

5
11
0 0

[xwiki-devs] [Proposal] Release 5.4.1 next Tuesday

by vincent＠massol.net

Hi Devs, Since we’ve found an important issue in 5.4 (see http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki54) and Denis has also fixed a security issue, I’d like to propose releasing 5.4.1 earlier than planned (it was planned for the 17th of Feb) and schedule a 5.4.2 with the leftover. GuillaumeD has proposed to be the RM for 5.4.1. Here’s what has been fixed so far in 5.4.1: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12003 There are 14 issues so far which makes it more than enough IMO. WDYT? Thanks -Vincent

11 years, 7 months

4
3
0 0

[xwiki-devs] 6.x performances work

by Thomas Mortagne

Hi devs, Here is a mail to talk about what I plan to do during 6.x related to performances. I don't have detailed plan for 6.0 yet, I still have work to do on unfinished 5.x stuff and my priority will goes to that but before working on it lets present what I already have in mind about performances and gather some other ideas. I did not really made much new reseachs yet, it's mostly things I have in mind since some time for most of them. First thing first: having good performance is everyone's work, don't expect me to review everything you do and do all the thinking about how to design each feature so that it has good performances. My main job is do things we always puh back because we don't have time so here it is. = Automated speed report with history I plan to write a build dedicated to test performances (of XE for now) and provide stored and compared reports about it. My plan is to combine the following tools: * JMeter and more precisely some jmeter Maven plugin (probably https://github.com/Ronnie76er/jmeter-maven-plugin/) * Jenkins Performance Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Performance+Plugin) to put a nice UI around that And probably run that build something like once a day on master branch for example. The first step is to report it, second will probably be to set a maximum timeout (that we ideally reduce over time ;)) to fail the build when it become too slow (but that will be only after we actually improved it). I hope to finish this in 6.0. = Spot worst places I plan to do hand testing with a profiler (probably YourKit) and write detailed reports in jira issues for the slowest parts or our code during a request (and not only for view, save is a realy a pain sometimes) and what seems weird so that we find solutions (or not) for each one. Same, I think I should have moved forward on it during 6.0 timeframe. = Things we already know but for which I don't have yet a definitive solution == Too much database requests Loading a single document generate tons of requests. The document cache hide this a little. Maybe start include some lazy loading of objects in document or things like this but it's hard since we don't have any real clean interface and only XWikiDocument to work on it. == The UI is very expensive Loading a page with /get/ action for example is a lot quicker (often more than 5 times quicker) than loading it with the full UI (/view/ action) even a page with lots of content including content we generally consider very slow like code macro. = Some ideas of refactoring or new features I already have in mind (not specifically done by me, it's just ideas of things to look at) == Async events I don't think there is much related issues in view but we are doing way too much blocking stuff when modifying a document so I plan to allow a listener to declare that it's ok for it to receive asynchronous events (events sent in a different thread than the one who actually saved the document) and review the listeners that could use that (the first one I have in mind is user cleaner but I'm also thinking about wiki extension module which execute several requests at each save for example and all the code responsible for parsing and storing backlinks in modified documents). == Activity stream UI This is nothing new and a project of it's own, the UI of Activity Stream is super slow and probably require a complete analysis and rewrite by a dedicated developer. <put other ideas here ;)> -- Thomas Mortagne

11 years, 7 months

2
1
0 0

[xwiki-devs] [ANN] XWiki User Map - Please add yourself!

by vincent＠massol.net

Hi XWiki users, We’re trying to create a user map of all XWiki users. There are 2 nice effects from this: 1) Increase the feeling of a community 2) Find out other XWiki users close to where you are. The next step will be to organize some XWiki User Group in places where there’s a cluster of xwiki users! Please join the xwiki community by adding yourself to: https://maps.google.com/maps/ms?msid=210331808187331529022.0004f02bd076d94d… Thanks a lot -Vincent Massol

11 years, 7 months

1
0
0 0

[xwiki-devs] [Proposal] Remove the panel "Wiki Information" in default subwiki configuration

by Guillaume "Louis-Marie" Delhumeau

Before 5.3, we used to have panel "Wiki Information" [1], by default, on the right column of new workspaces. In regular subwikis (not workspaces), we did not have this panel. I propose to not have it by default on the subwiki configuration. It will still be possible to add it manually since the panel will still be bundled in the subwiki application. Here is my +1. Louis-Marie [1] http://jira.xwiki.org/secure/attachment/27198/missing-panel.png

11 years, 7 months

5
4
0 0

[xwiki-devs] [Brainstorming] Default rights in subwikis

by Guillaume "Louis-Marie" Delhumeau

Hi devs. Since 5.3, we have this issue opened: http://jira.xwiki.org/browse/XWIKI-9726 - The default rights of subwikis has changed. I am not shocked by the new settings - same as in the main wiki - but it is different from what Workspaces used to be. What do you think about it? Thanks, Louis-Marie

11 years, 7 months

5
8
0 0

[xwiki-devs] [Proposal] XWiki 6.x cycle dates

by vincent＠massol.net

Hi devs, We’ve already decided on the 6.x cycle and on the 6.0 roadmap and dates. I’d like to propose the following global schedule for the full 6.x cycle: * 6.0: April 2014 * 6.1: June 2014 * 6.2: August 2014 * 6.3: October 2014 * 6.4: December 2014 Note that I’m implicitly proposing to change one rule defined at http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices… I’m proposing to have 5 release per cycle instead of 6 in order to make a cycle fit in 1 year (we did this for 5.x btw). Also note that I’ve put slightly shorter release times for releases (between 1.5 to 2 months, except for the 1st one for which I’ve allowed 2.5 months). WDYT? Thanks -Vincent

11 years, 7 months

1
0
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