JBCACHE-1156 [WAS: Priority issues for AS 5}
by Brian Stansberry
Manik Surtani wrote:
>
> On 13 Sep 2007, at 06:35, Brian Stansberry wrote:
>>
>
> Surely 1156 is pretty straightforward? Just a bunch of pre-configured
> profiles with a ProfileCacheFactory which takes a profile name rather
> than a cfg file or object, right?
I want to think through the 1156 use cases and do it right. I don't
think any of them are particularly hard though.
E.g. I'd like it to serve as a registry for caches, so if I ask for a
cache that's already running I get that cache. So, when Hibernate
creates a bunch of entity and collection caching regions, each goes to
the service and gets the shared "standard-entity-cache". Similar thing
for webapp deployments.
Also would be nice to be able to request configurations. So, a web app
deploys with
"<replication-config><synchronous>true<synchronous></replication-config>"
configured in its jboss-web.xml:
1) Asks for the "standard-web-session" Configuration.
2) If it exists, checks to see if it's REPL_SYNC.
3) Nope; check for the "standard-web-session,mode=SYNC" configuration.
4) Nope; create it by modifying my copy of "standard-web-session".
Register that with the service under "standard-web-session,mode=SYNC"
5) Ask for the "standard-web-session,mode=SYNC" Cache; use it.
Next webapp configured takes a different route down the decision tree
and ends up with the already existing cache.
Goal here is to make it easy to expose one or two config elements in
something like jboss-web.xml. But still end up with shared caches.
A further complication is whether the request is for a PojoCache or a
plain cache.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
18 years
- 1
- 0
maven test output stops when System.out.println calls are encountered
by Galder Zamarreno
Hi,
I've been running the cache loader migration tests via maven and I
spotted that only the first test results would print to the standard
output. The rest of tests would run, but the output would not appear.
Digging a little bit, I found http://jira.codehaus.org/browse/SUREFIRE-315
Basically, at the end of the first test run, whose results appear on the
STDOUT (TransformingFileCacheLoaderTest),
TestingUtil.recursiveFileRemove(targetLoc) is called which removes some
files created during tests.
Within TestingUtil.recursiveFileRemove(targetLoc) there's a
System.out.println("Deleting file " + file); call which ends up messing
test output. Removing it solves the problem.
If everyone's happy with it, I would change this System.out.println call
to a logger call.
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
18 years
- 3
- 5