June 2007 - jboss-dev-forums - Jboss List Archives

[TODO - DEVELOPMENT] - Re: Want to contribute?

by jbynum

I noticed a limitation in the RuleName*AgendaFilter classes and added a new class called RuleNameContainsAgendaFilter to address this need. How do I go about submitting this change? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052689#4052689 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052689

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by bstansberry＠jboss.com

+1. I think we've got a pretty good API now, which is what 2.0.0 is all about, but this is the one weak area. It would be nice to get it right in this area too. I actually don't think the Option API is a border case either. Every usage of JBC I've written, I use an Option at some point. I don't think my usages are that exotic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052675#4052675 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052675

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener callbacks for block/unblock

by bstansberry＠jboss.com

Yeah, I like the annotation approach. In 1.x we have ExtendedTreeCacheListener for just this sort of reason. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052674#4052674 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052674

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener callbacks for block/unblock

by jason.greene＠jboss.com

"bstansberry(a)jboss.com" wrote : Yeah, I agree it's not normal. My only concern here is you can't really add it later. CacheListener is an interface people actually implement themselves, so "an added method isn't an API change" thinking breaks down. | Right instead you have to introduce a new interface (ExtendedCacheListner or BlockCacheListener). One thing I was toying with in POJO Cache, that I might introduce at a later date is an annotation driven listener, which is more flexible and extensible: | @AttachNotificationListener | @DetachNotificationListener | @ListModifyNotificationListener | public myMethod(Notification notification) | { | .... | } | or they could do (both would work) | @AttachNotificationListener | public void myMethod(AttachNotification notification) | { | .... | } | | @DetachNotificationListener | public void myMethod(DetachNotification notification) | { | .... | } | -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052673#4052673 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052673

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by jason.greene＠jboss.com

A one shot option that is not associated with a method is error prone and verbose for calling code. Consider this code | cache.getOptions().setForceWriteLock(true); | String atomicUserCounter = cache.get("/user/123", "counter"); | Later someone assumes this is a persisting option and updates it | cache.getOptions().setForceWriteLock(true); | String atomicUserCounter = cache.get("/user/123", "counter"); | String atomicGroupCounter = cache.get("/group/456", "counter"); | The fix is overly verbose: | cache.getOptions().setForceWriteLock(true); | String atomicUserCounter = cache.get("/user/123", "counter"); | cache.getOptions().setForceWriteLock(true); | String atomicGroupCounter = cache.get("/group/456", "counter"); | That said persistent options could lead to problems as well. An overloaded parameter is neither error prone, nor overly verbose, and is intuitive: | Options options = new Options(); | options.setForceWriteLock(true); | String atomicUserCounter = cache.get("/user/123", "counter", options); | String atomicGroupCounter = cache.get("/group/456", "counter", options); | String regularReadValue = cache.get("/foo", "foo"); | You could even offer constant options (via an immutable extension): | String atomicUserCounter = cache.get("/user/123", "counter", Options.FORCE_WRITE_LOCK); | String atomicGroupCounter = cache.get("/group/456", "counter", Options.FORCE_WRITE_LOCK); | String regularReadValue = cache.get("/foo", "foo"); | -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052667#4052667 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052667

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener callbacks for block/unblock

by bstansberry＠jboss.com

Yeah, I agree it's not normal. My only concern here is you can't really add it later. CacheListener is an interface people actually implement themselves, so "an added method isn't an API change" thinking breaks down. I need to think quite a bit about whether/how I could use such callbacks to get a benefit beyond what Vladimir's done. My "shower thinking" a couple days ago had some ideas, but they don't seem so coherent as I've thought about it today. If it turns out there is a good use for them, I could always of course have the AS do tricks (e.g. a CacheImpl subclass) to get notifications. Ugly, but not the end of the world. In general, this thinking arises out of a concern that the multiplexer is going to lead to more frequent block calls for the JBC instances in the AS. The caches all share a channel, so one app doing a state transfer on a redeploy will cause a block on all caches. So, I'm noodling about strategies to minimize the impact of that. [Semi-OT] One thing I'll have to have a look at is whether the blocking stuff Vladimir did discriminates between txs that have done a write and those that haven't. Unless cache is SERIALIZABLE, there's no reason to prevent reads or to rollback txs that have only done reads. Similar thinking applies to OPTIMISTIC -- since the tx workspace is not included in any state transfer, there is no reason to worry about any optimistic calls except the prepare. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052664#4052664 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052664

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Timer servlet

by david.lloyd＠jboss.com

The timer servlet is currently not part of the jBPM web console's web.xml. Should it be added? In the long term, this should be separated somehow - if a customer removes the web console because they don't want it, they will be quite surprised when all their timers cease to function. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052659#4052659 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052659

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by bstansberry＠jboss.com

No argument there. That's how it is in the 1.x API, but the overloaded methods got cut in a drive to trim the 2.0 API. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052656#4052656 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052656

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss

by bill.burke＠jboss.com

I've been thinking about this a bit the last day. Here's the advantages, IMO, of the new deployer I'm proposing: * Easier for newbie to get start. One last thing they have to worry about. * Easier for development * Less configuration * Doesn't impair other jBPM deployment options * gets in line with how other JEMS projects deploy into JBsos Disadvantages: * Not portable to other application servers. (Until we get JBoss Embedded going). * I don't think this will work well with class versioning unless we add metadata to the .par (like a version number) My questsions are: * How often is versioning used? * How many versions are live at one time? How many versions do applications usually have in play? One last thing: * Maybe with this new deployer, versioning should be turned off by default? * Should a piece of metadata be added to the deployment to say whether or not it should be versioned or just overwrite the old deployment? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052653#4052653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052653

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by jason.greene＠jboss.com

IMO, if they shouldn't survive multiple invocations, then they should just be a parameter, else its really alien to general java usage. cache.put(fqn, key, object, options); -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052652#4052652 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052652

18 years, 10 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 June 2007