September 2009 - jboss-dev-forums

[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor

by barteljan

Hey everybody, at first sorry for my absence in the last week which was the result of unexpected project pressure in the last 4 days, but since this is managed, I hope to spend my next 3 days into the extension of the GPD .... As the things are now, I managed to check out the 4 projects in the jboss-svn at the last weekend and get a better view about eclipse-plugin-developement. With this new knowledge in mind I would agree to Koen that having a plugin-based way to extend the gpd with customized nodes would be great, and would also agree with Ronald that having a way to extend it without plugins would also be great. So why shouldn't we implement both way's ? Since we have to refactor the classes which are responsible for registering the nodes and showing them into the editor-palette it should be easy to do both, requesting spezified extension points, which will satisfy the situation where you don't want some additional classes in your "design-project", and interspecting project classes for annotated customized node classes for situations where you want unit testing and a more "eclipse independent" developement. I will have a closer look at the both classes koen specified in the next hours and at tommorrow morning so that I hope that I can join in the discussion in a better way at saturday. Which takes me to the next point should I create a wiki-page for our "delineation" or will we discuss that at the GPD 292 ? Again sorry for being silent for the last week, Cheers, Jan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255782#4255782 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255782

17 years

1
0
0 / 0

[JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation

by mmusgrov

anonymous wrote : So if there is an impossibility it doesn't come from sharing the transactional context between threads but from asynchronicity. What do you think? This is true in the case of the X/Open Distributed Transaction Processing specifications. The problem with a client starting a transaction and then making an asynchronous call to a remote server is that the client may call commit whilst the server is still trying to do transactional work. To cater for this scenario X/Open disallows transaction propagation on asynchronous requests. This is in contrast to synchronous or conversational requests in which case context propagation is allowed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255781#4255781 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255781

17 years

1
0
0 / 0

[JBoss ESB Development] - Strategies for packaging related services?

by arcticranger

I am using the basic 3-layer classification of my ESB services, basic, composed and process. Right now I need to deploy 10 or so basic services implementing atomic file system operations. I'd like some feedback on packaging strategies. It would make sense to me to put all of my read/write/delete/copy/etc operations for one domain in one .esb archive. The O'Reilly SOA Cookbook was very much against this and gave versioning, redeployment and coupling as reasons to avoid it. I just don't want thousands of .esb files floating around, even with a solid naming scheme. Also, how can my physical deployment accurately capture my classification scheme? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255770#4255770 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255770

17 years

1
0
0 / 0

[JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation

by chtimi2

Questions about the JBTS implementation of this functionnality Q'1: Is there documentation about this topic, or examples specific to JBossTS? I couldn't find a lot in the project documentation (the JTS Programmer Guide). Q'2: Can i continue to use my Spring declarative transactions, with JBTS embedded as the JTA transaction manager? Q'3: In relation to the previous post, do async services need to be one-way to be able to participate in a multi-threaded transaction? Q'4: Would this work with JBossPOJOCache as the transactional resource? (i'm not using a database) Q'5: Any gotchas and things that aren't possible that you can think of? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255769#4255769 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255769

17 years

1
0
0 / 0

[JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation

by chtimi2

Questions and comments about the article I quote excerpts of the article, and add my questions or comments in italic. The comments might well be wrong, by all means feel free to tell me so. anonymous wrote : 1. Introduction anonymous wrote : Although protocols exist for enforcing thread and transaction synchronisation in local and distributed environments (commonly referred to as checked transactions [1]), they assume that communication between threads is synchronous (e.g., via remote procedure call). A thread making a synchronous call will block until the call returns, signifying that any threads created have terminated. | For example, the Object Transaction Service (OTS), specified as one of the Common Object Request Broker Architecture (CORBA) Services [2] by the Object Management Group, specifies a checked transactions protocol based upon the X/Open model. Q1: Doesn't this mean that OTS in intrinsically synchronous? But then isn't this synchronicity contagious up to JTS/JTA? On the other hand other readings seem to indicate that the JTA/JTS specifications don't forbid or mandate support for the scoping of a transaction context to several threads. The question is then, is JBTS support of this functionnality accessible through standard JTA interfaces? For my personal case, would it work with declarative transactions in Spring? anonymous wrote : 2. A processing model This looks compatible with what we would need. anonymous wrote : 3. Checked behaviour Checked means that when the initiating transaction has committed, the commit includes the actions of the "sub-threads". Transactions within a single thread are always checked, multithreaded transactions require additional controls to be: completion callbacks go up the thread creation hierarchy up to the root thread, the one that initiated the transaction. Only then is the transaction committed, even though control has already been given back to the client of the root transaction. Q3: Can the client have some sort of Future or does the operation have to be one-way? Can he be notified of the transaction outcome? anonymous wrote : and the transaction 'end' may not proceed until the thread created for the invocation upon object a returns a 'synch'. This is coherent with the notion of a checked transaction. anonymous wrote : The thread created by the invocation upon object a cannot terminate until the thread it created for the invocation upon object b returns a 'synch'; Q4: But this seems stranger. Doesn't it mean that the invocation of b by a is synchronous? anonymous wrote : 4. The application domain anonymous wrote : Asynchronous invocation is implemented as a CORBA 'one-way' call. Q5: Does this mean checked async transactions lony work with void one-way calls, and that the client can't get a Future? anonymous wrote : 5. Using the CORBA Object Transaction Service anonymous wrote : Instead our proposed implementation dynamically turns asynchronous invocations into deferred synchronous, | if and only if, the invocation is occurring within a transaction. | This modification to the invocation mechanism occurs at runtime, and is completely transparent to the programmer. Again, what does this mean for the caller of the root service that initiates the transaction? Doesn't deferred synchronous mean you get a blocking Future reference (or something else, but that holds a return value)? Isn't that contradictory with the other times when they say the async methods need to be one-way? I'm confused. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255768#4255768 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255768

17 years

1
0
0 / 0

[JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation

by chtimi2

Hello Mark, I have read the paper you cited. It does a good job at presenting the problem and a possible solution, and from what i understand JBossTS seems to use this solution. If other people are reading this, the article can be found for free at: http://www.cs.ncl.ac.uk/publications/inproceedings/papers/598.pdf If you don't mind i have a few questions, first about the article (to be sure i got it right) and then about the JBossTS implementation. For the sake of clarity i will post these questions in two separate posts. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255767#4255767 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255767

17 years

1
0
0 / 0

[JBoss Identity Development] - secure web service with saml

by jeff.yuchang

"Daniel" wrote : | Jeff Yu and I are currently working on supporting SAML in JBossESB and have created the following thread in the ESB design forum: | http://www.jboss.org/index.html?module=bb&op=viewtopic&t=161206 | | What we currently have is the ability to issue a SAML Assertion for JBossSTS, and insert that Assertion into an existing SOAP Security Header. | The next step is create a web service that is secured and have our SAML Assertion validated by JBossSTS when calling this web service. | | I'm not sure about how to proceed with securing the web service, and configuring support for validating the SAML token with JBossSTS. | Any pointers to docs or classes would be great! | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255715#4255715 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255715

17 years

1
0
0 / 0

[JBoss Portal Development] - maven repository url ?

by schamarthi

hi, is there any place u publish jboss-portal.sar\libs in maven ? If yes, then where and whats the version I should use for JBP 2.7.2? thx Srinivas View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255681#4255681 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255681

17 years

1
0
0 / 0

[EJB 3.0 Development] - Caching anntations from MDR

by wolfc

[urlhttps://jira.jboss.org/jira/browse/EJBTHREE-1914[/url] With EJBTHREE-1914 we introduced a CachingAnnotationRepository which will query MDR only once. This means that changing the meta data runtime doesn't work any more. The changexml test case however changes the bean meta data security domain after deployment and thus the test fails. Do we still want to support the use case of changing meta data at runtime? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255672#4255672 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255672

17 years

1
0
0 / 0

[JBoss Profiler Development] - Profiler JMX domain

by thomas.diesler＠jboss.com

The current domain is org.jboss.profiler all other jboss MBeans use jboss.foo Please consider dropping the "org." prefix from the domain View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255658#4255658 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255658

17 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 September 2009