On Tue, Nov 4, 2008 at 7:09 PM, Deepal jayasinghe <[EMAIL PROTECTED]> wrote:
> > > > > > In my point of view always deployer should only map to an > extension. > > -1 , if you think the POJO deployer it can handle both .class > > files and > > .jar files , so are you saying thats a problem. If we have the > > flexibility and if we doing that for a long time without any problem, > > then we should continue to keep it as it is. > > > > good point. Lets associate many extensions with a deployer as Sanjiva > > has mentioned. > > Here the main point I want to tell is that deployer has nothing to do > > with a directory. For an example POJODeployer deployes either a .class > > or .jar file. Where is that file is not relevant for that. > I agree. However the problem is we are limiting some stuff , for example > at the moment we can deploy POJO and Transport as .jar archive. But if > you go with this proposal we are limiting some stuff right ? IMO we need to use different extensions for different type of services. transport should have something like http.tar. I think that is why we use .aar for service archives .mar for modules etc. > > In the meantime we do not loose anything if we register deployer with > extension and the directory , so the key become extension + directory. This depends on the people use it. For me what I would like to do is to specify a directory as my root service directory and organize the service files with some directory hierarchy and put the service archives in the directories I need. And for http case it should determine the service path from the directory relative to the root. you may ask why you can't specify all those directories in Axis2.xml and declare the extensions which I want to use with those directories. yes it is possible. but for me this is lot of work. if I change a directory name or add a new directory I need to update the Axis2.xml. And also with this way I am not sure how to figure out the http service path from the directory path since there is no any root directory. The other advantage is that if we think in this way it is easy to extend this for other repositories as URL repositories. thanks, Amila. > > > > As I can see even the repository can be able to configure through > > Axis2.xml as well. > > > > <repository class="<class name>" > > > <parameter name="" value=""/> > > <repository> > > > > This repository can be a file repository, url repository, WSO2 > > registry repository. Then the repository class can read the files on > > the repository and ask deployers to deploy them. > In other world what you are telling is AxisConfigurator , that exactly > what you are proposing. I mean adding new stuff into it. As I mentioned > in one of my previous mail , we have support for URL repo and file based > repo. > > (Since a deployer has only associated with a set of extensions) But > > this may have limitations in the way we read the files from different > > repositories. > you mean now ? No. > > > > > > > > > > > > In the above way it can support both expanded and single file > modes. > > Hehe , seems like you are not happy with the current way , I do not > > know whether you know about the deployment mechanism we had before > the > > deployer concept , and do you know how much of work JAX-WS people > > did to > > deploy their services. > > > > Well now you can understand the problem of not having custom deployers > > at the begining of Axis2. Then custom deployers has introduced as a > > solution for this. So it is an improvement but not an underestimation > > of the existing work. This is what currently happen as well. There > > are requirement even can not be solved by current custom deployers so > > need to improve it. > I understand what you mean, But IMO re-writing is not the solution for > each problem ;-) > > > > thanks, > > Amila. > > > > FYI , at Apachecon US 2007 we had a BOF session > > and their they mentioned what they are doing and the difficulties > > of the > > process , so as solution to that problem I introduced the idea of > > deployer , and whether you agree with me or not , it made the > > deployment > > so flexible and more extensible. And I do not see a any issues > > with that > > other thane the issue that Jarek mentioned. > > > > Thank you! > > Deepal > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > -- > > Amila Suriarachchi > > WSO2 Inc. > > blog: http://amilachinthaka.blogspot.com/ > > > -- > Thank you! > > > http://blogs.deepal.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
