[Design the new POJO MicroContainer] - Re: Reliance jBPM overview
by alesj
"kekatos" wrote : So, just to make it clear to me, the general idea of the jbpm-reliance project is to prepare the conf,classes,dependencies,annotations etc that will make the jbpm-jpdl runtime run in the jboss microcontainer without using the jboss
| application server, is that right?
|
No. :-)
The main idea that I have is to be able to introduce flow into bean's lifecycle.
Currently you have pre-defined states - ..., described, instantiated, configured, ..., installed.
You can of course add new states - see DeployersImpl - but I want to make it more flexible / extensible and transparent at the same time.
e.g.
a) perhaps squeezing in a fork of states, and later on a join
b) having human interaction to confirm your bean can move fwd
c) add additional behavior when leaving/arriving to state
And jBPM already addresses all these issues.
a) flexible flow definition
b) tasks, actors + transparent persistency
c) actions, execution, ...
Perhaps most of the things can be implemented just as a simple facade on top of jBPM's PVM. I need to investigate this further.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142036#4142036
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142036
18 years
[Design of JCA on JBoss] - Re: JBAS-5278 Errors .
by timfox
Pasting in some relevant comments by Jesper:
"jesper" wrote :
| By popular request I took a look at subject - here follows my analysis.
|
| First of all: Clebert's comment on this issue is correct - it _IS_ a JCA issue !
|
| The following two classes
|
| org.jboss.resource.adapter.jms.JmsManagedConnection
| org.jboss.jms.ConnectionFactoryHelper
|
| assumes that _just_ because the JMS ConnectionFactory bound in JNDI implements the XA interfaces that the functionality is enabled and always used. This is _not_ correct - the JMS spec doesn't say anything about that.
|
| JBossMessaging lets its classes implement both the non-XA and XA interfaces all over the implementation - e.g. JBossConnectionFactory implements ConnectionFactory and XAConnectionFactory.
| Messaging should be a black box from a JCA point of view - it can't assume anything about non-XA and XA use from a user point of view - it needs to keep track of it for each session. JBossMessaging implements precisely this at the session layer.
|
|
| Problem 1) - this needs to be fixed if JBossMessaging is to be a 1st-class citizen of EAP-4.3, AS-5.0 and at a later point EAP-5.0 (!).
| Problem 2) - using JMS in the AS-5.0 (and EAP-4.3) doesn't work correctly now AFAICT. We need to commit/rollback the transactions where they belong.
|
|
| As to 1) - we can extend the current implementation such that it will become a more 'XA capable JCA adaptor' which can be used with AS-4.2, AS-5.0, EAP-4.3 and EAP-5.0 -- this will require some resources. I need to go over all of the 7k LoC implementation and move/remove all assumptions on how the messaging implementation works - and run the TCK of course. Furthermore I properly need to extend the transaction tracking inside the adaptor.
|
| (I don't see this as a long-term solution - e.g. new implementation in AS-5.1 and EAP-5.1 is needed IMHO).
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141995#4141995
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141995
18 years