September 2006 - jboss-dev-forums

[Design of JBossCache] - Re: Designing Habanero - Configuration changes

by galder.zamarreno＠jboss.com

That indeed looks quite complicated. What about JBoss AS style? If they wanna make any modifications, repeat all the stack with the desired changes. I think this would be a lot easier than replacing by position or by name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973240#3973240 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973240

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Runtime changes of cache config elements

by manik.surtani＠jboss.com

I'm ok with this being a RT variable, but then it should not be injected into the inteceptors when the chain is configured, but should be referenced directly from the Configuration. You also suggested changing isUseInterceptorMBean to isUseMBean. +1 to both, are you going to make the change together? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973210#3973210 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973210

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: SingletonStoreCacheLoader in 2.0

by manik.surtani＠jboss.com

"vblagojevic(a)jboss.com" wrote : | Whoever wrote CacheLoaderInterceptor.isCustomCacheLoaderConfigured() is a very creative person ! | If you were being serious, I'll take credit for it - if you were being sarcastic, I have no idea who wrote that! :-) "vblagojevic(a)jboss.com" wrote : | Why not create AbstractDelegatingCacheloader class that combines things that are common to all future delegating cacheloaders. One of them is getCacheLoader method but I would implement all cacheloader methods in AbstractDelegatingCacheloader with delegates. Subclasses then just have to override specific methods. For example, I am looking at AsyncCacheLoader and it needs to override only half a dozen methods. | I think this is a good idea, since the majority of cases the call is just passed to the underlying loader. If someone just extends the AbstractDCL he'd end up with the same basic features of the underlying cache loader, and any added behaviour will have to be introduced by overriding methods. It would have to be javadoc'd pretty clearly to that effect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973209#3973209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973209

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Designing Habanero - Configuration changes

by manik.surtani＠jboss.com

"galder.zamarreno(a)jboss.com" wrote : | Manik, is there any reason why you'd want to only add/remove interceptors | and not change the core interceptor chain? Is it to avoid misusage? | This is not out of choice. :-) We have an XML config block that currently builds an interceptor chain based on config options. In the same XML config, adding more custom interceptors before/after this chain is easy, but to modify the chain is hard - imagine some XML element like: | <suppress-interceptor interceptor="org.jboss.cache.TxInterceptor" /> | or | <replace-interceptor position="2" interceptor="my.custom.TxInterceptor" /> | Very ungainly, and presumes that the user knows what sort of chain will be generated. And, as you said, open to a lot of breakage. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973207#3973207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973207

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Designing Habanero - Configuration changes

by manik.surtani＠jboss.com

"ben.wang(a)jboss.com" wrote : | | One other thing to mention is currently PojoCache uses jboss-aop.xml to specify the full interceptor stack. It is little bloated but still manageable, IMO, becuase of JBoss Aop has provided the poincut language. Maybe this is the step for the Cache impl to go? | | I agree, I think this is the way to go in future (eases up on a lot of the biolder-plate crap we have in TreeCache to pass calls up an interceptor stack) and we should be eating our own dog food, but it is way too big a change for now. Maybe in 3.0.0? ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973206#3973206 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973206

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Designing Habanero - Configuration changes

by manik.surtani＠jboss.com

"ben.wang(a)jboss.com" wrote : | Is there a use case to provide the XML interceptor configuration that currently can't be done progrmatically? | User feature requests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973205#3973205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973205

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: state transfer failure handling

by manik.surtani＠jboss.com

I vote a +1 on atomicity. I wouldn't continue after failure, even if we have a complete persistent state and an incomplete transient one. Just easier to deal with. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973203#3973203 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973203

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by timfox

For JMS traffic (e.g. messages) going from server to client, how do you do this? (Obviously you can't have a HTTP server on the client accepting connections) Do you poll the server from the client intermittently, or do you piggyback server to client traffic on return values of client to server traffic, or both? BTW all the stream stuff in the marshaller is a big pain. I have been having related issues since as you realised remoting always passes in a ObjectInput/Ouput Stream. In TRUNK I have changed all this so that now the underlying stream is passed in, so you're changes in that area may not be necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973201#3973201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973201

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: get suspended tasksinstances

by kukeltje

this is a user forum question, and please do not crosspost View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973191#3973191 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973191

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: does optimistic locking always work ?

by tom.baeyens＠jboss.com

session.load(class, id, LockMode.UPGRADE) or session.lock(processInstance, LockMode.UPGRADE) results in "SELECT ... FOR UPDATE" on databases that support pessimistic locking, this will result in a pessimistic lock. We expose the lock already in the JbpmContext (or in the persistence service, i don't remember). So users can start adding pessimistic locks themselves whenever they want to. But I want to work out a solution/workaround/fix that works by only using optimistic locking. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973189#3973189 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973189

19 years, 6 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 September 2006