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

[Design of JBossCache] - Re: JBCACHE-1025: JBossCache mbean registration fails on Web

by JerryGauth

I've looked at preregistration and see that I can invoke TreeeCache.preregister() to preregister an mbean for which no JBoss service exists. Maybe this is something that should occur in MBeanConfigurator to ensure that any preregistration code is executed? Preregistration isn't necessary to obtain the actual object name used by the server since this can be obtain from the ObjectInstance returned by server.register(). I think the larger issue is that we need to store all of the actual registration names (for the cache and its interceptors) so that they can be used when checking for the existence of an mbean before registering it. I assume that deregistration requires the actual name as well. Bottom line - I think we need to store a registration name map in cache and provide a getter/setter so that the MBeanConfigurator methods can access it. Exposing the cache's object name is insufficient since it can't be used to derive the interceptors' object names on WebSphere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038516#4038516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038516

18 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1025: JBossCache mbean registration fails on Web

by JerryGauth

I've just discovered a related issue when JBossCache isn't configured as a JBoss service. This issue applies when running on JBossAS as well as other servers. Suppose my cache's lifecycle is as follows. TreeCache cache = new TreeCache(); cache.start(); ... // use the cache cache.stop(); cache.destroy(); The start() method invocation will cause the cache's mbeans to be registered, assuming registration is enabled. The destroy() method invocation should deregister the mbeans that were previously registered. However this isn't occurring when the cache is created as noted. When running on JBossAS, the following messages are emitted to the log and cache.destroyService() is never invoked so deregistration never occurs. 10:21:51,053 WARN [ServiceController] Ignoring request to stop nonexistent service: jboss.cache:service=TreeCache-Group 10:21:51,053 WARN [ServiceController] Ignoring request to destroy nonexistent service: jboss.cache:service=TreeCache-Group It appears that the cache client must explicitly invoke cache.stopService() and cache.destroyService() to ensure that the cache is shut down properly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038457#4038457 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038457

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Continue to bundle up Remoting classes in jboss-messagin

by clebert.suconic＠jboss.com

I have seen so many other issues on having these jars on jbossall-client.jar also. I would like also to remove jboss-remoting.jar from jbossall-client.jar. Scott/Dimitris would have to take the decision on doing it. Tom Elrod added this to jbossall-client.jar and as I remember the only reason was to make Customer's life easier... and as this is making their lifes more difficult we should stop doing it. Scott/Dimitris.. .what you guys think? Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038453#4038453 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038453

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Continue to bundle up Remoting classes in jboss-messaging-cl

by jhowell＠redhat.com

Are we going to continue to bundle up the remoting classes in the jboss-messaging-client.jar? Customers are also having problems in their client because jbossall-client.jar does the same thing(bundle up remoting). Is there a reason, that remoting is bundled up in so many jars? Can it exist on it's own as a jar in the client's classpath? This has led to some difficulties when having customers upgrade thier remoting due to a remoting patch. This also leads to some difficulties because users using messaging and EJB3 could possibly be using two different versions of remoting on thier client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038450#4038450 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038450

18 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1025: JBossCache mbean registration fails on Web

by bstansberry＠jboss.com

OK, thanks for explaining where the name "jboss.cache:service=TreeCache-Group" is coming from. That tells me the when MBeanConfigurator.registerInterceptors() is invoked, preRegister() has *not* been called. The preRegister() call is a standard JMX callback the MBeanServer is supposed to make when you register a bean that implements the callback interface. Nothing JBoss-specific about it. See javadoc for javax.management.MBeanRegistration. So it sounds like you're deploying multiple caches and they are conflicting. If these caches aren't meant to cluster with each other, they should have a unique ClusterName anyway. Two possible approaches: 1) Add a TreeCache.setObjectName() and in TreeCache override ServiceMBeanSupport.getObjectName(Object name) to return it if available. Control the object name via configuration without depending on the JBoss deployer reading the "mbean" element's name attribute. 2) Programatically register the cache in JMX; don't count on registerInterceptors to do it. Use whatever name you like. Be sure you register it before calling createService(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038441#4038441 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038441

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: getAvailableTransitions() don't recognize SuperNode

by tom.baeyens＠jboss.com

is indeed a bug. i created http://jira.jboss.com/jira/browse/JBPM-953 thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038432#4038432 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038432

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Fixed failures in ClusteredConnectionFactoryTest

by timfox

Ok I seem to have the test working now. In summary the failures were occurring because when creating a new JMS connection, the call to Client.connect() was failing since the server we were trying against was dead. That is fine, and normally we would deal with this by catching the org.jboss.remoting.CannotConnectionException and retry on the next server. The problem as that the current 2_2_x branch of remoting does not throw a org.jboss.remoting.CannotConnectionException but instead it throws a RuntimeException with a CannotConnectionException nested two deep inside it's initCause() :) I have changed our catch code to take this case into consideration, the code is ugly but it works: | if (t instanceof JMSException) | { | return (JMSException)t; | } | else if ((t instanceof CannotConnectException) || | (t instanceof IOException) || | (t instanceof ConnectionFailedException)) | { | log.warn("Captured Exception:" + t, t); | return new MessagingNetworkFailureException((Exception)t); | } | else if (t instanceof RuntimeException) | { | RuntimeException re = (RuntimeException)t; | | Throwable initCause = re.getCause(); | | if (initCause != null) | { | do | { | if ((initCause instanceof CannotConnectException) || | (initCause instanceof IOException) || | (initCause instanceof ConnectionFailedException)) | { | log.warn("Captured Exception:" + initCause, initCause); | return new MessagingNetworkFailureException((Exception)initCause); | } | initCause = initCause.getCause(); | } | while (initCause != null); | } | } | Ideally remoting should provide a consistent API in the event of network failure. E.g. it should always throw a org.jboss.remoting.CannotConnectionException whether the failure happened in Client::invoke() or Client::connect() or Client::disconnect() or whatever. Currently the behaviour seems to depend on which method is being invoked. I'm not sure why this problem has only just surfaced - has the remoting API changed recently? Anyhow I am now running the test suite so hopefully we can get the patched remoting jar out ASAP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038429#4038429 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038429

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - getAvailableTransitions() don't recognize SuperNode

by camunda

I am not completly sure if it is a bug, but | token.getAvailableTransitions() | only returns the "leavingTransitions" of the node, the token is in currently. Shouldn't also the leavingTransitions of the SuperState be recognized? Somehow related to this JIRA-Issue (which is already fixed): http://jira.jboss.com:8080/jira/browse/JBPM-259[/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038425#4038425 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038425

18 years, 11 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: POP3 and MDB

by acoliver＠jboss.org

Please ask questions about what is now Meldware Mail at buni.org/forums rather than clutter up the JBoss lists with them. Thanks, -Andy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038406#4038406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038406

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Install Items

by adrian＠jboss.org

Well actually you've got to hook up the intallation target as well in there somewhere so you've either got to have | public interface InstallItem | { | // ... | setTarget(Object object) | } | | or | | public interface SingleInstallItem | { | add(Object target, Object item); | } | I think I prefer the second method since it is more stateless for the user (less error prone and less likely to leak) But that means the internal index of install items must also remember which context owns the install item so it can retrieve the target from the context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038327#4038327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038327

18 years, 11 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 April 2007