Vivek Pandey wrote:
> Marek Potociar wrote:
>> 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.
That's what I call clumsy: having to implement many methods with the
same content.
>>
>> 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.
Yes, my requirement on operation/message name is a single concrete case
that may justify this proposal. The proposal is however not motivated by
this single case.
>> 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.
That does not apply generally.
For instance in WSDLGeneratorExtension, if you have an extension that
extends each WSDL element, the extension implementation does not need to
care about what element it is extending. Also IMHO, having so many
choices (that might even change with new WSDL version) the switch
statement is superior to fine grained API. This applies both for
readibility of the code as well as for its flexibility. In general, you
can add new "event" types without breaking the code.
As for WSDLParserExtension (as it it is stated in javaodc)
implementations should not execute query method on WSDLObject instances.
API should enforce such requirements - passing WSDLExtensible instead of
subtyped WSDLObject would be probably more appropriate. By doing this
you might end up with many differently named methods with the same input
parameters serving basically the same purpose. That is another argument
for the generic API from this proposal.
>> 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.
I am sorry, I joined the WSIt team in february so I probably missed some
discussions. This however does not mean I will keep quiet about obvious
improvement possibilities... :)
I believe that the consensus was based on current SPI and I understand
that this was the only way how to make the life of SPI developer easier.
OTOH it is just another warning sign that the SPI could use some
improvement if one has to resort to such questionable design techniques.
>> 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.
Please, take my apology here for not being clear enough - I didn't mean
to cause such confusion. One thing is the minimum we agreed upon that we
need. That's part of the immediate plan of action.
The other (completely separate) thing is this RFE which tries to take
the SPI changes much further and I didn't want to include it into my
requirements because of current time pressure in JAX-WS team. OTOH I
didn't want to just raise a forum comment because I can tell from my own
experience that forum comments may easily get lost in the space and time :)
While this change does not require your immediate attention, maybe
you/we should consider to deal with it later (the sooner, the better
though). Having good API/SPI would definitely bring longer-term benefit
in reduced time spent on implementing future API/SPI changes and
enhancements. In fact, implementing our current requirements would be
much easier with this new SPI. It would also bring better user (SPI
developer) experience, but that is not on the priority list as I
understand it.
Let me also say that I really appreciate the open discussion that
originated from this RFE.
Thanks.
Marek
--
Marek Potociar
Web Technologies & Standards
Sun Microsystems Czech