EJB3 enterprise module?

[camunda]

Hi guys,

what is the current status of an eEJB3 enterprise module (form jbpm 3)? It was discussed quite often already, but nothing is done on this yet, right? Or did I miss any code?

For a current project I will develop it anyway, does it make sense to commit it for others? I know a couple of projects which developed their own EJB3 bean and I get the question in trainings quite often. So I think it would make sense for a lot of people, more than the "old" EJB 2.1 stuff...

What do you guys think?

Could it be put in 3.3. to avoid productization/support effort?

Cheers
Bernd

[heiko.braun]

I was looking into that for jbpm4 as well. But didn't make any progress so far.

[tom.baeyens]

where was that discussed ?

i want to verify the following points:

adding support for storing ejb 3 entities as process variables makes sense to me.

building ejb 3 versions of the command service and timer service do not make sense to me.

[camunda]

So it would maybe help if I commit it for jbpm 3? ;-)
Maybe I can also volunteer to port it to jbpm 4 afterwards, but I am not yet sure if I have the time...

[camunda]

Sorry, the latter was (building ejb3 command and job service and timer).

Why doesn't this make sense to you? Because it doesn't add new functionality?

[heiko.braun]

building ejb 3 versions of the command service and timer service do not make sense to me.

it wasn't dicussed yet. that's what we are doing atm. But what are your concerns?

[tom.baeyens]

in many corporate environments, it will take quite a while before ejb 3 gets adopted.

if we offer ejb 2 beans, developers in those businesses can just deploy them. whereas they might not be able to deploy ejb 3 beans.

ejb 3 is nicer for us to write, but that is not a good argument.

all containers that have ejb3 also can run ejb 2. and we have already ejb 2 versions.

so i don't see the point in spending effort to rebuild our own beans on ejb 3 and by doing so limit the number of environments that jbpm can be deployed in.

[heiko.braun]

well, it's a trivial task. isn't it?

[camunda]

I see more and more projects moving to EJB3. The stuff is easier to understand and even easier to deploy. Actually only having EJB 2.1 support sometimes let jbpm looks "old-fashioned" (never underestimate the marketing factor!). And as I mentioned, I am asked quite a lot for ejb3.

Since you often include jbpm in your own environment or application ejb 3 offers better support. E.g. extending the beans or adding interceptors is easier. And some stuff seems to be better supported with EJB 3 in respect to clustering.

Currently I am rewriting it anyway, so the question comes to if I should commit it, the effort would be reduced to maintenance.

[camunda]

heiko wrote:
well, it's a trivial task. isn't it?

Yepp, I scheduled it for today (and only today ;-)).

[heiko.braun]

I think the biggest problem with the CMP based implementation is the container dependence. It always requires a vendor specific persistence mapping. But if we move to JPA we get rid of that problem.

[tom.baeyens]

I think the biggest problem with the CMP based implementation is the container dependence. It always requires a vendor specific persistence mapping. But if we move to JPA we get rid of that problem.

that makes sense to me. (and makes me change my mind)

so what you're saying is that with ejb3, there is a bigger chance that the .ear file will run without modifications on lets say websphere or weblogic ?

if that is true, then i'm in favour of moving to ejb 3.

with ejb 2, we will not have the time to build those appserver specific deployment descriptors. so ejb 3 would give us better coverage of environments.

[heiko.braun]

so what you're saying is that with ejb3, there is a bigger chance that the .ear file will run without modifications on lets say websphere or weblogic ?

right

[camunda]

Damn, it seems that linking a Timer to an EJB3 Entity seems not to be possible like in EJB 2.1 (regarding https://jira.jboss.org/jira/browse/JBPM-886).

Or if anybody has an idea I would be delighted.

[aguizar]

Damn, it seems that linking a Timer to an EJB3 Entity seems not to be possible like in EJB 2.1 (regarding https://jira.jboss.org/jira/browse/JBPM-886 ).

In the current implementation the Timer POJO is flushed and loaded as an EJB2 entity bean. It works but looks and feels dirty. If the hack is not easily portable to EJB3 then we should just use two different tables. It does not make sense to sacrifice cleanliness just to save one table.

Another thought: the EJB3 stuff should not go into jBPM3, it would mostly bring further maintenance burdens and would certainly not be accepted for inclusion into SOA-P.