February 2007 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: Why is the UMDM using ConcurrentHashMap?

by jason.greene＠jboss.com

ConcurrentHashMap usually does not lock on reads with a successful ConcurrentHashMap usually does not lock on reads with a successful result. However, if the entry does not exist, a lock is always held on the corresponding stripe. Along with the extra locking, it also adds more processing and memory overhead. All of this is of course needed to handle multiple concurrent writers (or the possibility of multiple concurrent writers). However, since the UMD is written to only at the start, and only from one thread, no synchronization is needed, even in that single thread. So, since no locking is needed, there is no need for ConcurrentHashMap. It could be argued though that ConcurrentHashMap would improve safety, since improper use of the UMD (a writer happens after eager initialization for example) would be slightly protected. However the problem is that this would only be protecting one of the many internal types within the UMD, so the overall access to it still can not allow for multiple writers, unless of course, it was redesigned to allow for the multiple writer scenario. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014598#4014598 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014598

19 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Why is the UMDM using ConcurrentHashMap?

by heiko.braun＠jboss.com

anonymous wrote : | The design of the UMDM is that writes are confined to single thread on startup, and all access after that point is read-only. | Exactly. That's the reason why i changed it. The ConcurrentHashMap does not entail locking on read operations. I think this is the desired behaviour or did i miss your point? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014575#4014575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014575

19 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Why is the UMDM using ConcurrentHashMap?

by jason.greene＠jboss.com

I noticed a change in trunk that switched from the UMDM from HashMap to ConcurrentHashMap. Why was this change made? The design of the UMDM is that writes are confined to single thread on startup, and all access after that point is read-only. Switching from HashMap to ConcurrentHashMap adds unnecessary locking. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013932#4013932 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013932

19 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Web based generic webservice client

by maeste

Hi all, Alessio Soldano and me have just released as web application(seam) an open source generic client for web services. The idea is to generate on the fly rich html form (structuring data as tree) for soap request and response. The aplication is designed to be used also by non-programmer people (QA tests) It is an alpha quality code, but it seems to work with a lot of webservices deployed on http://jbossws.demo.jboss.com:8080 (for Heiko: we fixed it :) ). We wrote the core more than 2 years ago for an internal project (based on wsdl4j and, now, some jbossws apis). Now we refactored it to beautify the user interface and we are releasing it with LGPL because we think it could be useful for a lot of people. If you want to take a look we have deeper description, screenshots and an onlinedemo on www.javalinuxlabs.org. We have created a user jbwsdev/jbwsdev with already registered some wsdls taken from jbossws.demo.jboss.com with a comment for non-working ones. BTW on www.javalinuxlabs.org we have also an online demo of LMS, another service we developed (Web based Tcp Monitor like tool) and discussed here some weeks ago: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=94980 Have fun View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013623#4013623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013623

19 years, 1 month

1
0
0 / 0

security + whitespace in soap message

by Thomas Diesler

Jason, relates to: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012935#4012935 Amberpoint is having an issue where whitespace + comments are not preserved in jbossws-1.0.0. Their thirdparty security fails because of this. Isn't it true that for security processing a message needs to be normalized? I assume that comments should be preserved in a normalized message, right? If both is true, they might only have an issue with 1.0.0 not preserving comments. cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

19 years, 1 month

2
2
0 / 0

Re: priority is jboss-4.2

by Thomas Diesler

19 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: wsimport API, SPI, command line tool, and ant task

by jason.greene＠jboss.com

My position is unchanged. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013016#4013016 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013016

19 years, 1 month

1
0
0 / 0

priority is jboss-4.2

by Thomas Diesler

Hi Jason, relates to: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012965#4012965 the current company priority is jboss-4.2. Please help getting the 1.2.0 release out of the door. The sooner we can do that the earlier we can (all) focus on the CTS again. cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

19 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: wsimport API, SPI, command line tool, and ant task

by thomas.diesler＠jboss.com

Yes, this functionality should be included in 1.2.0 for many reasons. The actual naming of the tools seems to be the only remaining issue and should of course not hold back this important feature. Lets clarify and step back a little. When consuming a thirdparty web service using jbossws (i.e. a web service client) one would start with the abstract contract as input | wsdl -> [wsimport] | +- SEI | +- Service | +- JAXB artifacts | +- [wrappers] | +- [impl template] | [wrappers] - are generated on demand (i.e. with doc/lit wrapped, for exceptions) [impl template] - a template for the endpoint implementation could be generated When providing a webservice using jbossws one would start with the implementation bean or possibly with an SEI | Impl -> [wsgen] | [SEI] +- [wrappers] | +- [wsdl] | [wrappers] - are generated on demand (i.e. with doc/lit wrapped, for exceptions) [wsdl] - could be generated if asked to do so For branding reasons and clarity sake we cannot name the jbossws tools the same as the RI tools. After some whiteboard sessions, we came up with the following suggestions [wsgen]: javatowsdl, wsserver, wscontract, wsendpoint, wsexport [wsimport]: wsdltojava, wsclient Our favorite choice is underlined. I would like to reach a conclusion on this today, so we can actually bring the feature in and write about is here http://tddell.dyndns.org/mediawiki/index.php/JAX-WS_User_Guide#JBossWS_Tools View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012965#4012965 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012965

19 years, 1 month

1
0
0 / 0

CTS text nodes

by Thomas Diesler

Alejandro, relates to: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012935#4012935 If you have conflicts between the CTS and your findings in the spec, we should challenge the CTS. You can send your challenge request to me and I talk to "Lance J. Andersen" <Lance.Andersen(a)Sun.COM> until we reach a conclusion. If you prefer, you can of course talk to him directly, he is usually very helpful. Please keep the JavaEE-TCK <javaeetck(a)jboss.org> list in the loop. Generally, we don't have to implement any additional validation that goes beyond what the CTS is testing for. If it is a detail in the spec that the CTS does not test, we also don't need to worry about it (just yet). We should however not implement incorrect functionality just to pass the CTS. On debatable issues, the CTS has been proven wrong many times so far. cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

19 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

jbossws-dev February 2007