October 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: How to start jbossesb?

by mark.little＠jboss.com

Please take user queries to the User Forum. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979618#3979618 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979618

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by mark.little＠jboss.com

Just a thought, and not for the up coming release. We could assume that EPRs are created (the term used by the WS-A TC is "minted") on demand. In some cases this is the case and each user gets a unique EPR for the same service. In which case, the EPR is never published in the registry. Rather, the URI of the minter is placed there and the client then sends a "create EPR" request to that URI. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979617#3979617 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979617

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by tom.baeyens＠jboss.com

i think i initially created a separate forms.xml to avoid that the task definition gets an extra column in the database. but now i don't think this is important. so we probably will go to moving the task form reference to the task in the processdefinition.xml. this will impact the designer so we will have to carefully coordinate such a change. koen, how hard would this be for you (the update and verifying if/how this could break compatibility) ? xhtml files in the webapp i think is already possible but i'm not sure. David, do you know that ? i think it could be possible to support both xhtml and jsp files. the taskForm field of the task could become something like this: The webapp could look at the extension and based on that redirect to a separate jsp or include the xhtml into a template form page as is done now. let me know where this doesn't make sense cause i had to write this fast because koen is waiting for me to get a sandwish :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979615#3979615 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979615

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: MessageService and JMS

by tom.baeyens＠jboss.com

1) the configuration updates. maybe, you should start with working out a fixed configuration file. then i could later make it generic. the picture is not yet clear to me so if you just do it straightforward (with duplication), that gives you the ability to move fast. And still i got the freedom later to bind it into the overall build process. The picture on how to customize jbpm.cfg.xml's is not yet clear to me now. Probably it will be something like you mentioned, but i'm not sure yet. 2) There is an MDB called command listener (cmdlistener) that reads commands from a queue and passes them to the SLSB called command service (cmdservice) for execution. let me know if this helps you further View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979613#3979613 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979613

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by kukeltje

I addition I would like the mapping of a task to a form to also be able to map to a jsp/xhtml file *not* in the processarchive, but in e.g. a war (I mean to the absolute url of a jsp/xhtml file which is in a war) Taking the webcontextroot of the war/ear file where the task was called from would be even better, but much more difficult I assume) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979612#3979612 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979612

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by kukeltje

regarding the one file/pageflow (wizard) I have the following opinion: - If it is a one to one mapping of a taskform to a task, I would embed it in the processdefinition.xml - If we want to introduce some kind of wizard functionality, I would do it in a file identical to the pageflow of seam. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979611#3979611 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979611

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Server-side Thread-per-connection Model

by timfox

is it possible to just swap it out? Surely the semantics of blocking and non blocking would imply a different API? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979596#3979596 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979596

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Multiplexed (Bidirectional) Transport

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | From an API perspective, client to server invocations (synchronous and asynchronous) and server to client callback (synchronous and asynchronous) is all we need. Remoting is very close to that, and I will soon publish a wiki document with suggested API amendments. But this is not the problem. The problem is that we don't need to mess around with virtual sockets to get bi-directionality. A TCP connection is inherently bi-directional. You write stuff at this end and it comes out at the other end. You write stuff at the other end and it comes out at this end. Remoting should take advantage of that in the simplest way possible. Write a different transport for that, call it "bidirectional" or "nebuchadnezzar", doesn't matter, and Messaging will use it. | +1. A bidirectional transport core abstraction is what I have been suggesting from the beginning. It just make more sense, and prevent us having to jump though fiery hoops (callback servers, virtual sockets) to get a simple(ish) job done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979595#3979595 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979595

19 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Building on Suse 9.3

by diondodgen

Hi, I am having no luck building on suse9.3 using cr4 or rc3. I have gcc and g++ installed, I run /compile.sh with no errors but a libjbossInspector.so does not get generated. I need help here please or a step by step guide to get it going, the Readme.txt is not helping. Thanks Dion View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979594#3979594 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979594

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Server-side Thread-per-connection Model

by ovidiu.feodorov＠jboss.com

The only thing on the short term, is that we have a working blocking implementation, and if we get the API right, we can replace it with NIO later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979593#3979593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979593

19 years, 5 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 October 2006