Enterprise subproject and EJB spec level

[jeffdelong]

Tom,

I was looking over the enterprise subproject and noticing that the EJB are "old-school" EJB2 beans. I think that given JBoss leadership in EJB3, we should consider updating these beans to EJB3. We can use annotations, and get rid of the ejb-jar.xml files as well.

Also there is a comment in CommandListenerBean,

} catch (Exception e) {
e.printStackTrace();
// TODO add a retry mechanism or verify how this can be configured in the MDB itself
throw new JbpmException("command "+command+" couldn't be executed", e);
}

If the bean is deployed with transaction-attribute required (which is the default), then the container should automatically rollback the transaction if a system exception is thrown, which will cause the JMS Server to retry the message for some configurable number of tries, and then place the message on the DLQ.

You can also catch non-system exception (e.g., an ObjectNotFoundException, InvalidStateException, etc), and invoke setRollbackOnly on the messageDrivenContext, i.e.,

messageDrivenContext.setRollbackOnly();

Jeff

[tom.baeyens]

i would like ADDING ejb3 beans. but i don't want to to remove the EJB2 beans for backward compatibility reasons. the majority of containers will be ejb2 for a while. so we need ejb2 beans.

i have not focussed on ejb3 beans for now because that would imply that we have to factor out the common code. so the ejb3 simplifications would be countertackled by factoring out the common code between the ejb2 and ejb3 beans.

so i'm not sure if that is worth while.

If the bean is deployed with transaction-attribute required (which is the default), then the container should automatically rollback the transaction if a system exception is thrown, which will cause the JMS Server to retry the message for some configurable number of tries, and then place the message on the DLQ.

the thing i don't know is the actual configuration in the deployment descriptor. feel free to add this configuration property in the deployment descriptor if you know which one it is.

You can also catch non-system exception (e.g., an ObjectNotFoundException, InvalidStateException, etc), and invoke setRollbackOnly on the messageDrivenContext, i.e.,

please define non-system exception. afaik this means non-RuntimeExceptions, right ?

[jeffdelong]

Well there is really very little common code to factor out of the bean; most of the common code is in the org.jbpm.command package. So another approach would just be to add a second set of beans that were EJB3 compliant.

I'm not sure I see how this command pattern is working however. I can't see how the instance variables on the command classes get instantiated. For example, how would:

long taskInstanceId = 0;
String transitionName = null;

get set in the TaskInstanceEndCommand? There are no setter methods on the object, nor a non-default constructor that sets them (I must be missing something here).


I have another question about this pattern. The commands are currently limited in the amount of data they provide. So for example, if I wanted to update some contextVariables as part of completing the TaskInstance, I would basically write my own command, say TaskInstanceUpdateAndEnd?

In answer to your questions:

You don't need to add the transaction-attribute of required since it is the default, so how you have the ejb-jar.xml currently will provide the desired behavior. However, to be explicit, you would add

<transaction-attribute>required</transaction-attribute> to the assembly descriptor portion of the ejb-jar.xml.


Yes, non-RuntimeExceptions.

[tom.baeyens]

I'm not sure I see how this command pattern is working however. I can't see how the instance variables on the command classes get instantiated. For example, how would:

long taskInstanceId = 0;
String transitionName = null;

this is done through serialization. the commands can also be persisted with hibernate an the command id can be serialized in the message.

i didn't yet have a look at the transaction attributes. but probably that is going to come soon as i'm trying to set up a test harnass for testing jbpm in a enterprise environment.

[tom.baeyens]

also note that the commands and the ejbs still might have some rough edges that require some refactoring.

it's not all settled yet...

so please keep signalling bad things and proposing alternatives.