Activiti & CDI

[meyerd]

I saw Ronald's commit(s) today and realized that I have something quite similar in the pipeline.

It looks to me like what has been committed today is essentially a set of JSF-Components and a set of CDI-Components and Annotations for Human-Task-Management. Looks pretty cool.

I have something similar although I took it a bit further: I have written a proper CDI-Extension providing an own scope (@ProcessScoped) and also Unified-EL in the process, i.e. I can write sth. like #{myBean.method(…)} 'myBean' being a CDI-managed Bean so potentially also an EJB… (I saw some discussion around EJB-invocation in the last weeks, so this would be yet another possibility )

I have also developed a variation of the travel-expenses process as an example application, deployable using JBoss AS-6 with activiti-engine embedded.

I will try to clean this up and commit it over the weekend.

Ronald, if you are interested in pursuing this, I would be ready to help out and contribute.

Regards,
daniel

[ronald_van_kuij]

I saw Ronald's commit*(s)*

Yes, lots…. ops: <beeep> SVN.. why can't recursive deletes be supported. And getting the flue also does not help to stay focussed

Looks pretty cool.

It's a beginning. Primarily for an internal poc to show the power of jsf2, cdi, primefaces but I wanted it (temporarily?) stored in a public svn to be able to point to it for discussions and write blogs about it.

I have something similar although I took it a bit further: I have written a proper CDI-Extension providing an own scope (@ProcessScoped)

Now *that* is cool. It is^H^Hwas on my todo list for somewhere in the not to distant future. Does this mean you can use procesvariables in EL in a jsf page? or initially just in the java classes? (does not make it less cool) Yet, I also think of supporting something like a variables['….'] construction so metawidget can be used (still needs integration with primefaces, not sure if that is difficult)

ike #{myBean.method(…)} 'myBean' being a CDI-managed Bean so potentially also an EJB… (I saw some discussion around EJB-invocation in the last weeks, so this would be yet another possibility )

And this is cool to. Thought of this to, but I was not sure how difficult it would be to get the Weld/CDI resolver into activiti (I thought it was a composite resolver as well). The 'full' ejb resolver will still be needed afaik, since CDI cannot resolve remote beans.

Ronald, if you are interested in pursuing this, I would be ready to help out and contribute.

Definitely. The core team just has to decide if this is an interesting module to include. If not we could start something external (camunda svn?)

Currently it requires Java EE6 sinceI use a EJB3.1 singleton (no interface) to get the process engine. So we might need some work to either get a generic version that can also be used in Java EE5 or use maven profiles or whatever or just not support Java EE5

I will try to clean this up and commit it over the weekend.

Go ahead, (ab) use my branch  … in light of the 'seam', 'weld', 'solder' (sub project of weld/seam) we could call this 'activiti-glue'. Tom has some nice memories of a 'company' called gluelogic from several years ago

p.s. There is a jira for this.

[meyerd]

Hi Ronald,

just some brief comments:

Does this mean you can use procesvariables in EL in a jsf page? or initially just in the java classes? (does not make it less cool) Yet, I also think of supporting something like a variables['….'] construction so metawidget can be used (still needs integration with primefaces, not sure if that is difficult)

Not yet (I think). I can inject process-variables into a bean but not yet use them in JSF (or anywhere else using UEL for that matter) because only @Named beans have an EL-Name. This is one item to work on.

The 'full' ejb resolver will still be needed afaik, since CDI cannot resolve remote beans.

Right, in CDI you need to tell the container how to resolve the remote EJB using @EJB(…)  and then bind it to sth., e.g. using a producer method. This is not yet what we want. (Although I often think that it is better to write 3 lines of type-safe Java Code instead of xml But that is a matter of taste… ) So yes the 'full' EJB resolver is definitely needed. Even if it was supported, I don't think people want to depend on CDI  for doing this.

Definitely. The core team just has to decide if this is an interesting module to include. If not we could start something external (camunda svn?)

Yes I briefly talked to Bernd about this. We still need to decide but conceptually it is feasible.

Currently it requires Java EE6 sinceI use a EJB3.1 singleton (no interface) to get the process engine. So we might need some work to either get a generic version that can also be used in Java EE5 or use maven profiles or whatever or just not support Java EE5

Yes that would also be a "TBD". If the one singleton is the only place where EE6 is really required, than maybe it is possible to target EE5. Haven't thought about that yet. For me it was also a matter of trying out JBoss AS 6 with activiti etc…

