> > > 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 ? In the meantime we do not loose anything if we register deployer with extension and the directory , so the key become extension + directory. > > 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 ? > > > > > > 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]
