July 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: clustered grouping issue

by gaohoward

If you don't want to wait, how about letting node 2 continue to forward messages to node1 and let node1 to find where the messages are to be redistributed? I'm not sure I understand all the tricky problems here though. Howard View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244548#4244548 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244548

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Should Touching / changing timestamp of exploded folder

by jaikiran

The earlier versions indirectly supported this kind of the redeployments where you could rename the directory to something like .bak and name it back to the original name. This would trigger a undeployment and then a deployment. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244547#4244547 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244547

16 years, 8 months

1
0
0 / 0

[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

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Installing a context leads to resolve of other unrelated

by alesj

Even when you have explicit dependencies, it's far from trivial to determine what are one's dependencies, as the info can come from almost anywhere, component name, type just being two of the few, probably the most trivial one's to match against. And this is actually the real beauty of having such dependency abstraction, the component mixture simply falls out-of-the-box. But this again means you need to check all of them. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244541#4244541 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244541

16 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: clustered grouping issue

by ataylor

thoughts on this anyone? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244518#4244518 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244518

16 years, 8 months

1
0
0 / 0

[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

16 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Creating my own jms connection factories

by ron.sigal＠jboss.com

Hi Subhash, You should post this question on the "JBoss Messaging" forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=238. -Ron View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244454#4244454 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244454

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Parallel deployments

by smarlow＠redhat.com

Kabir, I understand that you are still working on parallel deployment but wanted to ask a few questions. Are you still seeing a ten second improvement on your machine? When do you think the parallel deployment support will show up in AS trunk? Thanks, Scott View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244402#4244402 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244402

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Should Touching / changing timestamp of exploded folder

by dimitris＠jboss.org

I guess you didn't do it because we didn't support this before. Conceptually, it makes sense and I think Max asked for this before. How do you 'touch' a directory on windows? :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244323#4244323 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244323

16 years, 8 months

1
0
0 / 0

[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

16 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2009