April 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Web Services] - Re: JBossWS 3.0.1 Release Issues

by richard.opalka＠jboss.com

"yhrn" wrote : Hi, | I was told to re-open JBWS-1714 but I can't. I have posted a comment and attached an example though. | | Cheers, | Mattias I reopened it ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141672#4141672 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141672

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS 3.0.1 Release Issues

by yhrn

Hi, I was told to re-open JBWS-1714 but I can't. I have posted a comment and attached an example though. Cheers, Mattias View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141662#4141662 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141662

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reliance jBPM - flow definition / bean lifecycle

by alesj

"tom.baeyens(a)jboss.com" wrote : | what is the timeframe that you want to achieve this? | The idea is to have this as part of GSoC: - http://labs.jboss.com/auth/wiki/GSoC "tom.baeyens(a)jboss.com" wrote : | Ideally this could wait a couple of months and then it could be build on jPDL 4. That is what I guess would be the easiest way to do it. As I see it, we have all the pieces already there, so no need to wait. But like discussed, we could perhaps leverage PVM for some parts. This needs further investigation, starting a new thread (ps: let's do this after our Wednesday live discussion). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141656#4141656 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141656

18 years

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-5278 Errors .

by clebert.suconic＠jboss.com

A kludge on this would be to create a delegate ConnectionFactory on the JCA Layer that will only implement the required interface, which is like putting a wire replacing the fuse when it breaks. It works now, but it can be worse later. That is a terrible solution, I don't like it.. but I just wanted to give that as an idea (Brain storm). I guess it would be possible to implement the delegate transparently without changing any configuration files (what would have implications on documentation as well). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141652#4141652 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141652

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: COM Gateway

by mark.little＠jboss.com

"lihui_pang" wrote : I am evaludating JBoss ESB too. I have the similar questions, e.g. if the message is non-serializable, do we need to implement MarshalUnmarshalPlugin, or is that existing plugin for us to use?, how to register plugin? -- I can't find any sample on this. Yes, the idea is that you can add a MarshalUnmarshalPlugin for each datatype so you get direct control over how to marshal (or unmarshal) it to (from) the Message. You may want to monitor http://jira.jboss.com/jira/browse/JBESB-1643. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141648#4141648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141648

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: COM Gateway

by mark.little＠jboss.com

Dirk, sorry for the delay in getting back to you, but here are some comments on your document. 1: on page 3 you state "The listener implementation class is not serializeable. This not allows to use the JBoss ESB message type JAVA_SERIALIZED, because we not provide MarshalUnmarshalPlugin only for the message type JBOSS_XML. " I didn't understand that. Why does the serializability (or not) of the listener affect the Message? 2: the use of JAXB makes perfect sense AFAICT from what you want to achieve. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141646#4141646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141646

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reliance jBPM - flow definition / bean lifecycle

by tom.baeyens＠jboss.com

while i don't yet know all the details of the lifecycle (e.g. bean lifecycle vs container life cycle) this looks like a very valid use case to leverage jPDL or PVM. what is the timeframe that you want to achieve this ? Ideally this could wait a couple of months and then it could be build on jPDL 4. That is what I guess would be the easiest way to do it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141645#4141645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141645

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Reliance jBPM - holder thread

by alesj

This thread here is to hold all related Reliance jBPM design discussions. Find an appropriate existing thread, or if none fits your needs, start a new one and attach the link to this one. Here are the first two I would like to discuss futher: 1) Flow definition / lifecycle - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=133085 2) Engine / console - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=133088 When we establish what all we need to do, I'll create matching JIRAs here: - http://jira.jboss.com/jira/browse/JBREL View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141644#4141644 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141644

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Reliance jBPM - engine/console

by alesj

Server / engine 1) central point of registry 1a) exposing client connect API 1b) security 1c) poolling 1d) caching 2) constructed of bunch of MC beans 2a) registry 2b) listeners + event 2c) statistics 2d) search (by flow, by actor, ...) Clients to engine 1) usage 1a) administrator 1b) actual users/actors 1c) remote M2M 2) common abstract client impl 2a) handling engine connect 2b) security - authentification, authorization Few client impl 1) socket / terminal 2) web application (Seam based) 3) webservices/ejb3 + desktop client Bean flow/lifecycle control 1) 1st exclusively beans registered with engine 1a) task confirmation 2) could extend that to on_demand and manual beans 3) handling beans in error, see JBMICRCONT-266 4) all beans View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141642#4141642 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141642

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Reliance jBPM - flow definition / bean lifecycle

by alesj

Defining flow / bean lifecycle 1) jPDL file 2) programmatic 3) from database 4) custom MC xml --> new schema --> jbossxb.builder All 4 would then require new deployer(s), but should be trivial to implement. Flow states We should be able to add additional states - besides the existing ControllerStates. This would then require matching ControllerContextAction(s), to be used when registering new ControllerContext. Transparent way to link bean to use the flow 1) annotation usage, e.g. @Flow("some-flow-name") 2) custom xml The first one looks good enough, specially since we are able to have annotations declared in xml for instance usage or pre Java5. Flow action/nodes integrated with MC IoC 1) cross injection 1a) injection of existing MC beans into action/nodes 1b) action/nodes are plain MC beans used in flow definition 2) extension of existing jPDL schema Dependencies 1) Transition ==> DependencyItem 1) Action ==> DependencyItem View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141635#4141635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141635

18 years

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 April 2008