Lahiru, Dims,

  Just to follow-up with some more info on this (I'll add this to the JIRA
as well). I've been able to successfully test some of the already existing
tests in jaxws (i.e. AddNumbersService, AddNumbersHandlerService, etc) using
our custom deployer.

- Fixed a problem with  EndpointDescription.createAxisServiceName where the
AxisService name was being generated incorrectly

- Add a 'serviceName' attribute to each WebService annotation in the test
samples so that the invocation will find the service that is specified by
service name in the wsdl

- New class in jaxws/framework called JAXWSDeployer
      - This is similar to the POJODeployer but I'm phasing out use of
annogen and all functionality that fills 
         in the AxisService (i.e. Utils.fillAxisService)

- Modified jaxws/test-resources axis2.xml to use our own deployer
'JAXWSDeployer'

- Change jaxws/server/EndpointController.getEndpointDescription to throw
exception if it can't find the     Endpoint

- Change jaxws/pom.xml to copy files to 'wars' directory instead of
'services'. 

- TODO: Change JAXWSDeployer to not call 'createServiceDescription' if its
not the impl. class
        This would be caught anyway, but no reason to try processing something 
that
we know will fail...ALSO, make sure that we don't add it to the
AxisServiceList

- TODO: Process expanded .wars

- TODO: Enhance JAXWSDeployer to handle .wars, expanded .wars, 

- TODO: Update pom.xml to place files as .wars/.jars so that we don't have
to use 'buildWars'


Roy Wood wrote:
> 
> Hi Lahiru, 
> 
> Yes, we are considering doing this as well. The POJODeployer is a simple
> somewhat "clean" way of deploying simple web services as .classes or
> .jars. Trying to add functionality for deploying .wars (or expanded .wars)
> would convolute its initial intent. So, our first thoughts are to build a
> new deployer (JAXWSDeployer or WebAppDeployer) that deploys .wars (or
> possible expanded .wars). It would be similar to POJODeployer but would
> also address the following problems:
>  
>      - Ability to process @WebServiceProvider annotations
>      
>      - Utilize the new 'wsgen' capabilities that Dims just added
>      
>      - Ability to possibly handle a custom deployment descriptor..still
> under discussion as this may 
>         not be necessary
> 
>      - Other problems with annotation processing/validation that we
> haven't discovered yet
> 
> 
> 
> Lahiru Sandakith Gallege wrote:
>> 
>> Hi Dims,
>> I am thinking of not extending the pojo deployer on this regard. Since
>> the
>> forward set of deployable service artifact of the sun TCK are in the form
>> of
>> war files and seems we are not allowed it to change them as we want. We
>> have
>> to get our deployment mechanism to get them sorted out. How about using
>> our
>> axis2 webapp and then have an extension to the deployment from plugable
>> component as TCK suit and made the sun specific wars deployable and we
>> can
>> have the services up on Axis2. Actually we can make this deployment
>> extension as JAXWS Deployer in JAXWS module. This was my idea rather than
>> going for the POJO Deployer on this. Thoughts ?
>> 
>> Thanks
>> Lahiru Sandakith
>> 
>> On Feb 5, 2008 4:16 AM, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Deepal, Sandakith,
>>>
>>> Right now we pick up just a few of the annotations from a java class.
>>> Namely the ones in
>>> org.apache.axis2.description.java2wsdlAnnotationConstants. I believe we
>>> need to take into account *all* possible
>>> annotations in the spec to pass the TCK.
>>>
>>> ~    String WEB_SERVICE = "javax.jws.WebService";
>>> ~    String WEB_METHOD = "javax.jws.WebMethod";
>>> ~    String WEB_PARAM = "javax.jws.WebParam";
>>> ~    String WEB_RESULT = "javax.jws.WebResult";
>>> ~    String TARGETNAMESPACE = "targetNamespace";
>>> ~    String NAME = "name";
>>> ~    String SERVICE_NAME = "serviceName";
>>> ~    String EXCLUDE = "exclude";
>>> ~    String ACTION = "action";
>>> ~    String WSDL_LOCATION = "wsdlLocation";
>>> ~    String OPERATION_NAME ="operationName";
>>>
>>> One option that was taken by the Geronimo team was to use the JAXWS RI's
>>> wsgen tool programatically. We should probably
>>> start looking at the same as well.
>>>
>>> We need to figure out how to support user specified WSDL's as well in
>>> the
>>> PojoDeployer..Thoughts?
>>>
>>> thanks,
>>> dims
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.5 (Cygwin)
>>>
>>> iD8DBQFHp5XYgNg6eWEDv1kRAu9yAKCnNI0KoFMIEIv2Re4BupJEvYIVKwCgnfS8
>>> j1O6XscwHo5eDOauyZvJIJQ=
>>> =/MI4
>>> -----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
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-Axis2--Generating-WSDL-for-JAXWS-artifacts-tp15279562p15365436.html
Sent from the Axis - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to