Regards,
daniel

[ronald_van_kuij]

Not yet (I think). I can inject process-variables into a bean but not yet use them in JSF (or anywhere else using UEL for that matter) because only @Named beans have an EL-Name. This is one item to work on.

For (CDI) beans yes, but it is not required to have @Named to be resolved in jsf el resolvers. You just need something to inject it into that 'scope' with a correct name. I have some small el resolver code that reads jsf message properties so you can use that in a class. The other way around would work as easily. I'll put this on my todo list. with a priority.

Right, in CDI you need to tell the container how to resolve the remote EJB using @EJB(…) and then bind it to sth., e.g. using a producer method. This is not yet what we want. (Although I often think that it is better to write 3 lines of type-safe Java Code instead of xml But that is a matter of taste… ) So yes the 'full' EJB resolver is definitely needed. Even if it was supported, I don't think people want to depend on CDI for doing this.

Yep… no more xml hell… (unless e.g for business oriented edi messages) This is kind of how Jorams example worked with spring… just wrapping it.

Yes that would also be a "TBD". If the one singleton is the only place where EE6 is really required, than maybe it is possible to target EE5.

CDI has the notion of application scoped and singleton as well. I just do not seem to be able to get it 'auto started' without e.g. a servletlistener when starting the server. Might be enough though if the first request triggers it (just some small delay then)

[kennardconsulti]

Hi guys,

I am the author of Metawidget, and I'm very excited to hear you are considering integrating it into Activiti! Please let me know if there is anything I can do to assist in the process.

PrimeFaces integration is on our 'wish list' and should be straightforward. The source code for RichFacesWidgetBuilder or TomahawkWidgetBuilder should be a good starting point, as would the chapter on WidgetBuilders in the Reference Guide.

Regards,

Richard.

[ronald_van_kuij]

:lol: I saw a similar response on the primefaces list by you but was not able to send a pm there. I already read on your site what needs to be done, so I  downloaded and will try if I feel better again.

One thing I'm a little worried about is reading that with some components of icefaces metawidget does not play nice (even if the 'cause' might be something in icefaces)

In addition, the usecase might be a little different. We won't have a bean with getters/setters of differently typed fields but most likely a (hash) map with objects of different types, including ones that are beans with getters/setters. Would this pose an issue?

[kennardconsulti]

Hi Ronald,

Thanks for your response. In answer to your questions:

1. Use of ICEfaces (or not) is entirely optional and configurable. We have lots of non-ICEfaces demos. But yes, ICEfaces probably doesn't play 100% nice with other component libraries, due principally to ICEfaces' unique (and very cool) 'Direct-to-DOM' technology. But such issues are outside of Metawidget's jurisdiction

2. No. Metawidget's 'back end' is controlled by a pluggable 'Inspector' interface which is designed to accomodate this (and many other) architectual preferences. For example see http://blog.kennardconsulting.com/2008/06/metawidget-and-namevalue-pairs.html

Regards,

Richard.

[ronald_van_kuij]

Thanks for your response 🙂

1. Use of ICEfaces (or not) is entirely optional and configurable. We have lots of non-ICEfaces demos. But yes, ICEfaces probably doesn't play 100% nice with other component libraries, due principally to ICEfaces' unique (and very cool) 'Direct-to-DOM' technology. But such issues are outside of Metawidget's jurisdiction

Ok ,so these issues will most likely not arise with Primefaces. Good to know

2. No. Metawidget's 'back end' is controlled by a pluggable 'Inspector' interface which is designed to accomodate this (and many other) architectual preferences. For example see http://kennardconsulting.blogspot.com/2008/06/metawidget-and-namevalue-pairs.html

Great, thanks for the pointer. If you have any other interesting ones…. 😉

[kennardconsulti]

> If you have any other interesting ones….

Sure! I have added a first version of PrimeFaces support into Metawidget (now in SVN) and put together a blog entry and sample application for you to download here: http://blog.kennardconsulting.com/2011/01/metawidget-primefaces-support.html

Please let me know if there is anything further I can do to help with your integration.

Richard.

[kennardconsulti]

Guys,

Just to let you know this work as now been released as part of Metawidget v1.10. I'd be most grateful if you could download it and confirm it works for you.

Regards,

Richard.