A default axis2Config.xml (with Spring beans) was used in WSF/Spring mimicking the behavior of the axis2.xml. Thus, giving a default config file if the user wanted to run with default options.
Sagara, may I know why you changed this back to the axis2.xml after you forked WSF/Spring? Regards, Tharindu On Thu, Apr 1, 2010 at 12:22 PM, Afkham Azeez <afk...@gmail.com> wrote: > +1 for designing & building this from scratch while bringing in ideas from > these different implmentations. > > Azeez > > > On Thu, Apr 1, 2010 at 12:31 AM, Andreas Veithen < > andreas.veit...@gmail.com> wrote: > >> On Wed, Mar 31, 2010 at 19:59, Amila Suriarachchi >> <amilasuriarach...@gmail.com> wrote: >> > >> > >> > On Wed, Mar 31, 2010 at 1:40 PM, Andreas Veithen < >> andreas.veit...@gmail.com> >> > wrote: >> >> >> >> All, >> >> >> >> Recently there have been some questions and discussions about Spring >> >> support in Axis2 [1] [2] [3] [4]. As mentioned in these references, >> >> WSO2 has developed a framework that provides Axis2-Spring integration >> >> [5]. Also, Sagara Gunathunga has done some very interesting work [6], >> >> but this has not yet been released. In [1] I argue that neither of >> >> these two frameworks provide a definite solution and Sagara actually >> >> agrees with my analysis. >> > >> > I also agree with your analysis :) but let me tell something about it as >> one >> > of the initial designer of wsf/spring. >> > >> > As I learned about the spring (two years ago) it promotes a way to write >> the >> > business logic as POJOs and managed them using spring framework. Spring >> > provides functionalities to let these business methods to access data >> layer >> > and expose them as web applications. But you can test the business logic >> > without being depending on the data layer or web layer as they are >> written >> > as POJOs. >> > >> > The idea of the wsf/spring was to let people expose these POJOs as web >> > services. For this it uses RPCMessage receiver, schema generator and >> some >> > utility methods of axis2-spring. So some of the new features you have >> > mentioned was not considered by that time as well. >> > >> > >> >> >> >> On my side, after writing my review and in >> >> reaction to [3], I wrote some PoC code to explore how some of my wish >> >> list items could be implemented. This code is available at [7]. I >> >> would also like to mention the interesting contributions made by >> >> Stephan van Hugten, who opened [3]. I would really like to see him >> >> continuing to contribute. >> >> >> >> After discussion with Sagara, we decided to join our efforts under the >> >> umbrella of the Axis2 project. >> > >> > Can we do this? According to apache rules I think it has to start an >> > incubator project. I am +1 on starting as axis project :) >> > >> > For me the ideal place is in the spring code base itself. As I remember >> this >> > is where the cxf/xfire spring integrations lies. Since this is a feature >> for >> > spring users it would give a better visibility to axis2 as well. >> >> The intention is indeed to make this a module of Axis2, so that an >> up-to-date version is part of every upcoming Axis2 release. >> >> > >> >> >> >> Probably what you will see happening in >> >> the next days is that Sagara will bring the existing Axis2M Spring >> >> code into a sandbox area in Axis2 [8] and that we will start a >> >> discussion about how to best merge our two codebases (which for the >> >> moment address different parts of the problem) into a single one. >> > >> > Although wsf/spring has short commings that you have pointed out, it >> > describes a better possible way of integrating Axis2 into a spring >> container >> > (I think this could be the reason for forking Axis2M from wsf/spring as >> > mentioned in the your blog). And also it supports ws security as well. >> > Therefore it would be easy to start from the wsf/spring and gradually >> > improve it to suite for new requirement would be an easy approach. >> > >> > So would like to propose to start with wsf/spring. Further Axis2M has >> forked >> > from wsf/spring and it has go bak to use axis2.xml as well. >> >> If everybody proposes his own code as a starting point, we will get >> nowhere. I think we should start from scratch, and then as we progress >> through the different areas we want to cover, take over those >> components from the three codebases that fit well into the >> architecture, discarding those that need to be redesigned. Anyway I >> think that both WSF/Spring and Axis2M share an architectural flaw that >> will make it difficult to support the standalone (non servlet) case >> and Spring at the client side. I will provide an analysis of this >> issue later. >> >> We should also establish a list of the requirements and goals that we >> want to achieve, so that everybody has the same vision of where we go. >> Probably a Wiki is a good place to write this down. I think, a new >> Wiki for the Axis project has been created recently. >> >> >> I think that everybody agrees that it will be beneficial for Axis2 to >> >> provide a good Spring integration out of the box. Of course, this is >> >> also the right moment to look for involvement of others in the >> >> community (developers and end users). I you want to help shaping the >> >> solution, please participate in discussions, provide scenarios that >> >> you would like to see supported, make suggestions, contribute code or >> >> simply test the code. >> > >> > From the given features list I really like the idea of servlet + jaxws + >> > spring. As I mentioned earlier wsf/spring uses RPC message receiver. But >> > this has some issues with performance and support lists maps etc. So if >> we >> > can solve these issues with jaxws message receiver or a new message >> receiver >> > based on jaxb while supporing jaxws it would be a really advantage of >> the >> > user point of view. IMHO for a normal user the performance and the >> > complexity level of the POJOs that we can support is also very >> important. >> >> I think that once the infrastructure is correctly in place, supporting >> JAX-WS doesn't require any new stuff, just plumbing code. Everything >> is already in place in the existing JAX-WS deployer. But it is >> probably too early to start discussing this question. >> >> > thanks, >> > Amila. >> >> >> >> Andreas >> >> >> >> [1] >> >> >> http://veithen.blogspot.com/2010/03/some-thoughts-about-axis2-spring.html >> >> [2] http://ssagara.blogspot.com/2010/03/roadmap-for-axis2m.html >> >> [3] https://issues.apache.org/jira/browse/AXIS2-4662 >> >> [4] http://markmail.org/thread/n2gpvabeh6ncdcxw >> >> [5] http://wso2.org/projects/wsf/spring >> >> [6] http://axis2m.sourceforge.net/axis2m-spring.html >> >> [7] >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/ >> >> [8] Note that Sagara was part of the bunch of committers we recently >> >> voted into the new Axis TLP. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org >> >> For additional commands, e-mail: java-user-h...@axis.apache.org >> >> >> > >> > >> > >> > -- >> > Amila Suriarachchi >> > WSO2 Inc. >> > blog: http://amilachinthaka.blogspot.com/ >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> For additional commands, e-mail: java-dev-h...@axis.apache.org >> >> > > > -- > Afkham Azeez > Software Architect & Product Manager, WSO2 WSAS; WSO2, Inc.; > http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > email: az...@wso2.com cell: +94 77 3320919 > > blog: http://afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware >
