Deepal, > So let's provide user flexibility of deploying a pojo as a jar file or > class file , if the file is jar then as you suggested in option1 we scan > though the jar and find the annotated files and make them a services.
If we provide the ability to deploy a pojo that isn't a jar, isn't that what option 2 is? I could be missing something here. We don't have to do it for 1.2, but this is something that would be just as useful for JAX-WS endpoints as it is for Axis2 endpoints. Using this in conjunction with a hot deployment capability would make service development more developer friendly, as I'm guessing it does today for Axis2 endpoints. Regards, Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 Deepal Jayasinghe <[EMAIL PROTECTED]> 02/19/2007 12:12 AM Please respond to [email protected] To [email protected] cc Subject Re: [Axis2] Deployment options for JSR 181 artifacts Hi Dims; I have slightly different idea in mind , after we introduce Deployer concept I am thinking of writing a new Deployer for this scenario. Since with the new deployer mechanism user have flexibility of selecting the directory (he might select pojo or bean directory). And user can deploy his service either as .jar file or .class (or .jws) file. I am not happy with option2 since he can easily create a jar and drop that. So let's provide user flexibility of deploying a pojo as a jar file or class file , if the file is jar then as you suggested in option1 we scan though the jar and find the annotated files and make them a services. Thanks Deepal Davanum Srinivas wrote: > Folks, > > Picking back up from the old thread [1]. We already support specifying > JAXWSMessageReceiver in a services.xml and the ServiceClass pointing > to a class that has annotations. > > Here are some additional options, we need to pick one or more of these: > > Option #1: User drops jar into services directory. One or more of the > classes in the jar have a @Webservice Annotation. (Like the multiple > services in our services.xml). We could just pick up the Main-Class > attribute in the manifest like sanjiva mentioned instead of scanning > the whole jar. If that is absent then scan the whole jar. > > Option #2: User creates a directory under services and drops the > class(es) under the directory. This is equivalent to creating a > services.xml under a directory like we have now. > > repo/services/MyService/org/apache/sample/MyService.class > > {Question here is, do we need the additional MyService directory layer) > > Option #3: Variant of Option #1. But look under beans directory > (instead of services) > > Option #4: Variant of Option #3. But look under beans directory > (instead of services). In this case the single class deployment looks > like this > > repo/beans/org/apache/sample/MyService.class > > Note: For both #1 and #2, we have to update the processing for > services.list to pick up the jars/classes for unpacked war deployment. > Since we can't traverse the directories in unpacked war. Right now we > specify the name of the aar(s) in services.list. > > Did i miss anything? Please chime in quickly since we need to wrap > this up to get something working for 1.2's experimental support. > > thanks, > dims > > [1] http://marc.theaimsgroup.com/?t=116371698300001&r=1&w=2 -- Thanks, Deepal ................................................................ "The highest tower is built one brick at a time" --------------------------------------------------------------------- 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]
