[xwiki-devs] [Proposal] Making it easier to customize XWiki for public web sites
Hello devs, When we are using XWiki for public web sites, most of the time we want to hide some elements in the UI for guest users (and sometimes for authenticated users as well). Currently, it's not elegant to do so : either we have to create a custom skin, override a couple of templates (with all the merging nightmare it bringd when upgrading the wiki) - either we create a SSX to "hide" visually elements. None of those solutions are really satisfactory. The first one is painful, the second one is only a workaround and can be a pain too (there is no way currently to use a SSX "under certain conditions") Before we can handle all this nicely using Interface eXtensions, I propose to make couple of light changes to some templates to make our life easier : 1) Add 4 variables in layoutvars.vm : * $displayContentMenu // display or not the content menu (view, edit links, etc.) true by default * $displayMainMenu // display or not the main menu (wiki and space links, user profile) true by default * $displayDocExtra // display or not the tabs with doc extra links (comments, attachments, etc.) true by default * $displayShortcuts // display or not the document shortcuts (those are in the line written under the document title) (this is XWIKI-4394 "Allow some UI elements not to be displayed by setting a variable") 2) Add a "extravars.vm" template that remains empty by default. This will allow to override values from xwikivars/layoutvars without the need to override them (and introducing the merging pain upon upgrade). (this is XWIKI-4927 "We need a way to be able to override variables from xwikivars.vm / layoutvars.vm without overriding these templates") Please let me know what you think, I would like to move forward with this during 2.3 Thanks, Jerome.
On 02/24/2010 12:36 AM, Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want to hide some elements in the UI for guest users (and sometimes for authenticated users as well). Currently, it's not elegant to do so : either we have to create a custom skin, override a couple of templates (with all the merging nightmare it bringd when upgrading the wiki) - either we create a SSX to "hide" visually elements. None of those solutions are really satisfactory. The first one is painful, the second one is only a workaround and can be a pain too (there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I propose to make couple of light changes to some templates to make our life easier :
1) Add 4 variables in layoutvars.vm : * $displayContentMenu // display or not the content menu (view, edit links, etc.) true by default * $displayMainMenu // display or not the main menu (wiki and space links, user profile) true by default * $displayDocExtra // display or not the tabs with doc extra links (comments, attachments, etc.) true by default * $displayShortcuts // display or not the document shortcuts (those are in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This will allow to override values from xwikivars/layoutvars without the need to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with this during 2.3
+1 for all. -- Sergiu Dumitriu http://purl.org/net/sergiu/
+1 Thanks, Marius Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want to hide some elements in the UI for guest users (and sometimes for authenticated users as well). Currently, it's not elegant to do so : either we have to create a custom skin, override a couple of templates (with all the merging nightmare it bringd when upgrading the wiki) - either we create a SSX to "hide" visually elements. None of those solutions are really satisfactory. The first one is painful, the second one is only a workaround and can be a pain too (there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I propose to make couple of light changes to some templates to make our life easier :
1) Add 4 variables in layoutvars.vm : * $displayContentMenu // display or not the content menu (view, edit links, etc.) true by default * $displayMainMenu // display or not the main menu (wiki and space links, user profile) true by default * $displayDocExtra // display or not the tabs with doc extra links (comments, attachments, etc.) true by default * $displayShortcuts // display or not the document shortcuts (those are in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This will allow to override values from xwikivars/layoutvars without the need to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with this during 2.3
Thanks, Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want to hide some elements in the UI for guest users (and sometimes for authenticated users as well). Currently, it's not elegant to do so : either we have to create a custom skin, override a couple of templates (with all the merging nightmare it bringd when upgrading the wiki) - either we create a SSX to "hide" visually elements. None of those solutions are really satisfactory. The first one is painful, the second one is only a workaround and can be a pain too (there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I propose to make couple of light changes to some templates to make our life easier :
1) Add 4 variables in layoutvars.vm : * $displayContentMenu // display or not the content menu (view, edit links, etc.) true by default * $displayMainMenu // display or not the main menu (wiki and space links, user profile) true by default
Is this notion not specific to colibri only? Do we want to make it a generic feature for all skins or do we want to add an empty skinlayoutvars.vm in templates/ that are there so that skins fill it with skin-specific vars?
* $displayDocExtra // display or not the tabs with doc extra links (comments, attachments, etc.) true by default
Don't we already have a variable for hiding the doc extra tabs? We need to make sure we use the same one.
* $displayShortcuts // display or not the document shortcuts (those are in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This will allow to override values from xwikivars/layoutvars without the need to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with this during 2.3
+1 Thanks -Vincent
On 2/24/10 8:35 AM, Vincent Massol wrote:
On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want to hide some elements in the UI for guest users (and sometimes for authenticated users as well). Currently, it's not elegant to do so : either we have to create a custom skin, override a couple of templates (with all the merging nightmare it bringd when upgrading the wiki) - either we create a SSX to "hide" visually elements. None of those solutions are really satisfactory. The first one is painful, the second one is only a workaround and can be a pain too (there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I propose to make couple of light changes to some templates to make our life easier :
1) Add 4 variables in layoutvars.vm : * $displayContentMenu // display or not the content menu (view, edit links, etc.) true by default * $displayMainMenu // display or not the main menu (wiki and space links, user profile) true by default
Is this notion not specific to colibri only? Do we want to make it a generic feature for all skins or do we want to add an empty skinlayoutvars.vm in templates/ that are there so that skins fill it with skin-specific vars?
I tend to think we don't want to introduce skin-specific variables. I would say we have all four variables in templates/ and displayContentMenu is ignored for older skins as they had no content menu (i.e. everything was in the "main menu"). My description of the main menu above was colibri specific indeed
* $displayDocExtra // display or not the tabs with doc extra links (comments, attachments, etc.) true by default
Don't we already have a variable for hiding the doc extra tabs? We need to make sure we use the same one.
I will check that, yes. Jerome.
* $displayShortcuts // display or not the document shortcuts (those are in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This will allow to override values from xwikivars/layoutvars without the need to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with this during 2.3
+1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 24, 2010, at 11:11 AM, Jerome Velociter wrote:
On 2/24/10 8:35 AM, Vincent Massol wrote:
On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want to hide some elements in the UI for guest users (and sometimes for authenticated users as well). Currently, it's not elegant to do so : either we have to create a custom skin, override a couple of templates (with all the merging nightmare it bringd when upgrading the wiki) - either we create a SSX to "hide" visually elements. None of those solutions are really satisfactory. The first one is painful, the second one is only a workaround and can be a pain too (there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I propose to make couple of light changes to some templates to make our life easier :
1) Add 4 variables in layoutvars.vm : * $displayContentMenu // display or not the content menu (view, edit links, etc.) true by default * $displayMainMenu // display or not the main menu (wiki and space links, user profile) true by default
Is this notion not specific to colibri only? Do we want to make it a generic feature for all skins or do we want to add an empty skinlayoutvars.vm in templates/ that are there so that skins fill it with skin-specific vars?
I tend to think we don't want to introduce skin-specific variables.
I would agree only if the concept are supposed to be generic for all possible skins. Otherwise if each skin introduces its own concepts, it's going to be a mess after a while.
I would say we have all four variables in templates/ and displayContentMenu is ignored for older skins as they had no content menu (i.e. everything was in the "main menu"). My description of the main menu above was colibri specific indeed
Let's see what others think. It's not obvious that the number of menus is generic to all skins. Having at least one menu is probably generic. Having 2 I'm not sure. Some skins would work fine with only 1 menu. Imagine a future skin adds 2 more menus (making it 4 in total). I'm not sure if it would mean that the Colibri skin didn't use 2 menus. It could also mean that that new skin has the concepts of 4 menus that other skins don't have. I'm personally +0 on either choice. Thanks -Vincent
* $displayDocExtra // display or not the tabs with doc extra links (comments, attachments, etc.) true by default
Don't we already have a variable for hiding the doc extra tabs? We need to make sure we use the same one.
I will check that, yes.
Jerome.
* $displayShortcuts // display or not the document shortcuts (those are in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This will allow to override values from xwikivars/layoutvars without the need to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with this during 2.3
+1
Thanks -Vincent
On Wed, Feb 24, 2010 at 11:21, Vincent Massol <[email protected]> wrote:
On Feb 24, 2010, at 11:11 AM, Jerome Velociter wrote:
On 2/24/10 8:35 AM, Vincent Massol wrote:
On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want to hide some elements in the UI for guest users (and sometimes for authenticated users as well). Currently, it's not elegant to do so : either we have to create a
custom
skin, override a couple of templates (with all the merging nightmare it bringd when upgrading the wiki) - either we create a SSX to "hide" visually elements. None of those solutions are really satisfactory. The first one is painful, the second one is only a workaround and can be a pain too (there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I propose to make couple of light changes to some templates to make our life easier :
1) Add 4 variables in layoutvars.vm : * $displayContentMenu // display or not the content menu (view, edit links, etc.) true by default * $displayMainMenu // display or not the main menu (wiki and space links, user profile) true by default
Is this notion not specific to colibri only? Do we want to make it a generic feature for all skins or do we want to add an empty skinlayoutvars.vm in templates/ that are there so that skins fill it with skin-specific vars?
I tend to think we don't want to introduce skin-specific variables.
I would agree only if the concept are supposed to be generic for all possible skins. Otherwise if each skin introduces its own concepts, it's going to be a mess after a while.
I would say we have all four variables in templates/ and displayContentMenu is ignored for older skins as they had no content menu (i.e. everything was in the "main menu"). My description of the main menu above was colibri specific indeed
Let's see what others think. It's not obvious that the number of menus is generic to all skins. Having at least one menu is probably generic. Having 2 I'm not sure. Some skins would work fine with only 1 menu.
Imagine a future skin adds 2 more menus (making it 4 in total). I'm not sure if it would mean that the Colibri skin didn't use 2 menus. It could also mean that that new skin has the concepts of 4 menus that other skins don't have.
I'm personally +0 on either choice.
Thanks -Vincent
* $displayDocExtra // display or not the tabs with doc extra links (comments, attachments, etc.) true by default
Don't we already have a variable for hiding the doc extra tabs? We need to make sure we use the same one.
I will check that, yes.
Jerome.
* $displayShortcuts // display or not the document shortcuts (those are in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This will allow to override values from xwikivars/layoutvars without the
need
to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with this during 2.3
+1
Thanks -Vincent
Hello devs, As you may know, we build web sites since a while with XWiki and we have had to face the issues describe by Jerome. Modified VMs was really a pain for us when we need to upgrade to a newer XWiki version. This is why during our move from 1.4 to 1.9, we have mostly stopped using VM in our own skins, and we now apply the needed changes directly into the .vm on the server using patches, which are a more maintainable (I have move them to 2.2 in less then an hour). So there is not only the issue regarding hidding interface for which we need to do so (we had advanced google analytics, accessibility markup, company logo, additionnal docextras (rigths), ...). Since we host a farm, with many different XWiki requiring different behaviors, these patches should also be customizable from the preferences of each wikis. In particular, we have a patch for hiding interface elements, not only menus but also tags, authors, docextras globally and separately (also taking care of removing related menu options), copyrights, version,... , that extends the capacity initially available through the old hidden preferences named showcomments, showattachements,... To allow easy customization directly from XWikiPreferences without cluttering the XWikiPreference class (like the several show... does IMO), we have only added a single multi-valued static list, that list what we want hidden. We have also categorized several kind of users: guest, users, editors, managers, admin and all, based on some predefined group (XWikiAllGroup, XWikiEditGroup, XWikiManagerGroup,...) and we provide a leveled hiding of each interface element in a manner that guest do not see what users can't see, guest and users do not see what editors can't see, and so on... This has reveal to be really easy and practical, since we have a consistent and uncluttered interface for each kind of users, and the behavior is customizable for each spaces. Since this is a more featured extension, the trade of, compare to Jerome proposal, is that it is a less flexible approach, the velocity code being already written with some predefined behavior. Anyway, I hope you were interested by my story. If you want more, I am open to share any of these patches... but to be really useful in a general case, additional tuning is probably required. Thanks for reading me. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi everyone, Could you tell me if it's normal or if it's a bug; in fact i'm not sure. I'm using jbosscache in local mode but attributes "timeToLiveSeconds" and "maxNodes" in default-local.xml are not taken into account. It's default.xml which is use. Here are my configurations files : xwiki.properties : [...] cache.cacheHint=jbosscache cache.localCacheHint=jbosscache/local [...] default-local.xml : <?xml version="1.0" encoding="UTF-8"?> <server> <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache"> <!-- Specific eviction policy configurations. This is LRU --> <attribute name="EvictionPolicyConfig"> <config> <attribute name="wakeUpIntervalSeconds">5</attribute> <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute> <!-- Cache wide default --> <region name="/xwiki"> <!-- NOT TAKEN INTO ACCOUNT, BUG ? --> <attribute name="maxNodes">5002</attribute> <attribute name="timeToLiveSeconds">21602</attribute> </region> </config> </attribute> </mbean> </server> default.xml : <?xml version="1.0" encoding="UTF-8"?> <server> <!-- ==================================================================== --> <!-- Defines JBoss Cache configuration --> <!-- ==================================================================== --> <!-- Note the value of the 'code' attribute has changed since JBC 1.x --> <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache"> <!-- Specific eviction policy configurations. This is LRU --> <attribute name="EvictionPolicyConfig"> <config> <attribute name="wakeUpIntervalSeconds">5</attribute> <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute> <!-- Cache wide default --> <region name="/xwiki"> <attribute name="maxNodes">5001</attribute> <attribute name="timeToLiveSeconds">21601</attribute> </region> </config> </attribute> </mbean> </server> In fact, the 'maxNodes' and 'timeToLiveSeconds' which are used are 5001 and 21601. Is it normal ? I would like adding that I'm trying to optimise my cache configuration because we have error "java.lang.OutOfMemoryError: Java heap space" one or twice a week and we are suspecting a cache problem. ( Tomcat parameters used are : -Xms1024m -Xmx1048m -XX:MaxPermSize=128m [...] ) We have many errors look like arround the OutofMemory : 08:47:45,880 [http://wiki-soa.airfrance.fr/xwiki/bin/view/XWiki/MyTestClass] ERROR aseEvictionAlgorithm Eviction of /xwiki/wikidict:BlogToolbar.WebPreferences failed java.lang.NullPointerException at org.apache.log4j.Category.log(Category.java:849) at org.apache.commons.logging.impl.Log4JLogger.trace (Log4JLogger.java:152) at org.jboss.cache.factories.ComponentRegistry.invocationsAllowed (ComponentRegistry.java:816) at org.jboss.cache.invocation.CacheInvocationDelegate.cacheStatusCheck (CacheInvocationDelegate.java:582) at org.jboss.cache.invocation.CacheInvocationDelegate.evict (CacheInvocationDelegate.java:355) at org.jboss.cache.eviction.BaseEvictionPolicy.evict (BaseEvictionPolicy.java:27) at org.jboss.cache.eviction.BaseEvictionAlgorithm.evictCacheNode (BaseEvictionAlgorithm.java:231) at org.jboss.cache.eviction.LRUAlgorithm.evict (LRUAlgorithm.java:92) at org.jboss.cache.eviction.LRUAlgorithm.prune (LRUAlgorithm.java:172) at org.jboss.cache.eviction.BaseEvictionAlgorithm.process (BaseEvictionAlgorithm.java:116) at org.jboss.cache.eviction.EvictionTimerTask.handleRegion (EvictionTimerTask.java:133) at org.jboss.cache.eviction.EvictionTimerTask.processRegions (EvictionTimerTask.java:118) at org.jboss.cache.eviction.EvictionTimerTask.access$000 (EvictionTimerTask.java:28) at org.jboss.cache.eviction.EvictionTimerTask$1.run (EvictionTimerTask.java:106) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) But in fact I don't know if this error is a cause or a consequence of this OutOfMemoryError. Thanks, Julien Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en ligne sur http://www.airfrance.com Find best Air France fares, manage your reservations and check in online at http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent être de nature confidentielle et soumis au secret professionnel et sont destinés à l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous recevez cette communication par erreur, nous vous demandons de ne pas la copier, l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à l'expéditeur et d'effacer immédiatement cette communication de votre système. Société Air France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX The data and information contained in this message may be confidential and subject to professionnal secrecy and is intended for the exclusive use of the recipient at the address shown above. If you receive this message by mistake, we ask you not to copy, use or disclose it. Please notify this error to the sender immediately and delete this message from your system. Société Air France - Limited company with capital of 1,901,231,625 euros - Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX Pensez à l'environnement avant d'imprimer ce message. Think of the environment before printing this mail.
On Wed, Feb 24, 2010 at 11:38, Julien Revert <[email protected]> wrote:
Hi everyone,
Could you tell me if it's normal or if it's a bug; in fact i'm not sure. I'm using jbosscache in local mode but attributes "timeToLiveSeconds" and "maxNodes" in default-local.xml are not taken into account. It's default.xml which is use.
It depends of the cache actually. Some caches are using "default" and some others are using "default-local". Most of the caches are using default.xml as default configuration. See http://code.xwiki.org/xwiki/bin/view/Modules/CacheModule for more. This goal was to separate caches we could want to synchronize between several XWiki instances (default) and caches for which it's not useful (default-local). But this distinction is not useful anymore since clustering is not done using cache configuration anymore (as you already know it ;)). We should probably remove the default-local things and make all caches use default.xml as default configuration file. Now about maxNodes, if you are trying to set the document cache size specifically, the best is probably to set the xwiki.store.cache.capacity property in xwiki.cfg file.
Here are my configurations files : xwiki.properties : [...] cache.cacheHint=jbosscache cache.localCacheHint=jbosscache/local [...]
default-local.xml : <?xml version="1.0" encoding="UTF-8"?> <server> <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache"> <!-- Specific eviction policy configurations. This is LRU --> <attribute name="EvictionPolicyConfig"> <config> <attribute name="wakeUpIntervalSeconds">5</attribute> <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default --> <region name="/xwiki"> <!-- NOT TAKEN INTO ACCOUNT, BUG ? --> <attribute name="maxNodes">5002</attribute> <attribute name="timeToLiveSeconds">21602</attribute> </region> </config> </attribute> </mbean> </server>
default.xml : <?xml version="1.0" encoding="UTF-8"?> <server> <!-- ==================================================================== --> <!-- Defines JBoss Cache configuration --> <!-- ==================================================================== --> <!-- Note the value of the 'code' attribute has changed since JBC 1.x --> <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache"> <!-- Specific eviction policy configurations. This is LRU --> <attribute name="EvictionPolicyConfig"> <config> <attribute name="wakeUpIntervalSeconds">5</attribute> <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default --> <region name="/xwiki"> <attribute name="maxNodes">5001</attribute> <attribute name="timeToLiveSeconds">21601</attribute> </region> </config> </attribute> </mbean> </server>
In fact, the 'maxNodes' and 'timeToLiveSeconds' which are used are 5001 and 21601.
Is it normal ?
I would like adding that I'm trying to optimise my cache configuration because we have error "java.lang.OutOfMemoryError: Java heap space" one or twice a week and we are suspecting a cache problem. ( Tomcat parameters used are : -Xms1024m -Xmx1048m -XX:MaxPermSize=128m [...] ) We have many errors look like arround the OutofMemory : 08:47:45,880 [http://wiki-soa.airfrance.fr/xwiki/bin/view/XWiki/MyTestClass] ERROR aseEvictionAlgorithm Eviction of /xwiki/wikidict:BlogToolbar.WebPreferences failed java.lang.NullPointerException at org.apache.log4j.Category.log(Category.java:849) at org.apache.commons.logging.impl.Log4JLogger.trace (Log4JLogger.java:152) at org.jboss.cache.factories.ComponentRegistry.invocationsAllowed (ComponentRegistry.java:816) at org.jboss.cache.invocation.CacheInvocationDelegate.cacheStatusCheck (CacheInvocationDelegate.java:582) at org.jboss.cache.invocation.CacheInvocationDelegate.evict (CacheInvocationDelegate.java:355) at org.jboss.cache.eviction.BaseEvictionPolicy.evict (BaseEvictionPolicy.java:27) at org.jboss.cache.eviction.BaseEvictionAlgorithm.evictCacheNode (BaseEvictionAlgorithm.java:231) at org.jboss.cache.eviction.LRUAlgorithm.evict (LRUAlgorithm.java:92) at org.jboss.cache.eviction.LRUAlgorithm.prune (LRUAlgorithm.java:172) at org.jboss.cache.eviction.BaseEvictionAlgorithm.process (BaseEvictionAlgorithm.java:116) at org.jboss.cache.eviction.EvictionTimerTask.handleRegion (EvictionTimerTask.java:133) at org.jboss.cache.eviction.EvictionTimerTask.processRegions (EvictionTimerTask.java:118) at org.jboss.cache.eviction.EvictionTimerTask.access$000 (EvictionTimerTask.java:28) at org.jboss.cache.eviction.EvictionTimerTask$1.run (EvictionTimerTask.java:106) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462)
But in fact I don't know if this error is a cause or a consequence of this OutOfMemoryError.
Thanks,
Julien
Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en ligne sur http://www.airfrance.com Find best Air France fares, manage your reservations and check in online at http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent être de nature confidentielle et soumis au secret professionnel et sont destinés à l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous recevez cette communication par erreur, nous vous demandons de ne pas la copier, l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à l'expéditeur et d'effacer immédiatement cette communication de votre système. Société Air France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX The data and information contained in this message may be confidential and subject to professionnal secrecy and is intended for the exclusive use of the recipient at the address shown above. If you receive this message by mistake, we ask you not to copy, use or disclose it. Please notify this error to the sender immediately and delete this message from your system. Société Air France - Limited company with capital of 1,901,231,625 euros - Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX Pensez à l'environnement avant d'imprimer ce message. Think of the environment before printing this mail. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Ok, thanks for your answer. In fact i had also change the other parameter (I haven't found any information about this parameter on your website, maybe it will be good to add something on it ?) : xwiki.store.cache.pageexistcapacity (Which is in fact the maxNode for cache xwiki.store.pageexistcache) in xwiki.cfg. I'm agree, maybe it will be easier to understanding if you remove default-local.xml in fact. Julien Thomas Mortagne <thomas.mortagne@ xwiki.com> A Envoyé par : XWiki Developers <[email protected]> devs-bounces@xwik cc i.org Objet Re: [xwiki-devs] Question on 24/02/2010 14:28 JBossCache configuration and EvictionPolicyConfig... Veuillez répondre à XWiki Developers <[email protected]> On Wed, Feb 24, 2010 at 11:38, Julien Revert <[email protected]> wrote:
Hi everyone,
Could you tell me if it's normal or if it's a bug; in fact i'm not sure. I'm using jbosscache in local mode but attributes "timeToLiveSeconds" and "maxNodes" in default-local.xml are not taken into account. It's default.xml which is use.
It depends of the cache actually. Some caches are using "default" and some others are using "default-local". Most of the caches are using default.xml as default configuration. See http://code.xwiki.org/xwiki/bin/view/Modules/CacheModule for more. This goal was to separate caches we could want to synchronize between several XWiki instances (default) and caches for which it's not useful (default-local). But this distinction is not useful anymore since clustering is not done using cache configuration anymore (as you already know it ;)). We should probably remove the default-local things and make all caches use default.xml as default configuration file. Now about maxNodes, if you are trying to set the document cache size specifically, the best is probably to set the xwiki.store.cache.capacity property in xwiki.cfg file.
Here are my configurations files : xwiki.properties : [...] cache.cacheHint=jbosscache cache.localCacheHint=jbosscache/local [...]
default-local.xml : <?xml version="1.0" encoding="UTF-8"?> <server> <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache"> <!-- Specific eviction policy configurations. This is LRU --> <attribute name="EvictionPolicyConfig"> <config> <attribute name="wakeUpIntervalSeconds">5</attribute> <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default --> <region name="/xwiki"> <!-- NOT TAKEN INTO ACCOUNT, BUG ? --> <attribute name="maxNodes">5002</attribute> <attribute name="timeToLiveSeconds">21602</attribute> </region> </config> </attribute> </mbean> </server>
default.xml : <?xml version="1.0" encoding="UTF-8"?> <server> <!--
==================================================================== -->
<!-- Defines JBoss Cache configuration --> <!--
==================================================================== -->
<!-- Note the value of the 'code' attribute has changed since JBC 1.x --> <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache"> <!-- Specific eviction policy configurations. This is LRU --> <attribute name="EvictionPolicyConfig"> <config> <attribute name="wakeUpIntervalSeconds">5</attribute> <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default --> <region name="/xwiki"> <attribute name="maxNodes">5001</attribute> <attribute name="timeToLiveSeconds">21601</attribute> </region> </config> </attribute> </mbean> </server>
In fact, the 'maxNodes' and 'timeToLiveSeconds' which are used are 5001 and 21601.
Is it normal ?
I would like adding that I'm trying to optimise my cache configuration because we have error "java.lang.OutOfMemoryError: Java heap space" one or twice a week and we are suspecting a cache problem. ( Tomcat parameters used are : -Xms1024m -Xmx1048m -XX:MaxPermSize=128m [...] ) We have many errors look like arround the OutofMemory : 08:47:45,880 [http://wiki-soa.airfrance.fr/xwiki/bin/view/XWiki/MyTestClass] ERROR aseEvictionAlgorithm Eviction of /xwiki/wikidict:BlogToolbar.WebPreferences failed java.lang.NullPointerException at org.apache.log4j.Category.log(Category.java:849) at org.apache.commons.logging.impl.Log4JLogger.trace (Log4JLogger.java:152) at org.jboss.cache.factories.ComponentRegistry.invocationsAllowed (ComponentRegistry.java:816) at org.jboss.cache.invocation.CacheInvocationDelegate.cacheStatusCheck (CacheInvocationDelegate.java:582) at org.jboss.cache.invocation.CacheInvocationDelegate.evict (CacheInvocationDelegate.java:355) at org.jboss.cache.eviction.BaseEvictionPolicy.evict (BaseEvictionPolicy.java:27) at org.jboss.cache.eviction.BaseEvictionAlgorithm.evictCacheNode (BaseEvictionAlgorithm.java:231) at org.jboss.cache.eviction.LRUAlgorithm.evict (LRUAlgorithm.java:92) at org.jboss.cache.eviction.LRUAlgorithm.prune (LRUAlgorithm.java:172) at org.jboss.cache.eviction.BaseEvictionAlgorithm.process (BaseEvictionAlgorithm.java:116) at org.jboss.cache.eviction.EvictionTimerTask.handleRegion (EvictionTimerTask.java:133) at org.jboss.cache.eviction.EvictionTimerTask.processRegions (EvictionTimerTask.java:118) at org.jboss.cache.eviction.EvictionTimerTask.access$000 (EvictionTimerTask.java:28) at org.jboss.cache.eviction.EvictionTimerTask$1.run (EvictionTimerTask.java:106) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462)
But in fact I don't know if this error is a cause or a consequence of this OutOfMemoryError.
Thanks,
Julien
Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en ligne sur http://www.airfrance.com Find best Air France fares, manage your reservations and check in online at http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent être de nature confidentielle et soumis au secret professionnel et sont destinés à l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous recevez cette communication par erreur, nous vous demandons de ne pas la copier, l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à l'expéditeur et d'effacer immédiatement cette communication de votre système. Société Air France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX The data and information contained in this message may be confidential and subject to professionnal secrecy and is intended for the exclusive use of the recipient at the address shown above. If you receive this message by mistake, we ask you not to copy, use or disclose it. Please notify this error to the sender immediately and delete this message from your system. Société Air France - Limited company with capital of 1,901,231,625 euros - Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX Pensez à l'environnement avant d'imprimer ce message. Think of the environment before printing this mail. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en ligne sur http://www.airfrance.com Find best Air France fares, manage your reservations and check in online at http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent être de nature confidentielle et soumis au secret professionnel et sont destinés à l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous recevez cette communication par erreur, nous vous demandons de ne pas la copier, l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à l'expéditeur et d'effacer immédiatement cette communication de votre système. Société Air France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX The data and information contained in this message may be confidential and subject to professionnal secrecy and is intended for the exclusive use of the recipient at the address shown above. If you receive this message by mistake, we ask you not to copy, use or disclose it. Please notify this error to the sender immediately and delete this message from your system. Société Air France - Limited company with capital of 1,901,231,625 euros - Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX Pensez à l'environnement avant d'imprimer ce message. Think of the environment before printing this mail.
participants (7)
-
Denis Gervalle -
Jerome Velociter -
Julien Revert -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol