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

[Design the new POJO MicroContainer] - JavaBeanValueAnnotationPlugin

by adrian＠jboss.org

Please commit this class. I already fixed this compile once! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070080#4070080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070080

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Failure handling

by tom.baeyens＠jboss.com

i think you already got the first part, but i'll reformulate to build up the complete response. whenever an exception comes out of a process execution, the process instance can be in an invalid state. so you (read: the client) *must* rollback your transaction. every exception that is thrown into the engine, comes back out at the client side (usually wrapped in a JbpmException) exception handlers only can 'overwrite' exceptions that occur in user code and cause the process execution to continue even when an exception occurred. in case you want to rollback the workflow transaction and do something else, there is only one option: you start a new transaction as indicated before in this thread. but note that it is not a good idea to start working on the process execution directly in this thread. as the failing transaction will probably still have database locks on the process execution rows. therefor, i think the best way to handle this is by sending a new command as a job over the async messaging queue to the job executor. the command will do what you want to do (set variables as bill mentioned or take a 'failure' transition,...) in yet another (3rd) transaction. in jee, you might want to send the command job in the afterCompletion of a synchronization. in that case, you're sure that the database locks of the failing transaction are released when the async job executor executes the 3rd transaction with the fail-action. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069967#4069967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069967

16 years, 9 months

1
0
0 / 0

[Design of JBossXB] - Re: Release of JBossXB with no dependence on Oswego Concurre

by alex.loubyansky＠jboss.com

The reason for oswego was 1.4 compliance. If there are no more dependent projects that require 1.4 compliance we can switch to java.util.concurrent. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069923#4069923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069923

16 years, 9 months

1
0
0 / 0

[Design of JBossXB] - Release of JBossXB with no dependence on Oswego Concurrent J

by anil.saldhana＠jboss.com

Is it possible to get a release of XB that uses the JDK5 concurrent classes and relinquishes the dependence on oswego concurrent jar. The mavenized security project needs to pull in the oswego jars because of XB. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069905#4069905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069905

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Exposing management operations

by scott.stark＠jboss.org

while its straightforward to express the properties that correspond to managed properties from the deployment attachment, its not so for the managed operations. Take the case of the datasource root managed object attachment. This contains the properties, but the operations need to be bound to an mbean whose name is not know until deployment time. It seems like there needs to be a ManagementOperation annotation that can be used to describe a reference to an operation that will be resolved during deployment processing. Something like: | @ManagementObject( | name="TheDS", | operations={@ManagementOperation(target="TheDSPool", name="flush", signature={})} | ) | public class DSMetaData implements Serializable | { | @ManagementProperty(name="display-name", use={}) | public String getDiplayName() | | ... | } | I'm not sure how to integrate this into the mc processing. There is also the issue of how to map the "TheDSPool" alias onto the actual mbean name for the DeploymentUnit this metadata is associated with. What are others thoughts on how to associate the managed operations with the ManagedObject? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069896#4069896 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069896

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType

by scott.stark＠jboss.org

I have added a org.jboss.metatype.api.types.Name and org.jboss.metatype.plugins.types.StringName default implementation. This has been added to the MetaType.ALLOWED_CLASSNAMES. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069843#4069843 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069843

16 years, 9 months

1
0
0 / 0

[Design of Security on JBoss] - Re: TimedCachedPolicy never removes entries from cache

by scott.stark＠jboss.org

Sure, but the impl needs to be updated to use a ConcurrentHashMap so that the flush is not blocking access. You could also look at using the java.util.concurrent.DelayQueue to know exactly when entries have expired and how many have expired. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069841#4069841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069841

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Need a NamedObject SimpleMetaType

by scott.stark＠jboss.org

In working with ManagedObjects that contain properties that are references to other ManagedObjects, I need to be able to represent this type of property, so I want to introduce a SimpleMetaType NAMEDOBJECT. This is equivalent to the jmx SimpleType. The only problem with this is that unlike jmx, there is no entry point for resolving the NAMEDOBJECT. The value of a NAMEDOBJECT property is simply the referenced object name. The issue is, what is the reference resolver. The only logical place is the add support for this to the ManagedObject interface: | interface Name | { | String getName(); | } | | public interface ManagedObject extends Serializable | { | ... | /** | * Resolve a named object reference. | * | * @param name - the reference name to resolve | * @return the ManagedObject the name resolves to if found, | * null otherwise. | */ | ManagedObject resolveName(Name name); | } | This looks like containment, but in general it will not be and the ManagedObject impl needs some registry impl. Maybe there should just be a property ManagedObjectRegistry api for this and that is where the resolution has to be done as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069776#4069776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069776

16 years, 9 months

1
0
0 / 0

[Design of Security on JBoss] - Re: TimedCachedPolicy never removes entries from cache

by anil.saldhana＠jboss.com

This discussion is wrt http://jira.jboss.com/jira/browse/JBAS-3986 I am wondering maybe we can flush the cache at a configurable number of access. If the cache is accessed at say the 100th time, do a cache flush. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069775#4069775 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069775

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Failure handling

by estaub

Bill, >> Then the business process would be in an inconsistent state, wouldn't it? Yes. I suppose yet another option is to commit the transaction that entered the node, then start a new transaction for all db work thenceforth (including the actionhandler), both JBPM and not. If, when the actionhandler returns, a rollback has occurred, a third transaction could be started to do exception handling and any subsequent behavior. Incidentally, this is another area where the current recursive-traversal model makes correct implementation difficult. -Ed Staub View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069773#4069773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069773

16 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2007