Hi Aki, sorry I hadn't gotten to your dev list message, and my knowledge in this area is incomplete. The fact that the original submitter of this bug wrote "The SOAPFault in CXF will only throw the 'Fault occurred while processing.' message rather than the original NPE message." shows he doesn't understand the Pen-testing 101 rule not to pass service-side exception bug details back to the client. He didn't mention anything about the JAX-WS specification, so that wasn't his motivation.
Why is his motivation important? Right now, he apparently feels that if you have a database space error, somehow the SOAP client should receive a message like "Wizard RDMBS error: Table AdminAccountName.MY_STUFF on server camel07 is full, please expand more space for it." That's a training issue, and once he understands that's a no-no, I suspect he would be likely going to request a return to 'Fault occurred while processing' again, rather than defend the new implementation based on the apparent rule in JAX-WS 10.2.2. Very few people indeed truly want service-side error messages propagated back to the client (incidentally, NPEs are embarrassing for all concerned and developers don't like it when their web service stacks embarrass them to their customers in such a manner.)
Further, "NullPointerException" is a Java-language construct, while SOAP is language-independent. There shouldn't be any need to return Java-language constructs to the client, as that would incorrectly imply the SOAP client base may base logic on the fact that the SOAP service is implemented in Java.
I'm confused a little about your statement: "But I am more concerned about some unknown user extended runtime exception that overwrites its toString to do more than writing its class name." Does this new change facilitate that (they can override toString() now?) or hinder that (now if they tried to overwrite it, the client will still get an "NPE" message)? If the latter, perhaps this change does more good than harm, but if the former, I would say CXF should tighten up and not allow this, to protect systems against sloppier developers putting too much info in their error messages back to the client.
Anyway, CXF has several masters-
the WSDL, JAX-WS, JAX-RS and WS-I Basic Profile (and Basic Security Profile) specs-and as you know, we can't serve more than one perfectly. I believe CXF has already tightened itself up in a few places w.r.t. the WS-I profiles, becoming invalid as a consequence with the more-easygoing WSDL and JAX-WS specs, both of which allow more than what WS-I does. This would appear to be something where going the safer route rather than strict compliance with any specific JAX-WS rule would appear justified. I don't think this change is vetoable but my instinct would be to revert it, because I think its going to happen anyway (someone several months down the road will complain about CXF improperly sending internal error messages to the client) but if you wait several months to revert you may have to deal with backwards compatibility issues of many SOAP clients now incorrectly basing logic based on specific Java class exceptions being returned from the web service provider.