[Design of POJO Server] - Re: Controlling deployments via a barrier bean
by adrian＠jboss.org
"bstansberry(a)jboss.com" wrote :
| I need to better understand what Scott's driving at with the discussion of DESCRIBE, DESCRIBE_CLUSTERED, DESCRIBE_SINGLETON and how that solves the issue where we "(r)eally we don't want the unelected singleton beans to be exposed as available for installation as runtime components."
I'm saying that's the wrong approach. What's required (for the first iteration) is being
able to activate/deactivate a sub-profile.
That's what your singleton activation policy does (the contract).
The implementation of scanning to determine what's in that profile
is specific to the current profile implementation.
Another possible implementation is to pull that profile from some reference repository
(which may or may not be clustered).
The definition and implementation of the sub-profile is an orthogonal issue to how
and when it gets activated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155618#4155618
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155618
17 years, 10 months
[Design of JBoss jBPM] - Using TaskManagement for non node specific TaskInstances
by camunda
The TaskManagement in jBPM is what you need for a lot of "Task-enabled-applications". So I faced this requirement a couple of times:
- Create AdHoc-TaskInstances in the process, not related to a special TaskNode, but related to a ProcessInstance
- Create AdHoc-TaskInstances not related to any process
By supporting this, you could use a generic tasklist-frontend (Webapplication or whatever) even to capture non jBPM specific tasks. This is a bit like BPEL4People, where you can create Human Tasks via an (WS-)Interface from your whole "SOA". So you need just one generic human task user interface.
Supporting this would release the people from the need to code their own task management beside jBPM, only because they have a few AdHoc-Tasks. Maybe the TaskManagement can be even used without the BPM part of jBPM. And if the integration with for example Outlook or Webportals goes on, this alone has already value for users (so maybe jBPM can be introduced through this backdoor ;-)).
Also I can image that you could connect TaskInstances and process states a bit more flexible, for example I faced the requirement, that you have a bunch of TaskInstances open during the first phase of the process (indicated by a wait state or super state) and the open ones should be canceled as soon as you leave this state. It is already possible today with having Tasks in a forked TaskNode, but this was more weird than it would have been (easier would be to create and cancel them via ActionHandler, but then they are not connected to a TaskNode)...
Just to give the idea, haven't already thought too deep into it...
Cheers
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155609#4155609
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155609
17 years, 10 months
[Design of EJB 3.0] - Instructions for SerializableMethod Unit Tests
by ALRubinger
Jaikiran:
Within the EJB3 Proxy Component is a currently untested class, "org.jboss.ejb3.proxy.lang.SerializableMethod". We need tests to ensure that:
* .equals() returns true if the name, className, returnType, and each of the argumentTypes are equal by value.
* .hashCode() follows the contract of .hashCode(), ie: if two objects are equal by value, they must have the same hashCode
* java.lang.reflect.Method > SerializableMethod > Method roundtrip returns with input equal by value to output given the same ClassLoader
The project itself follows the standard Maven2 layout, and you should be able to follow the template (naming conventions, etc) of the other tests. I'll send the JBoss Eclipse formatting and code templates for you to import.
To Download and Build:
svn co https://svn.jboss.org/repos/jbossas/projects/ejb3/trunk
| cd trunk
| mvn clean install
>From there, you can easily "cd" into the "proxy" component and issue "mvn clean install" to run the tests, see the Maven Surefire Plugin documentation for information on attaching a debugger, running only one test, etc.
Once you've completed, if you attach a patch ("svn diff > filename.patch") to the JIRA below; I'll review and commit it.
http://jira.jboss.com/jira/browse/EJBTHREE-1400
Thanks for your interest; let's use this Thread for any questions so we keep development concerns truly open to the community. :)
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155598#4155598
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155598
17 years, 10 months