Hi Jitu,
Thanks a lot for the response but I like to get few things clarified.
1. For my first requirement,you have mentioned like
"We don't want SEI is to tie with binding specific information.
Note
that the same SEI could be used with multiple bindings like
SOAP1.1/HTTP
and SOAP1.2/HTTP"
But thing is that,as I have mentioned in my code changes,the @BindingType
annotation will be added only when the bindingtype is JMS(which can be
checked in the SOAPExtensionHandler and generated using SEIGenerator),if
is not JMS then it won't be generated and the default would be HTTP.Please
correct me if am wrong/if this will fail in any other scenario.
2.Then for the second requirement,the existing design which generates the
<soap:binding...> is something like in
com.sun.xml.internal.ws.wsdl.writer.WSDLGenerator class
generatebinding(){
//addBindingExtension();
//generate the soap binding element with the tranport as
HTTP
}
So it is like first the extension is called and then the <soap:binding> is
generated,so could you please let me know how can this be generated
through extension.?
If it can be done through extension,then the subsequent part where the
<soap:binding> is generated in the code base should be skipped/ignored,to
skip/ingore this.we need to know if the <soap:binding> is already
generated or not,so could you please let me know how this can be done?
Also if WsGen sees the @BindingType annotation in the SEI,it goes for
validation check,where the validation is done for HTTP,if it is not HTTP
binding,then it throws error,so in the JDK,the validation should tolerate
JMS too.
So it appears to me that,to achieve these things,JDK code base also needs
some changes.(as I have mentioned in my previous mail attachment of the
changes needed)
Once again please correct me if am wrong.
Thanks&Regards
J.JayaKarthik
Jitendra Kotamraju <Jitendra.Kotamraju_at_Sun.COM>
Sent by: Jitendra.Kotamraju_at_Sun.COM
02/22/2008 06:51 AM
Please respond to
dev_at_jax-ws.dev.java.net
To
dev_at_jax-ws.dev.java.net
cc
Steve Poole <SPOOLE_at_uk.ibm.com>
Subject
Re: JAXWS Extensions
Jayakarthik Jayabalan wrote:
>
> Hi,
>
> I am from IBM Java 6 Development team, this is regarding few
> clarifications needed on JAXWS extension mechanisms.
>
> So our requirement is to support JMS binding in the JDK,that is,SOAP
> over JMS.But the current JDK supports only SOAP over HTTP.So our
> initial plan was to try to do this only with extension without any
> base JDK changes but on my investigations,it appears to me that JDK
> also needs some changes as there are few places where the validation
> checks are done for HTTP.
>
> I went through the link https://jms-ws-transport.dev.java.net/ but
> that does not appear to be related to our requirement.
>
> Please find the attached document for the changes proposed for
> supporting this JMS binding,Could you please have a look at it and let
> me know if it is fine/any alternatives available/ if it can be done
> without the JDK changes?Please correct me if am wrong in my
> understanding of this extension mechanism or in my changes.
>
>
>
> Also I have a doubt like in
> *com.sun.tools.internal.ws.api.TJavaGeneratorExtension*,there is only
> a function called *writeMethodAnnotations*() for writing annotations
> over methods but there is no method to write annotations over the
> class,So is it like this cannot be achieved by using Extension
mechanism?
You have two requirements:
1. If in the given input WSDL, if there is a JMS transport value in the
<soap:binding> something like <soap:binding
transport=
http://schemas.xmlsoap.org/soap/jms style="document"> then we
run WsImport on this WSDL,the generated SEI class should have something
like
@BindingType(value="
http://schemas.xmlsoap.org/soap/jmbinding")
* We don't want SEI is to tie with binding specific information. Note
that the same SEI could be used with multiple bindings like SOAP1.1/HTTP
and SOAP1.2/HTTP.
2.Similarly when we run WsGen on the SEI class which has
@BindingType(value="
http://schemas.xmlsoap.org/soap/jmbinding")
then the genearted WSDL should have <soap:binding> like
<soap:binding transport=
http://schemas.xmlsoap.org/soap/jms
style="document">
* Here, once again you do not have to use WsGen. Instead, when the
runtime generates WSDL you could add your
extension(WSDLGeneratorExtension) to generate the desired WSDL.
Using runtime extensions is more tried and tested approach. On the WSDL
side, WSDLGeneratorExtension, WSDLParserExtension can be used.
* Runtime could understand
@BindingType(value="
http://schemas.xmlsoap.org/soap/jmbinding")
by writing your own BindingID extension. See how JSON extension does this:
https://jax-ws-commons.dev.java.net/json/
https://jax-ws-commons.dev.java.net/source/browse/jax-ws-commons/trunk/json/jaxws-json/src/main/java/org/jvnet/jax_ws_commons/json/
JSONBindingID.java, JSONBindingIDFactory.java
* New BindingID is picked using services discovery mechanism. for e.g:
JSON binding is picked by bundling this file
https://jax-ws-commons.dev.java.net/source/browse/jax-ws-commons/trunk/json/jaxws-json/src/main/resources/META-INF/services/
* Since this is SOAP, you could use default SOAP codec and that can be
got from "Codecs" class
* Next is plug-in transports for JMS on client and
server(
https://jms-ws-transport.dev.java.net/ or
https://jax-ws-commons.dev.java.net/smtp/)
* wsimport -extension should work if the WSDL contains JMS bindings
* While generating the WSDL at runtime, I am hoping
WSDLGeneratorExtension should work for you.
If you require any extensions to be enhanced(esp at runtime), we can
plan for them.
Jitu
>
>
> Thanks&Regards
> J.JayaKarthik
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net