August 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes (Repost)

by adrian＠jboss.org

"alesj" wrote : This move | - protected MetaDataContext createMetaDataContext(List retrievals) | made the following classes: | - CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) | - PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) | - LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) | - TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) | useless, since they don't serve the caching override function anymore. | You should add @Override so it doesn't compile if somebody refactors the callback. Why didn't I see any failing tests? I must be blind? anonymous wrote : | What's the best way to port this? | Overriding this in some ControllerContext impl doesn't seem like a good fit. I don't think there is a one best way. The simplest would be to allow a setMetaDataContextFactory() on the ScopeInfo, it could be set by the BasicKernelMDR if you want. If you wanted to be "clever", you could make it a piece of metadata itself. :-) i.e. which MetaDataContextFactory to use by looking through the retrievals before you construct it. That would allow application and system wide construction, but how it gets populated is a different question. NOTE: The deployers also do this, see DefaultScopeBuilder, although there you can override it by adding a ScopeBuilder attachment to your deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169648#4169648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169648

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes

by adrian＠jboss.org

"alesj" wrote : This move | - protected MetaDataContext createMetaDataContext(List retrievals) | made the following classes: - CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) - PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) - LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) - TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) useless, since they don't serve the caching override function anymore. You should add @Override so it doesn't compile if somebody refactors the callback. Why didn't I see any failing tests? I must be blind? anonymous wrote : | What's the best way to port this? | Overriding this in some ControllerContext impl doesn't seem like a good fit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169648#4169648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169648

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction redesign

by manik.surtani＠jboss.com

Re: XML configuration, I also propose dropping defaultPolicyClass and defaultEventQueueSize from the eviction element since there is a default element within the eviction element to denote settings for the default region, e.g.: | <eviction wakeUpInterval="5"> | <default policyClass="o.j.c.e.SimpleEvictPolicy" algorithmClass="o.j.c.e.LFUAlgorithm" eventQueueSize="100000"> | <properties> | maxNodes=10 | timeToLive=300 | </properties> | </default> | </eviction> | Or is this shorthand for | <region name="/" ...> | pointless? WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169646#4169646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169646

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBoss Remote API with in the Jboss AS 4.21

by ron.sigal＠jboss.com

Hi crr, Could you post this question on the Remoting users forum at http://www.jboss.com/index.html?module=bb&op=viewforum&f=222 and elaborate about your application? Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169645#4169645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169645

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction redesign

by manik.surtani＠jboss.com

Okay, so here is what I propose (and yes, it will break existing custom eviction policies and cfgs). Just to sum things up first, there are 4 tasks involved in the eviction system: 1. Identify and record node activity (performed by the EvictionInterceptor, recorded on the Region) 2. Triggering processing of eviction queue (performed either by the EvictionTimerTask, or manually by calling Region.getEvictionPolicy().getEvictionAlgorithm().process()) 3. Identifying which nodes are to be evicted: EvictionAlgorithm.process() 4. Evicting the node: EvictionPolicy.evict(); 2 triggers 3 which triggers 4, so logically only 2 need be exposed to users via an API. E.g., Region should just have 3 eviction-related methods on its public interface: | Region.processEvictionQueue(); | Region.resetEvictionQueue(); | Region.putNodeEvent(); // used by the EvictionInterceptor | EvictionPolicy and EvictionAlgorithm are never exposed to client code. Configuration There have been requests for greater flexibility here, and I think there are 4 aspects to configuring eviction, which should be independent of one another: * Region - region that the cfg applies to * EvictionAlgorithm - how are nodes selected for eviction * EvictionAlgorithmConfiguration - cfg details for an EvictionAlgorithm, such as maxNodes, etc. * EvictionPolicy - what happens when nodes are evicted * ancillary aspects to the eviction region such as queue size The above will allow people to configure a LFUAlgorithm with, for example, SimpleEvictPolicy that just does a cache.evict(). Or, an LFUAlgorithm could be coupled with a RemoveOnEvictPolicy, which as the name suggests, does a remove. Basically I see the following exposed on each of the interfaces: | EvictionPolicy.evict(Fqn f); // this is what happens when a node is evicted. | | EvictionAlgorithm.process(Queue eventQueue, EvictionPolicy policy); // processes a region. Decides what to evict, sets up internal queues, and then calls policy.evict(); | Region.processEvictionQueue() would: | algorithm.process(eventQueue, policy); | I also propose that we change the XML configuration to be more consisent with what w are doing with cache loaders, to look like: | <eviction wakeupInterval="5000"> | <region name="/org/mydata" policyClass="o.j.c.e.SimpleEvictPolicy" algorithmClass="o.j.c.e.LFUAlgorithm" eventQueueSize="100000"> | <properties> | maxNodes=10 | timeToLive=300 | </properties> | </region> | </eviction> | What do people think? The benefit is a much cleaner and easier-to-understand set of interfaces and extension points. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169644#4169644 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169644

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes

