Hi Dims, As I understood in the forward set of testcases of the TCK we have a set of sun war files which we can not make any changes for that other than some parts of the web.xml. We have to get our deployment configured in to deploying this and pass the testcases. On the reverse set of test cases we have set of wsdls that we have to codegenerate the services and pass the test cases by deploying those services.
Thanks Lahiru On Feb 6, 2008 1:34 AM, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeff, > > looks like we need more information from the folks who have the TCK. > specifically some layout hints on where the service > classes are and where the wsdl's and xsd's are. > > ~From what i can tell with the information we have now. We need to be able > to plugin the RI's wsgen to generate wsdl if > it's absent. We need to be able to pick up wsdl/xsd for a specific service > if they are already in the war. and we need > to be able to pick up all the classes with webservice and > webservicesprovider annotations from the war and turn them > into services. > > thanks, > dims > > Jeff Barrett wrote: > | ims, > | > | My understanding of what the TCK permits is the same as yours. You can > | remove the RI-specific DDs and can add your own vendor-specific DDs. > | However, anything that exists in the TCK application archive (such as > | classes, WSDL, etc) must remain as is. So, the classes couldn't be > moved > | from WEB-INF/classes to some POJO-deployer-specific location. Another > | consideration is that a single TCK application archive, I believe, > | contains multiple services AND there may be multiple TCK application > | archive. > | > | Is any of that going to cause problems for the POJO deployer? > | > | I talked with Roy Wood about this a bit, and I got the impression that > | having multiple archives and multiple services may be a problem that > needs > | to be fixed in the POJO deployer. Also, that it would be possible to > | point the POJO deployer at a specific directory or archive, so it could > be > | pointed to an "installed applications" directory and be able to find the > | services there. It seems to me that would work for the TCKs. > | > | Thoughts? > | > | Thanks, > | Jeff > | > | IBM Software Group - WebSphere Web Services Development > | Phone: 512-838-4587 or Tie Line 678-4587 > | Internet e-mail and Sametime ID: [EMAIL PROTECTED] > | > | > | > | Davanum Srinivas <[EMAIL PROTECTED]> > | 02/04/2008 04:45 PM > | Please respond to > | [email protected] > | > | > | To > | [email protected] > | cc > | > | Subject > | [Axis2] Re: PojoDeployer vs JAXWSMessageReceiver in services.xml > | > | > | > | > | > | > | Resending using [Axis2] since looks like no one looks at the emails > | otherwise :) > | > | Davanum Srinivas wrote: > | | One more observation: > | | > | | In PojoDeployer, we can't specify a custom wsdl (yet!) When one writes > a > | | WebServiceProvider, typically they provide a > | | wsdl and the xsd's. > | | > | | -- dims > | | > | | Davanum Srinivas wrote: > | | | Sandakith, Roy, > | | | Looks like PojoDeployer picks up only the javax.jws.WebService > | | | annotation and not the javax.xml.ws.WebServiceProvider > | | | annotation. > | | | > | | | Sandakith, > | | | ~From what i know, we cannot modify WAR's shipped by the TCK. Only > | | | changes allowed are removing sun specific dd's and > | | | adding our own and maybe change the port #'s...This may have an > effect > | | | on which way to lean using PojoDeployer vs > | | | JAXWSMessageReceiver in services.xml as we cannot modify the WAR's > to > | | | suit the pojo deployer. Please note that all the > | | | existing services.xml in the modules\jaxws are handwritten :( > | | | > | | | thanks, > | | | dims > > - --------------------------------------------------------------------- > 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] > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Cygwin) > > iD8DBQFHqME4gNg6eWEDv1kRAisTAJ9VgDn6Iu/WWxQQmAGOf5iWW6posQCgvbVz > NiM/pP0YGE4/+AFCCoyuwnI= > =oDOA > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks Lahiru Sandakith http://sandakith.wordpress.com/ GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
