Marek Potociar wrote:
>
>
> vivekp_at_dev.java.net wrote:
>> https://jax-ws.dev.java.net/issues/show_bug.cgi?id=51
>>
>>
>>
>> ------- Additional comments from vivekp_at_dev.java.net Fri Sep 15
>> 20:35:24 +0000 2006 -------
>> It will be good to know what you're trying to do that the existing
>> methods wont
>> do for you.
> 1. Ease of use: In many cases current extension mechanism makes the
> extending code unnecessarily verbose and less readable. For instance
> if I want to apply same extension to more than one element, I would
> like to do something like this (instead of having to implement
> gazillion methods with the same code...) :
>
> switch (type) {
> case WsldObjectType.SomeTypeA:
> case WsldObjectType.SomeTypeB:
> case WsldObjectType.SomeTypeC:
> doSomething(...);
> break;
> case WsldObjectType.SomeTypeD:
> case WsldObjectType.SomeTypeE:
> doSomethingElse(...);
> break;
> default:
> // do nothing or do some default action...
> }
>
> Also, AFAIK addressing and policy are the first two JAX-WS
> extensibility users (WSIT tooling resinged on attempts to exploit
> JAX-WS extensibility). I can speak for policy only and I have to say
> that the current extension mechanism is little bit clumsy IMHO.
Not sure why you think its clumsy. I think this is pretty much you will
have to do if you have a generic method that gest called for each of the
wsdl element.
>
> 2. Flexibility: Also I believe that the enhancement I propose provides
> more generic and extendible interface. If it turns out that you need
> to provide access to additional information in some methods, you can
> add appropriate getters into the context without compromising existing
> extension implementations.
>
This is good idea. I will be going thru the extension api to see how we
can do it best. This relates to your requirement regarding
operation/message name.
> 3. Readability: The interface with two generic methods is arguably
> much more comprehensible (to the user-developer) than an interface
> with miriad of fine-grained method declarations.
>
Then implementation has to keep looking for the wsdl element that they
are looking for. Which is tedious too.
>> Having said that here is what we aready plan to do:
>>
>> * WSDLGenerationExtension.start(WSDLGenExtnContext) - already
>> implemented in
>> jaxws 2.1.
>>
>> * WSDLGenerationExtension.finish(XMLTypedWriter)
>>
>> * Have a mechanism to give name of the wsdl element, such as message
>> name or
>> operation name.
>>
> Yes, that is what we agreed on as well as it is the minimum of changes
> we currently need.
Ok.
>> We dont plan to change the abstract class to interface or add change it
>> radically unless you find it something that you cant do with the
>> existing ones.
>>
> My motivation for such suggestion is based on the fact that use of
> abstract classes is a questionable design technique in situations
> where abstract classes cannot hold any reasonable business logic
> implementation (in contrast to template method or strategy design
> pattern) thus does not bring any real value and even hinder the free
> use of inheritance mechanism in Java (you can implement many
> interfaces but extend only a single class). Need to use an abstract
> class to provide a NOOP implementation of all the methods in the
> interface because it is expected that user will not want to implement
> them all is a signal that API design does not reflect the use case it
> is trying to address.
We discussed this at length before it was changed to abstract class,
this is to avoid any implementations to avoid implementing an newly
added methods if it doesn't need so. I think we had consensus on it.
>> It will be good to have such discussion on dev_at_jax-ws.dev.java.net
>> before such
>> enhancement requests are filed, this is so that we understand your
>> requirement.
>>
> I do not necessarily share your view of RFE mechanism ussage. I
> believe that issue tracker should be used to track all the
> issues/RFEs/RFFs/... that arise on the project. The discussion should
> come next - as it is happening right now. Otherwise a RFE may be
> easily lost in the discussion forums.
>
Right. Its just fine.
All I was saying that, we discuss and reached to a conclusion on plan of
action to provide you features in WSDLGeneratorExtension, then you file
an RFE which has new requirements which do not match with the ones we
decided . It confused me as it looked like the discussion we had is not
going to serve your purpose.
JAXWS team is totally time crunched and we don't want to revisit any of
the design/feature decision we collectively made unless it doesn't let
you do something that stops you from making progress. In this case I
think all you need is what we decided to provide you. Our first priority
is JAXWS 2.1 features and meeting WSIT requirement.
thanks,
-vivek.
> Thanks.
>
> Marek
>