> > On Fri, Aug 28, 2009 at 4:28 PM, Deepal jayasinghe <deep...@gmail.com > <mailto:deep...@gmail.com>> wrote: > > I just went though the patch and which has a number of assumptions > which > introduce so many issues. First as I can see it might break the > directory based deployment, the reason is the logic differentiate > sub-directory from a service just considering have services.xml. And > just look at the following code, if the service is an archive file it > assume it does not have a serviceXML which is wrong (I might have also > done such mistake, but I am just pointing out). > > if > (DeploymentFileData.isServiceArchiveFile(file.getName())) { > addFileToDeploy(file, > deploymentEngine.getServiceDeployer(), > - WSInfo.TYPE_SERVICE); > + WSInfo.TYPE_SERVICE); > + noServicesXML = false; > > noServicesXML = false; --> Does't this mean; foundServiceXML = true? Go for it. what I told was variable name is not correct (I just reviewed the patch). If you think if you do not care, then no worries. > > > > At the runtime this make some very wrong assumptions, that is if the > service is not found that it assume it might be hierarchical > service and > find the service from second part of the URL. I believe this break the > REST behavior and normal operation dispatching, for example logic > would > assume operation name as the hierachical service. (I think he has only > test the scenario which supposed to work, not the cases which > introduces > issues). You will understand what I am talking about if you just go > through the patch. > > * Ex : services/echo/echoString --> values[0] = echo, values[1] = > echoString > + * values[2] = echo/echoString > + */ > + String[] values = new String[3]; > > > Yeah, there may be issues in this implementation, but that does not > mean that you simply reject it because you think it is ugly. We can > review the implementation & provide valuable feedback and suggestions > on how this could be properly done, so that it does not break anything > & also see how we can make REST work. Of course I did not reject that based on ugly, what I told was that directly hierarchy does not make any sense. I know we really need service version and there is no question about that. But we have to do that in a correct manner, just introducing "/foo/bar" does not solve the problem correctly. Second, we can have service name to be anything and then handle the version using services.xml and some other means.
Other thing is we already have a JIRA for service versionning and and I remember we have already discussed some stuff there too. At least you guys need to looking to it before creating a new JIRA. It is not good idea to ignore the history and do from the beginning. https://issues.apache.org/jira/browse/AXIS2-1810
