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.
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.
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.
> 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.
> 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.
> 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.
Thanks.
Marek
--
Marek Potociar
Web Technologies & Standards
Sun Microsystems Czech