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

[Design of POJO Server] - JBAS-5578 ServiceMBeanSupport as MC bean

by bstansberry＠jboss.com

Discussion of http://jira.jboss.com/jira/browse/JBAS-5578 Kind of an odd issue as it relates to doing something strange -- deploying a ServiceMBeanSupport subclass via a beans.xml, and then annotating it as @JMX. The create/start/stop/destroyService methods don't get invoked. This comes up because I tend to try to deploy things as MC beans, but for backwards compatibility reasons things like HASingletonController are still ServiceMBeanSupport subclasses. So I hit weird issues. I can work around them, so not critical. But want to bring it up in case it suggests some more fundamental problem. Anyway, here's what I think is going on: I think this has to do with ServiceControllerLifecycleCallback. The @JMX annotation means this class handles starting the service. Leads to this: ServiceControllerLifecycleCallback.install --> ServiceController.start(ObjectName) --> ServiceController.doChange(controller, context, ControllerState.INSTALLED, "start") does some stuff... and then calls into ServiceMBeanSupport.start() which has this: | if (serviceName != null && isJBossInternalLifecycleExposed) | server.invoke(ServiceController.OBJECT_NAME, "start", new Object[] { serviceName }, SERVICE_CONTROLLER_SIG); | else | jbossInternalStart(); | The first branch of the if test is taken and that calls ServiceController.start(ObjectName) again (i.e. a recursive call). That call hits this and returns: | // If we are already started (can happen in dependencies) just return | if (ctx.state == ServiceContext.RUNNING || ctx.state == ServiceContext.FAILED) | { | log.debug("Ignoring start request for service: " + ctx.objectName + " at state " + ctx.getStateString()); | return; | } | Effect of all this is the startService() method never gets invoked. One possible solution to this is to add a way to configure the bean (a setter) such that isJBossInternalLifecycleExposed returns false. Avoid the recursive call. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155445#4155445 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155445

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - ending process does not end tasks

by kukeltje

http://jira.jboss.com/jira/browse/JBPM-392 and http://jira.jboss.com/jira/browse/JBPM-590 are about this 'problem' 392 is closed as won't fix since there are some related loggings??? I personally do not see the problem here. Why not just cancel them? Related to the ending of a process from a leg of a fork, this is a behaviour two of my colleagues (a minority according to Tom) did not expect. I personally did not expect this as well. There is a workaround to write an actionhandler that cancels all open tasks. The other solution is to add this to the 'end-complete-process' to end all tasks or add a new attribute end-task(s) to the end-state to do this like proposed in http://jira.jboss.com/jira/browse/JBPM-1184. any suggestions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155429#4155429 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155429

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: state transfer optimizations - persisitng state with JDB

by bstansberry＠jboss.com

Ah, now I understand. Yeah, that makes sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155426#4155426 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155426

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: state transfer optimizations - persisitng state with JDB

by manik.surtani＠jboss.com

There could be state on the recipient, since in-memory state is integrated before persistent state. This is why I suspected that the exists() check is an optimisation, since integrating in-memory state will result in a cache loader put() as well. And as for passivation, if the state is in-memory (after integrating in-memory state), it won't (and shouldn't) be in the cacheloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155419#4155419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155419

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: state transfer optimizations - persisitng state with JDB

by bstansberry＠jboss.com

Isn't the idea of state transfer that the recipient has no state in the region being transferred; i.e. it's a complete replace? If so, then for sure there's no need for an exists check. And, if so, then in the passivation case it's the responsibility of the sender to properly segregate the in-memory nodes from the passivated nodes (i.e. it's a bug if it isn't that way already). So, no need to check if a node in the persistent state is in memory before writing it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155412#4155412 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155412

17 years, 10 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - JBAS-5577 Discussion thread

by bstansberry＠jboss.com

Discussion of http://jira.jboss.com/jira/browse/JBAS-5577 . I can understand the desire for this, but let's be careful about overly harming performance or adding too much complexity to support it. The difficulty I see here is the HAPartition.callMethodOnCluster invocation returns a list with no identifying information about who returned the response. So, trying to pick a response based on a previous response won't work at the HA-JNDI level. It could be made more random simply by picking a random location to start iterating through the list. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155403#4155403 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155403

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - JBoss Cache Public API

by manik.surtani＠jboss.com

So I've started on work on JBC 3.0.0. I don't intend to make any public API changes, the main new features are internal, but significant enough to warrant a major version update. But, if anyone can convince me of any reasons why the public API does need to change, now would be a good time to do it. Specifically, genericisation of the Cache interface - which happened in 2.0.0 - is not something I'm overly pleased with as I find it clunky. What do people think, should it stay or go? Ah, there is one public API that is due for a change though. Fqn. No more public constructors, all Fqn construction needs to go through factory methods (which have been in existence for some time now). This will help us optimise Fqns later as needed. Also, Fqn generics are going away. This has been more than just clunky, in fact downright error-prone. And without much value-add. Thoughts, comments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155390#4155390 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155390

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: EJB/War deployer ordering problem

by alesj

"adrian(a)jboss.org" wrote : | I suspect that longer term we'll want some way of retrieving what Seam does | to resolve the ejb so we can properly manage cross deployment | dependencies that Seam creates. | The only thing that I can see us doing is checking to what all we can map @In annotation. e.g. is there some existing EJB that we can map to using field's name | public class SomeSeamComponent | { | @In | private PaymentManager manager; | } | and then use AnnotationEnvironment.classHasFieldAnnotatedWith(In.class) (where In.class must come from unit's classloader). Then we iterate over all fields, checking if we can do some mapping. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155374#4155374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155374

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation Tests in deployers-vfs

by alesj

I've simplified things a bit. "adrian(a)jboss.org" wrote : | i.e. one deployer knows how to scan for bean annotations | That's already GenericAnnotationDeployer. It creates lazy metadata about classes and its annotations. "adrian(a)jboss.org" wrote : | one knows how to create components from a set of such annotations | (mod those that already have metadata). I'm creating metadata from annotations directly, leaving component creation to existing component deployers. | public void deploy(DeploymentUnit unit, AnnotationEnvironment deployment) throws DeploymentException | { | for (AnnotationProcessor processor : processors) | { | String attachmentName = processor.getAnnotation().getName(); | Object annotationAttachment = unit.getAttachment(attachmentName); | Object metadata = processor.createMetaData(annotationAttachment); | if (metadata != null) | unit.addAttachment(attachmentName, metadata); | | Set<Class<?>> classes = deployment.classIsAnnotatedWith(processor.getAnnotation()); | for (Class<?> clazz : classes) | { | metadata = processor.createMetaDataFromClass(clazz); | if (metadata != null) | unit.addAttachment(attachmentName + "#" + clazz.getName(), metadata); | } | } | } | And in case you want to stick your deployer in between (the one that modifies all metadata created from annotations), you can easily iterate over attachments picking only those which name starts with your annotation name. To handle (merging wise) just metadata that comes from annotations doesn't make sense. Since duplicate metadata can pop-up from anywhere - via getAllMetaData(getOutput()) - so it's should be component deployers that know how to handle it. And this must be addressed in general or not addressed at all - leading to failure on duplicate name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155341#4155341 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155341

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ending a process from other token than root token

by nizzy

Didn't even notice I was in the design forum, sorry new topic as requested. http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155336#4155336 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155339#4155339 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155339

17 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 2008