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

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

by bstansberry＠jboss.com

Does keeping any of the options around beyond the life of a single invocation make sense? When I look at them they all seem like one-time-only settings. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052648#4052648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052648

18 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - http://jira.jboss.org/jira/browse/JBMESSAGING-861

by sergeypk

http://jira.jboss.org/jira/browse/JBMESSAGING-861 - Change the test framework to use remoting-service.xml configuration for testing, and drop ServiceContainer duplicate remoting configuration. I have an implementation of this ready but I'm not sure on certain points: a) the HTTP invoker is configured differently from socket-based invokers. If we are to configure the HTTP invoker from XML as well, should remoting-service.xml then be split into remoting-service-http.xml and remoting-service-bisocket.xml? Or should remoting-service.xml contain settings for both invokers? b) Should the bisocket configuration be shared among other socket-based invokers (socket, sslsocket, sslbisocket), or should I add a separate file for each of the invokers, thus duplicating the common settings? c) The way I've implemented this is I load remoting-service.xml, get hold of the configuration, fetch all attributes with isParam set and combine their keys and values to form the URL, since as far as I understand, the URL should only contain those attributes marked with isParam=true. However, serverSocketClass was originally included in the URL even though it is not marked with isParam. Is this the way it should be or is this an oversight? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052644#4052644 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052644

18 years, 10 months

1
0
0 / 0

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

by jason.greene＠jboss.com

If we do this, we could keep options around for ever (no CL leak) by having the Options object delegate to a hashmap on the threadlocal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052629#4052629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052629

18 years, 10 months

1
0
0 / 0

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

by manik.surtani＠jboss.com

Hmm, this is very specialised use of the listener. Not 'normal' usage, IMO ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052616#4052616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052616

18 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remote replyto functionality - Bridge configuration in p

by timfox

Haven't forgotten about this. Will reply soon. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052605#4052605 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052605

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - JSF Components to move into main CVS

by david.lloyd＠jboss.com

I've been considering what to do about the jBPM Facelets component library for the upcoming release, and I think it would be best to move it out of the new repository and into the current jBPM CVS repository. This allows the component library to track with jBPM releases and will make bug fixing and maintenance easier overall. So, I want to make the following changes: * Add a jbpm4jsf subproject into the main CVS repository * Update the build system so that jbpm4jsf is built by default, and include it as a project dependency rather than as an external JAR Any objections or opinions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052599#4052599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052599

18 years, 10 months

1
0
0 / 0

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

by bstansberry＠jboss.com

That's via the Option too, right? All the stuff in Option is appropriate for a client API, except I guess failSilently which AIUI is an implementation detail of putForExternalRead. How about using interfaces for this -- InvocationContext and InvocationContextSPI, plus InvocationContextImpl? The InvocationContext interface just exposes the getters that make sense for a client, and via getOptionOverrides() makes the Option available. If getOptionOverrides() is the only thing a client InvocationContext interface should expose, then maybe it makes more sense to change Cache so it exposes Cache.getOptionOverride() rather than getInvocationContext(). CacheSPI can expose getInvocationContext(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052598#4052598 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052598

18 years, 10 months

1
0
0 / 0

[Design of JBoss Build System] - Re: What is this circular dependency issue in common-core?

by pgier

Ok, I think it should be good to go now. If you grab the updates from svn, then the release should be ok. I removed the purge local repository step from the parent pom because that seemed to be causing the problem. So that part might have to be a manual step until I figure out how to better automate it. For the common project, I'd like to remove the common parent since each of the common modules have their own release schedule and are separate in svn. Most of the configuration is in the jboss-parent anyway, so I will probably just have the modules point directly to that one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052596#4052596 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052596

18 years, 10 months

1
0
0 / 0

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

by bstansberry＠jboss.com

More stuff that's too late for the 2.0 API... This is morning shower thinking, so not very fleshed out. What do people think about adding CacheListener callbacks related to block/unblock events? Vladimir has done some stuff related to state transfer handling to prevent calls proceeding into the cache during block, wait for in progress txs to complete or roll them back if they take too long etc. But it seems like the app would have a better idea of how to do that, with Vladimir's stuff a 2nd line of defense. For example, if the http session repl layer knew the cache was blocking, it could prevent calls into the cache and would have a better idea of how to deal with any tx rollbacks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052594#4052594 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052594

18 years, 10 months

1
0
0 / 0

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

by manik.surtani＠jboss.com

Needed by Hibernate providers to inject their own DataVersion implementations for optimistically locked nodes, where versioning is maintained elsewhere (e.g., in a DB). Among other things. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052593#4052593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052593

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