[Design the new POJO MicroContainer] - Re: JBKERNEL-12 - Scoped Deployments
by alesj
"marius.bogoevici" wrote :
| So, the beginning question is, what are the current thoughts regarding the Scoped Deployments feature, and if there is a list of outstanding TODOs?
|
There are currently no exact thoughts on the scoped deployment.
Hence this discussion is very welcome.
The current scoped *kernels* are initial prototype of what can be done,
at least a simple hierarchy based lookup and registry is there.
But of course it is missing a lot of proper API, to be really useful.
Although I wouldn't limit the scoping to plain parent-child lookup,
I always had in mind a more peer model, a plane graph - hence GraphController.
"marius.bogoevici" wrote :
| However, there is no generic "deploy in XYZ scope"
|
Not yet, but there should be one, once we properly discuss this.
"marius.bogoevici" wrote :
| operation or "get the Controller corresponding to the XYZ scope",
|
Currently scoping is more an impl detail,
once we have proper API this should be part of GraphController.
"marius.bogoevici" wrote :
| or "get Bean from XYZ scope".
|
You actually have this with @Search (which is deprecated; was initial impl)
and something a member of the community contributed - moving this search notion into inject; see its search attribute.
"marius.bogoevici" wrote :
| As well, every deployment gets some scope associated with it, but I can't see this being used in any practical fashion.
|
Not yet, but I think this is the right way to go, and we'll simply re-use this.
"marius.bogoevici" wrote :
| Also, while injection works properly with scoping (i.e. beans will be injected into other beans only if found in the appropriate scope), consuming scoped beans is somehow inconsistent, in that getBean("someBean") called on a Kernel will return the first encountered bean with a given name, defined in the global Kernel controller, or any of its children. If there are multiple beans with the same name defined in the Kernel, in different scopes, an arbitrary bean (first encountered) is chosen and returned.
|
That was one of the reasons I pushed @Search in, to have a consistent / deterministic behavior.
But this is actually a common problem with any hierarchy/graph lookup; see classloading. ;-)
"marius.bogoevici" wrote :
| - all MC-registered beans created by a deployment are created in the Scope of the Deployment
|
They should only be put into deployment's scope if this is explicitly defined.
Otherwise it should go into top level / main / global (depending on the structure) scope.
Or we will break or had to hack too many things.
To sum things up, I think your understanding of the current code is OK.
I see we also agree on the need for proper API, on Deployers and Kernel side.
My guess is we should just play a bit with this, prototype around existing working stuff,
and see what would be the best way to extend this into some useful feature set.
e.g. add new scoping info metadata into current pojo, mbean metadata
* proper elements in KernelDeployment/BeanMetaData or ServiceDeployment/ServiceMetaData
* external new descriptors that setup proper scoping
* re-check PolicyMetaData
First impression is that this would't take much work,
adding a few new deployers, and modifying BeanMetaDataDeployer to consider this new info on top of GraphController.
I guess hidding the actual scoping impl under more generic (peer) model would be more work.
And it's really a question if we should do that, as mostly such lookups are expected to be hierarchical.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244543#4244543
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244543
17 years
[Design of JBoss jBPM] - Moment of assignment not tracked
by gleenders
I really think something is missing in jBPM 4. At the moment there are only two timestamps logged for tasks: creation and execution (start_ and end_).
I have a BPM case where most of the time the candidate groups are filled in by an AssignmentHandler and in a second phase an individual users can take a task (according to his candidate groups).
What I miss is a timestamp for the moment a task is assigned (taken by) to an individual user.
Since BPM is all about optimizing your process I miss some valuable information here. It is currently impossible to retrieve enough information on the tasks duration. If for example a task is created and assigned to a candidate group but the users waits two weeks to take the task, the bottleneck is not the creation or execution of the task but the process of taking the task.
So I would suggest to extend:
-Data model:
JBPM4_HIST_TASK and add a new Column: ASSIGNMENT_ of type TImeStamp.
-API Class
HistoryService with a new method java.util.Map<java.lang.String,java.lang.Long> avgAssignmentPerTask (java.lang.String processDefinitionId)
Regards,
Gert
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244516#4244516
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244516
17 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Provide GUI-friendly management operations
by jmesnil
related to https://jira.jboss.org/jira/browse/JBMESSAGING-1605.
Currently, it is not possible to use a GUI management console (e.g. jconsole or AS 5 jmx-console) to create JMS connection factories.
All createConnectionFactory() methods required complex parameters of type Object[], String[], Map<String, Object> but the gui consoles can not know how to transform the text input field into these types (e.g. AS 5 console will complain that there is no PropertyEditor for Map)
To make it possible to create JMS connection factory from a management console, we need to pass a String instead of these complex data structures and recreate them on the server side.
e.g. a method which requires a String[] will have a corresponding method where a String is expected. This String will expect comma-separated values and, on the server side, we will recreate the String[] from the comma-separated String.
Similarly, when a Map<String, Object> is expected, we will add an equivalent method with a String expecting a comma-separated list of key=value.
In fact, the encoding we will use is JSON. The management console will send a String to the server. On the server, we will use a JSON decoder to recreate the complex data structures.
It is not completely user-friendly as the management user will need to know the expected format of the String (CSV, or comma-separated key=value) but we will help him by providing MBeanInfo and good documentation on the expected format.
Only the JMSServerControl.createConnectionFactory() methods are affected as they are the only management methods which uses these complex parameters.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244307#4244307
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244307
17 years