by alesj

"alesj" wrote : This is passing for me in IDE. | Due to luck/random behavior? OK, got the failure: | *** DEPLOYMENTS IN ERROR: Name -> Error | simple -> java.lang.IllegalStateException: Unable to register context name=simple state=Not Installed, name already exists: simple | Should be able to fix it now. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169638#4169638 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169638

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes

by alesj

"alesj" wrote : | Overriding this in some ControllerContext impl doesn't seem like a good fit. | e.g. | protected void initKernelScopeInfo() | { | String className = null; | Object target = getTarget(); | if (target != null) | className = target.getClass().getName(); | BeanMetaData bmd = getBeanMetaData(); | if (bmd != null) | { | String bean = bmd.getBean(); | if (bean != null) | className = bean; | } | setScopeInfo(createScopeInfo(className, bmd)); | } | | protected ScopeInfo createScopeInfo(String className, BeanMetaData bmd) | { | return new KernelScopeInfo(getName(), className, bmd); | } | Where you could push in your ControllerContext impl, which would override this createScopeInfo method, providing ScopeInfo that again has overridden createMetaDataContext method. Yuck. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169636#4169636 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169636

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes

by alesj

This move | projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java | =================================================================== | --- projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 14:37:38 UTC (rev 76832) | +++ projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 15:11:04 UTC (rev 76833) | @@ -21,20 +21,13 @@ | */ | ... | | - | - /** | - * Create metadata context. | - * | - * @param retrievals the retrievals | - * @return new metadata context instance | - */ | - protected MetaDataContext createMetaDataContext(List<MetaDataRetrieval> retrievals) | - { | - return new AbstractMetaDataContext(null, retrievals); | - } | } | made the following classes: - CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) - PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) - LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) - TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic) useless, since they don't serve the caching override function anymore. What's the best way to port this? Overriding this in some ControllerContext impl doesn't seem like a good fit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169635#4169635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169635

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: cache statistics via JMX

by manik.surtani＠jboss.com

BuddyManager - current group details (data owner name and buddies) as well as groups the current cache participates in, as a buddy. RPCManager - channel information (configuration stack, bound address and port, JGroups View) Cache configuration (read-only for non-@Dynamic fields, ability to modify for @Dynamic fields?) Eviction queue status - but wait for JBCACHE-1141 for this. LockManager - locks currently held? Essentially invoking LockManager.printLockInfo()? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169634#4169634 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169634

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes

by alesj

"adrian(a)jboss.org" wrote : | 1) ScopingOverridingTestCase | | This is failing because of the problem I suspected when taling to Kabir | about the issue that led to finding JBMICROCONT-330 | i.e. a scoped controller context is sharing the same metadata | as one that should not be scoped. | This is passing for me in IDE. Due to luck/random behavior? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169632#4169632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169632

17 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008