Hi.
Currently, XWiki is quite long to start, and this is mainly because of the
LESS compiler which generates the CSS file of the skin.
Fortunately, we cache the results of the compilation in the LESS cache,
which is stored in the file-system (this is important).
Some actions can be done to make the launch quicker:
1 - Not purge the cache at startup.
The idea is to keep the cache of the previous launch of XWiki, so LESS
would have nothing to compile anymore. This does not solve the first launch
issue, but it is a great progress anyway. The disadvantage of this is that
restarting XWiki will not solve any issue related to a bad cached file (ex:
a buggy CSS file stored in the cache will still be there after a restart.
The only way to fix this is to re-save the buggy LESS resource).
Note that this behaviour can easily be changed by modifying a config file:
http://extensions.xwiki.org/xwiki/bin/view/Extension/LESS+Module#HCacheStra…
2 - During the build of XE, run an integration test that performs a simple
view request to XWiki in order to make the LESS compiler builds the CSS
file and pushes it into the cache. After the integration test, we just copy
the generated LESS cache file into the Jetty/HSQLDB distribution, and so
when you launch XWiki from this distribution, you use the pre-generated
cache.
Of course it could only work for our Jetty distributions that users test
locally. It will not solve the issue on production servers. But it is
already good that a user have a good impression by starting XWiki quickly
on her computer.
I have made a proof of concept on a branch [1] and the thing is working
well. The first request to XWiki is really faster.
The only blocking point I have now is that the current cache directory is
currently configured to be the temporary directory. Instead, I need to use
a directory from the distribution (where I can put my pre-generated cache
files). I have solved this locally by setting an absolute path to my "data"
folder [2], but it is not clean.
Thomas suggested me to configure all the caches to use the "permdir"
directory, which actually is the "data" directory in the case of our jetty
distributions, and so it does the job.
So the vote is for the following proposal:
1 - move the cache files to permdir
2 - do not purge the LESS cache at startup (by default)
3 - add a new module that pre-generate the LESS cache file to make the
first XWiki launch faster
Here is my +1.
Thanks,
[1] https://github.com/xwiki/xwiki-enterprise/compare/feature-datalesscache
[2]
http://jira.xwiki.org/browse/XWIKI-10879?focusedCommentId=85369&page=com.at…
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi all,
Today I worked with Mohamed to release an extension (TotemApplication) to the extension manager
and he wrote an excellent tutorial for uploading a xar file so that is is accessible from the
extension manager.
http://www.xwiki.org/xwiki/bin/view/Drafts/ContributingExtensions
I'd like to propose we move this to a more official location than /Drafts/ since at this point
it's the only end-to-end tutorial on contributing XAR extensions.
WDYT?
Caleb
--
Satire is the escape hatch from the cycle of sorrow, hatred and violence. #JeSuisCharlie
Hi XWIKI Team,
Please, is there any way to make a search inside page sources.
I need to search for a word inside page sources in the Space "Main".
Even by a query on the database.
Thanks in advance.
Best Regards,
Walid YAICH
The XWiki development team is proud to announce the availability of XWiki
Enterprise 6.4.1.
This is a stabilization release that fixes important bugs discovered in the
previous 6.4 version, while also providing an integration of the new Tree
Widget with the Index Application and the WYSIWYG Editor.
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/ReleaseNotesXWiki641
Thanks
-The XWiki dev team
Hi devs,
I need to code some stuff for the new mail sender API (ability to send mails to all users of several groups) and I’ve noticed 5 issues with the current group API (XWikiGroupService):
1) It’s not implemented as components (you need to get the XWiki object and call getGroupService() to get an instance)
2) The APIs uses String to reference groups (instead of an EntityReference/DocumentReference). Note that ideally we should have a Java interface to represent a Group and a Group Reference since we could want to implement Groups differently than as wiki pages in some future (for example, by using JAAS, LDAP, etc) but this is probably for later and for now having an EntityReference/DocumentReference is probably good enough
3) The API to return all users of a group (getAllMembersNamesForGroup) return a Collection<String> and takes as input an offset and a number of users to return. This is a very DB-oriented way to scale an API but it’s not easy to use in Java when you want to get all users of a group (you need to maintain a cursor). What is useful in Java is an API that return an Iterator<DocumentReference>.
4) The getAllMembersNamesForGroup() API doesn’t seem to handle subgroups...
5) I’ve also noticed that we have **lots** of group-related APIs in a RightsManager class (which is javadoc-ed as being internal BTW but used elsewhere…), used by the RightsManagerPluginApi. I don’t see why we have users or group-related APIs in a an API related to permissions/rights (i.e. authentication)… This API suffers from another problem: even though is has a resolveUsers(String userOrGroup, XWikiContext context) method to extract users from a list of users or group references, it doesn’t scale! Indeed it doesn’t accept any offset/count parameters and it returns a Collection<DocumentReference>...
Thus, I have 2 options:
A) do the conversion between String <-> DocumentReference on my side (in the mail sender api) + handle subgroups in the mail sender api + maintain cursor in the mail sender code
B) Start quickly a new component-based Group API which would have just the method I need for now (and would be marked unstable).
For B) I‘m thinking about something like:
Option 1:
=========
GroupManager
 |_ Iterator<DocumentReference> getAllUsers()
(in the future we would also have a getMatchingUsers(…))
By default the impl would retrieve batches of user references from the group (say 100 at a time)
However, if you want to get just 1 user for example, this is a bit overkill to get 100 DB results. But is that a real use case? So we also have option 2:
Option 2:
==========
GroupManager
 |_ GroupResultSet getAllUsers()
Where:
GroupResultSet
 |_ Iterator<DocumentReference> iterator() - default to batch size of 100
 |_ Iterator<DocumentReference> iterator(int batchSize)
 |_ Collection<DocumentReference> get(int nb, int offset) (do we really need this api?)
I’d prefer to not use option 2 if possible but there may be use cases I don’t see right now that would require 2 and it has the nice advantage of being able to add new methods to GroupResultSet without impacting backward compatibility.
Note that this discussion between option 1 and 2 is interesting more generally speaking since we would need to decide what’s our best practices in all our APIs when we require to return large collections of values. So far a lot of our old APIs use the (int nb, int offset) solution, which is versatile but not easy to use IMO and I don’t find it nice that we mix business parameters with technical ones.
Last question would be where to put this new code. I can see 2 choices:
i) in a new xwiki-platform-group module
ii) in a new xwiki-platform-user/xwiki-platform-user-api module where we would put both APIs for both Users and Groups
option ii) seems better IMO.
WDYT?
Thanks
-Vincent