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

[Design of POJO Server] - Re: Where should unit tests for deployers-spi go?

by alesj

(3) Keep self pity comments out of MC code ;-) | // I seriously have no idea about how the setInput()/setInputs()/addInput() API expect/work | // The more i look into it, the more confused i am. | // For some weird reason, this is expected to be done. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238268#4238268 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238268

16 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Where should unit tests for deployers-spi go?

by alesj

"alesj" wrote : | This needs to be changed / fixed / in the worst case reverted. | I'll go ahead and fix this. Check later if it still suites you. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238265#4238265 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238265

16 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Where should unit tests for deployers-spi go?

by alesj

"jaikiran" wrote : | Yep, it will be backward compatible and will have tests :) . This needs to be changed / fixed / in the worst case reverted. (1) The names are bad * RealDeployerWithInput - how should I know which one to take; vs. AbstractRealDeployerWithInput * ExtendedDeploymentVisitor - extended? .. what does it extend ... Nameable perhaps? (2) Looking at the impl, it's actually usesless to have this ExtendedDeploymentVisitor. This could easily be a contract of the deployer, to have an attachment name + old DeploymentVisitor. As all you do is lookup certain attachment and pass it to visitor. Dunno why this should be part of the visitor, or why new interface is required. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238264#4238264 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238264

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Undeployment in JBosss Deployer

by camunda

Hi! I have a small change I discussed with several people already, including two of our bigger customers: Undeployment of processes with the JBoss Deployer. In the current code base undeploying a process archive (sorry, a "bar" ;-)) means deleting the process definition and all instances from database. This is a bit rude and can cause a lot of trouble, even if it was "just" a user error or whatever. The deleted process instances are gone then. So I will change the logic from deleting to suspending a process definition when the archive is deleted. Then it must be deleted by an administrator explicitly or you can reactivate it if it was by mistake. For me it is important that this goes into GA already. Any objections? Cheers Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238250#4238250 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238250

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by camunda

A short comment from me as well. The wiki page looks already promising. For me, most important would be some easy things: - see the current activity of a process instance (would be sufficient as a column in the table) - See all process instances (not selecting a process definition) By the way: How do I see Child Executions / the Execution Hierarchie? This would be important as well. And and some feedback on the usability: To have the ProcessDefinition/ProcessInstance Tab was a bit confusing for me first. I didn't recognize they have a relationship to each other... Heiko wrote : | Process variable inspection is one of those cases. There is currently no constraint on variables whatsoever. The "hashmap" style of design allows for everything and nothing at the same time. Of course it would be useful have that feature in the console, but without any type descriptions associated with the process it will only work in particular situations and break in others. | I agree with the others, a simple table with the toString representation would be already a big step ahead. With some improvement it may get a generic Tree (e.g. to show lists, maps and object properties easily). This is what we have in a couple of rich clients at some customers already. If you then cann delete, change or add variables/entries (add by specifying the class name), it would be already very sophisticated :-) But this has not a very high priority (even if I had the demand already a couple of times). But I am eager to the see the next evolution of it :-) Heiko wrote : | Currently the console has to cope with a lot of unknowns, which derive from the "everything possible, but nothing mandatory" style of coding that jbpm4 reflects. | Yeah, I think thats the destiny of a generic process engine console ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238246#4238246 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238246

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How about fixing some of the issues with the v1.0 and v1

by mark.little＠jboss.com

We should doc where it's not applicable then (even better would be for those gateway implementations to issue a warning if they see the value set.) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238228#4238228 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238228

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How about fixing some of the issues with the v1.0 and v1

by Kevin.Conner＠jboss.com

Now that we are deferring the http gateway work we will have time to sort this out. As for maxThreads, it is applicable to at least one gateway that I know of so we cannot just remove it from them all. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238209#4238209 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238209

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"mark.little(a)jboss.com" wrote : Can we please have this in 4.7 then? We really need it for SOA-P 5. It is definitely scheduled for SOA 5, which means 4.7 if not 4.6. I haven't moved the issue yet but will now do so. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238206#4238206 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238206

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"tfennelly" wrote : Sorry again, but this all seems a bit confusing to me in the context of the Http Gateway use cases, that I have in my head. Perhaps I'm a total idiot, but I just don't follow this. Am I alone here? Here is the link to the asynchronous continuation stuff. http://www.jboss.org/community/wiki/AsyncContinuation Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238205#4238205 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238205

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"tfennelly" wrote : As I see the use cases around this, we have the following type of interaction (which doesn't look like the interaction you have above): | | | (sync-http-client) --> (http-gateway) --> (Service) | | Sure it does, you just need to add the second service | (sync-http-client) --> (http-gateway) --> (OneWay, routing Service) -> (RequestResponse service) | "tfennelly" wrote : One way or another, the Http Gateway is going to be returning a synchronous response to the sync client. The question is what does the Http Gateway return? Even after your comments on IM, I still don't see why we can use the mep of the service. The gateway can still make a synchronous call to a service defined with an mep of OneWay as, in the example above, it is a subsequent service which is responsible for sending the reply. Your code will, erroneously, assume that it is oneway from the client's perspective when that is not the case. It is the combination of the services which provide the request/response behaviour. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238203#4238203 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238203

16 years, 9 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 June 2009