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

[Design of JBoss Web Services] - Re: Stack independent addressing implementation

by richard.opalka＠jboss.com

We discussed this topic with Alessio and we have the following conclusions: We'll try to discuss this problem with JAX-WS representatives. From our point of view the only correct way of addressing this problem is to update JAX-WS spec so it will include required WS-A abstractions. It already includes some abstractions from WS-Addressing specification i.e. EndpointReference. Thus question is why other abstractions from that spec aren't part of the API? We think they have to be there to don't confuse JAX-WS users and don't make them tend to write proprietary code for each JAX-WS stack they're trying to integrate with. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208911#4208911 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208911

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm 4 module dependencies

by heiko.braun＠jboss.com

IMO enterprise depends on jPDL. Not on PVM. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208905#4208905 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208905

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Stack independent addressing implementation

by adinn

anonymous wrote : | First of all we need to keep in mind basic J2EE principle here Write once run everywhere. Thus proprietary api is always wrong approach from this point of view. | Well, I really want my WSTX implementation to be container-independent and the hope was that JaxWS would provide that independence in the transport layer. However, I have no choice but to use the WSA management API which lies outside the spec -- the WS-* transaction specs requires manipulation of addressing properties. In the absence of any definition from the specs I still need some API to code to and it it would be better if we could provide just one API. If I were to build myself some facade classes to wrap around the CXF and JBoss WSA implementations of the WSA types I think I would still need to deploy stack-specific code at the interface to the stack (i.e. when I create addressing property values and when I install them or test for them on the client/server side of a connection). So, my code will end up being dual-image and deployment of my code will depend upon the WS deployment. Following this route seems doubly inappropriate in that the AddressingProperties classes are already facades. Is it possible to deploy the javax.xml.ws.* interfaces in the CXF WS release but configure them to use the CXF builder classes to populate them? In other words to use the implementation provided by the underlying stack but make it available via the same API as the native WS release. If we do choose an API it would be better if it were located in the javax package (although, strictly, we are not supposed to pollute this namespace with our own definitions). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208897#4208897 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208897

17 years, 1 month

1
0
0 / 0

[Design of JBoss Identity] - typed interface of identity api

by tom.baeyens＠jboss.com

after integrating the identity api in jbpm, i have 2 remarks: 1) typed interfaces are nice in oo design, but i believe they are counterproductive in this api. before i can do a query that involves a user and a group, i have to fetch the identity-object and group-object from the api. only then i can supply those objects into the query method. this means 3 api calls instead of just 1. probably this will lead to 3 times DB access instead of 1. in the jbpm api, we take primitives (id's) as method parameters in our session facade apis. and we provide typed objects as the return value. in case you would have the typed object and need to invoke a method, then you can always supply the id by doing someObject.getId(). 2) i believe there should be no difference between a role and an association. role should be just an optional property of an association. this would make the whole model and the related api managers a lot simpler. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208892#4208892 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208892

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Clean up / Compactor

by timfox

"clebert.suconic(a)jboss.com" wrote : | The idea was to update the file on disk, + change the counters in memory, so case there is a reload, after the linked files were deleted, the data wouldn't be duplicated. Why would you need to update the file on disk? If you update in memory, then the files get deleted, so they won't get reloaded... What am I missing here? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208887#4208887 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208887

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Concurrency in jBPM4

by roschmel

I do not use pessimistic locking because it is necassary to synchronize against the parent parent parent.... process instance because a signal anywhere in the process can cause data changes up in the hierachy. So I would have to make a loadInstanceForUpdate on the parent instance. Using pessimitic locking on the row level causes deadlock situations in the database where orcale throws exceptions then. I decided to do it with a jboss cache so that i can relase the jbpmcontext during the wait for the lock in order not to hold the the database resources during waiting. But the loadInstnaceForUpdate would definitly be an option I think. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208880#4208880 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208880

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - EJB3 enterprise module?

by camunda

Hi guys, what is the current status of an eEJB3 enterprise module (form jbpm 3)? It was discussed quite often already, but nothing is done on this yet, right? Or did I miss any code? For a current project I will develop it anyway, does it make sense to commit it for others? I know a couple of projects which developed their own EJB3 bean and I get the question in trainings quite often. So I think it would make sense for a lot of people, more than the "old" EJB 2.1 stuff... What do you guys think? Could it be put in 3.3. to avoid productization/support effort? Cheers Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208878#4208878 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208878

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Concurrency in jBPM4

by camunda

@roschmel: Okay, now its a bit clearer. Why don't you use hibernate pessimistic locking in this case? And: With async=true, couldn't you get completly rid of the problematic situations if you use it often enough? Alex wrote : An ExecuteJobsCommand is constructed with the exclusive job IDs and sent to the command queue. The command executor then executes the jobs serially. Couldn't this lead to the behavior of a repeating timer creating jobs which cannot be processed as fast as created (assume the system is very utilized)? This is why we normally decided against executing timer stuff over JMS. Or what do you think? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208876#4208876 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208876

17 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: Design of Portal Deployer

by alesj

"mwringe" wrote : | Thats the way the current sar is setup, I can be converted to a -beans.xml in the future. Is there a big reason to switch? | JMX might not be there for 6.x. ;-) Our beans IoC is far superior to our JMX IoC. sar == jar in MC "mwringe" wrote : | Because the deployers are started before the deployables, so I can't inject something from a deployable into a deployer (correct me if I am wrong, but I have tried this) | So I use the MC kernel to get a reference to the objects at runtime which gives me the same result. | It depends how you inject them. ;-) After each phase deploy - boot, deployers, deploy - a MainDeployer::checkComplete is called, to make sure everything is deployed as it should be. But you can make your injections optional, injected via callback. So it will be almost the same as you have now, except that your code will be MC agnostic, hence more flexible. Think POJO. ;-) "mwringe" wrote : | So the common metadata driven approach is the best? | Best is relative term. ;-) But I guess it's good, see our previous 4.x deployers vs. new VDF. "mwringe" wrote : | No, and there are other deployers which need to do similar things (sometimes even worst than the tld deployers). I know its not the best way of doing it, but it works. It something that will need to be looked into more and fixed (if possible). What about if we did this on our own? As it looks like we'll have to wait forever for Remy. :-) Or get ThomasH to ping/push the new JBossAS bosses about this issue, as it's crucial for you guys. I think all we need is a VDF based DirContext + investigate how this affects .tld lookup. There already is a VFS based one, but it's not used due to some legacy Servlet api crap. Perhaps we could make this dynamic, e.g. if we see JBP app use VDFDirContext, else fall back to default. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208870#4208870 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208870

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Stack independent addressing implementation

by richard.opalka＠jboss.com

First of all we need to keep in mind basic J2EE principle here Write once run everywhere. Thus proprietary api is always wrong approach from this point of view. And because of wretched JAX-WS spec the first acceptable solution seems to be setting binding provider request properties and populating these properties to message payload via provided WS-A properties propagation JAX-WS handler. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208841#4208841 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208841

17 years, 1 month

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 February 2009