RE: Shared schemas: where to put them?
Hi Mauro! Just want to add my 2 cents (even though it's off-topic), perhaps it helps you. We are using (My)Eclipse, keep the sources in CVS, and do not put generated artefacts into CVS. It's like Sietse's approach. Concerning magnitude, we have 5 Web services with ~5 operations per service. When we set up a new development environment, a checkout is done and an ANT script is run - that's all the Webapplication is ready for development AND deployment (the ant script generates needed aretfacts directly in the WEB-INF folder). Development is done using hot code replacement on a local Tomcat Server (Eclipse compiles classes to /WEB-INF/classes, no reload/restart is necessary changes are in effect immediately). Artefacts don't have to be generated for each code change during development. For a production release, the ANT script generates a clean WAR file from scratch (this includes artefact generation and re-compilation of sources). So, artefact generation takes place only when setting up the environment, for making production releases, and of course when source WSDL and/or XSD documents change. The overhead added to the development process is neglibible, also (but not only) because WSDL s and XSDs tend to change infrequently. However, resources needed for developing the necessary ANT build script were definitly significant. Cheers, Peter. <[EMAIL PROTECTED]> schrieb am 20.11.2007 12:37:40: > Hi Mauro, > > I am not working in a big dev environment. But that doesn't make a > difference. Common schemas or parts of it isn't a problem. > > I also have the webservice structure in SCM (svn in this case). Having > the generated code in there is the wrong usage of it in my opinion. This > causes duplication. What I do is: > - Check out the sources (using eclipse or another program/IDE who can > perform svn client operations); > - Let the IDE generate the sources (I use maven for this, but ant can > also be used); > - Now you have a working environment on your local machine (which should > be independent of IDE/OS etc); > - Go ahead and makes changes / improvements to your code. (I like the > test driven approach, but learning that atm); > - Try running them locally; > - If it works local, check out the newest version from the SCM (to adapt > with changes from other developers); > - If you got it working and the tests pass after this you check the > changes in to the SCM. > > I hope this helps you. I think the important bit is to NOT duplicate > sources in the SCM (which you do imho with storing the generated > sources). > > Regards, > Sietse > > -Original Message- > From: Mauro Molinari [mailto:[EMAIL PROTECTED] > Sent: 20 November 2007 11:25 > To: axis-user@ws.apache.org > Subject: Re: Shared schemas: where to put them? > > [EMAIL PROTECTED] ha scritto: > > Hi all, > > > > In my opinion Peter sketched out a nice solution. Why do you care of > > having multiple copies of the xsd while they're generated? Generated > > code shouldn't be in version management, only the sources. And because > > > of his solution makes use of only one xsd you're not duplicating > > anything. The only source is the original (shared) xsd file. > > Hi Sietse, > I don't know which is your development environment, however here we have > a very huge web application for which we are going to write many web > services. These web services can have some data in common (think of > exceptions/faults, for instance) and this is why we need a shared > common.xsd. > We use environments like Eclipse and Netbeans to develop. Having the > webservice structure ready after a CVS checkout enables us to let the > IDE auomatically do the deployment and hit a couple of clicks to make > the webapp start inside our development environment, in order to test > and/or debug. > Adding a custom deployment phase like the replication of this XSD into > all services META-INF folders breaks this automation. Although there are > ways of partially solve this, it simply adds overhead to a process that > isn't working because of what seems to me just a minor flaw of Axis2. > > Moreover, maybe I'm missing something, but I can hardly realize how you > could implement your webservices without putting the generated code (at > least the Java code) under version control... How do you fill your > skeleton with the implementation? How do you use type classes generated > from the WSDL if they are not available at development time? > > -- > Mauro Molinari > Software Developer > [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail
Re: Shared schemas: where to put them?
Hi! I had similar requirements and decided to rely on code generation by WSDL2JAVA. WSDL2JAVA takes the unique shared XSD from a source directory and copies it for each service. That is, I have a directory wsdlDefinitions that contains service1.wsdl, service2.wsdl, and common.xsd. Then I run WSDL2JAVA to generate server code with the -R option, and .../MyService1/META-INF/service1.wsdl .../MyService1/META-INF/common.xsd .../MyService2/META-INF/service2.wsdl .../MyService2/META-INF/common.xsd are generated. I have no troubles with the replication of common.xsd because I only change wsdlDefinitions/common.xsd. Generated artefacts won't be touched anyway. I know that my approach above may not be appropriate in your situation. If so, perhaps You can try setting the useOriginalWSDL parameter in the service.xml to true. Frankly, I don't know the effects of doing this. Good luck, Peter. Mauro Molinari <[EMAIL PROTECTED]> schrieb am 20.11.2007 10:53:47: > Hello! > I have a problem if I want to share some schema files between services. > > Suppose I have the following structure: > > The WSDLs for MyService1 and MyService2 are in the following folders, > respectively: > contextpath/WEB-INF/services/MyService1/META-INF/ > contextpath/WEB-INF/services/MyService2/META-INF/ > > I want them to share Common.xsd: where should I put it? > If I put it here: > contextpath/WEB-INF/services/ > and the xsd:import schemaLocation in the WSDLs points to > "../../Common.xsd", Axis2 can find them and processes the services > correctly, but when it substitutes the link to it in the WSDLs, it > generates the following links: > > MyService1?xsd=../../Common.xsd (in MyService1 WSDL) > MyService2?xsd=../../Common.xsd (in MyService2 WSDL) > > The problem is that from an HTTP client point of view, this translates > to path contextpath/Common.xsd: in fact, if you try to write the link: > > http://server:8080/contextpath/services/MyService1?xsd=../../Common.xsd > a "file not found" error is given. > Another clue is that if I try to generate a client pointing to > http://server:8080/contextpath/services/MyService1?wsdl, Java2WSDL says > that it cannot retrieve the schema. > > By manually typing: > http://server:8080/contextpath/services/MyService1?xsd=../Common.xsd > I see that the schema can actually be found; but if I replace the > xsd:import in the original WSDL so that the schemaLocation points to > "../Common.xsd", then Axis2 can't find it anymore, because it searches > for it in contextpath/WEB-INF/services/MyService1/ and the generation of > the WSDL fails. > > How to face this problem? Where should I put the shared schemas? How to > reference them from within the original WSDLs? > > Thanks in advance. > > -- > Mauro Molinari > Software Developer > [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOAP XML from HttpRequest
You could use the Axis2 MessageContext to retrieve an AXIOM representation of the SOAPEnvelope. For example, something like "org.apache.axiom.soap.SOAPEnvelope se = org.apache.axis2.context.MessageContext.getCurrentMessageContext ().getEnvelope();" may get you started. Regards, Peter. Lahoria <[EMAIL PROTECTED]> schrieb am 19.11.2007 22:07:18: > > Hi There > I am kinda new to SOAP and may be its very basic question but I am having > hard time to find the answer: > how to extract/retrieve SOAP XML from am incoming HttpRequest. I want to > intercept the incoming SOAP call and do some processing. From the > HttpRequest header I know there is a SOAP call as the SOAPAction is set and > the content type of rquest are "text/xml". > Any help/pointers would be really appreciated. > Regards > -- > View this message in context: http://www.nabble.com/SOAP-XML-from- > HttpRequest-tf4839475.html#a13845400 > Sent from the Axis - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Get HTTP ContentType
Hi! If you want to retrieve the Content-Type HTTP header of the current call, you could do: MessageContext context = MessageContext.getCurrentMessageContext(); HttpServletRequest req = (HttpServletRequest) context.getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST); String contentType = req.getHeader(HTTPConstants.HEADER_CONTENT_TYPE)); Bye, Peter. juliocest <[EMAIL PROTECTED]> schrieb am 15.11.2007 13:54:24: > > Hi! > > I would like to read the content of HTTP header, in my service provider with > encapsulate some XML. I am trying to do: > >String httpconstant = HTTPConstants.HTTP_CONTENT_TYPE; > > But I just receive: > >Content-Type > > Thanks. > > Júlio > -- > View this message in context: http://www.nabble.com/Get-HTTP- > ContentType-tf4811689.html#a13767057 > Sent from the Axis - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 1.3 configuring client authentication
Take a look at http://wso2.org/library/161. You can access the "options" object mentioned in the article using "my SoapClientStub._getServiceClient().getOptions()" Best Regards, Peter. "Jon Wilmoth" <[EMAIL PROTECTED]> schrieb am 09.10.2007 08:57:02: > I've gone through the user guide and the http transport guide, but I > haven't found how I can configure an Axis2 web service client (generated > from WSDL) to pass authentication info to the http client. Any pointers > would be greatly appreciated. > > Thanks, > Jon > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
