[Design of POJO Server] - Re: Java EE inter-module accessibility for Web Beans
by pete.muir＠jboss.org
"alesj" wrote :
| "pete.muir(a)jboss.org" wrote :
| | * using an ejb-jar not deployed inside the app, but deployed at the top level
| |
| You mean we should be able to track external EJBs and add them as accessible BDA?
|
| How does this again play with all listed BDAs and circularity problem?
| e.g. if I list it in one WB app Deployment/BDAs, I them must exclude it in another (its original app) ...
Exactly, this is why Web Beans allows the container to put circularities into the BDA graph. Inside Web Beans we remove the cycles by removing the first BDA to reoccur when we walk a particular path by tracking what BDAs we have already seen in this path. This is why the Javadoc says "Circular dependencies will be detected and ignored by the container" - thats not very clear, it now says "Cycles in the accessible BeanDeploymentArchive graph are allowed. If a cycle is detected by Web Beans, it will be automatically removed by Web Beans. This means any implementor of this interface don't need to worry about circularities."
Note that the graph can only be changed during deployment, at runtime it is static and we can cache the transitive closure of BDAs a BDA can access which means we have low overhead.
Of course, the container may already have a non-circular structure in place, so that could be
anonymous wrote : "pete.muir(a)jboss.org" wrote :
| | * using extensions defined in manifest.mf http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Main%20At... and [url]http://java.sun.com/javase/6/docs/technotes/guides/extensions/spec.html
| |
| This looks like normal manifest lib listing, and is already supported - while building classpath.
| Hence it should already be included in the recent new impl.
Great. We will add some TCK tests soon to verify this deployment structure, so we'll get results then :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246749#4246749
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246749
15 years, 7 months
[Design of JBoss jBPM] - [BPMN2] How to implement uncontrolled sequence flow behaving
by camunda
I try to figure out how the PVM works internally and how to implement this requirement best:
In BPMN if a task (activity) has more than one outgoing flow (transition), than this is an "uncontrolled sequence flow" which leads to parallelizing. So it behaves like a parallel gateway / fork!
So for every task the flow semantic must be: If there is more than one outgoing flow, ALL must be used. This should be done somewhere generic.
I think the ExecutionImpl.proceed() would be a good place, but this is PVM internal, I cannot overwrite that in the language, right?
Or maybe try to leverage the ExecuteActivity as a AtomicOperation?
Or try to do it in a abstract super class of all activities? Which seems to be a bit complicated, but possible (so I have to add the logic from the fork after the execution of the activity).
Any good ideas for that?
Thank god the uncontrolled joining is like it is default in the PVM -> XOR-Join.
Thanks
Bernd
P.S: I commit a failing test case with a uncontrolled sequence flow as Fork and two tasks, if somebody cannot stop himself from coding ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246747#4246747
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246747
15 years, 7 months
[Design of EJB 3.0] - Re: Quartz MDB integration and classloader issues
by ALRubinger
"jaikiran" wrote : I see that most of our current interceptors reside in ejb3-core. I guess the right place for new interceptors in the ejb3-interceptors component?
|
Nope. :)
Interceptors are aspects; they encapsulate logic that runs across the core concerns of other components. So to dump them all in the same project would be counterproductive; we'd eventually build up a tangled mess of dependencies equivalent to the old "aspects" module of the AS.
So each interceptor should get its own component with release cycle. Then they can be plugged in at will.
Also, IMO we overuse interceptors. Oftentimes we leverage them just to break code out into some other space, for instance in the InstanceInterceptors which pick out the target instance a Container should invoke. That's a required concern of the Container. We should be careful to apply interceptors as they're intended; to plug and play behaviours without affecting the overall operation of the core concern. A great example of this is Tx and Security; remove them and you've got no Tx or Security. And interceptors should not depend upon each other.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246746#4246746
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246746
15 years, 7 months