Let us see case by case.
Starting from wsdl: Can a wsimport understand a wsdl which contains JMS
binding. I think it is going to with -extension switch. Otherwise can
you send a sample wsdl ?
Starting from java: I am suggesting not to run wsgen to generate WSDL.
Just do this during the runtime.
Jitu
Jayakarthik Jayabalan wrote:
>
> 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
> *_at_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
>
>