+1 for a solution which has convention over configuration. Azeez
On Thu, Apr 1, 2010 at 1:44 PM, van Hugten, Stephan < [email protected]> wrote: > As you can read in issue AXIS2-4662[1] I support the idea of starting from > scratch as this provides the most lean and extensible result. I also vote > for a solution which has convention over configuration, where the end-user > can deploy the basic run-time within 5 lines of XML configuration and add > configuration only to override the defaults. > For instance I would make the SimpleHTTPServer and the > CommonsHTTPTransportSender the default choice for a ConfigurationContext to > minimize the mandatory top-level elements. The basic run-time configuration > would then look like this: > > <beans:beans xmlns:beans="http://www.springframework.org/schema/beans"; > xmlns="http://axis.apache.org/spring-axis2"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd > http://axis.apache.org/spring-axis2 > http://axis.apache.org/schema/spring-axis2.xsd";> > <!-- Configures a run-time at port 6060 with the default > SimpleHTTPServer receiver and CommonsHTTPTransportSender sender --> > <configurationContext port="6060" /> > > <!-- Resolves any @Webservice annotated webservice on the classpath --> > <webserviceAnnotationConfig /> > </beans:beans> > > I started with the creation of a new DefinitionBuilder that would resolve > the basic run-time configuration XML with a different namespace (Something > like http://axis.apache.org/axis2-configuration). > We should also decide what types of webservices this solution should > support. Will this project still support AAR's (including POJO's)? > > Regards, > > Stephan van Hugten > > [1] https://issues.apache.org/jira/browse/AXIS2-4662 > > -----Oorspronkelijk bericht----- > Van: Afkham Azeez [mailto:[email protected]] > Verzonden: do 1-4-2010 8:52 > Aan: [email protected] > CC: [email protected] > Onderwerp: Re: Axis2-Spring integration > > +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 > <[email protected]>wrote: > > > On Wed, Mar 31, 2010 at 19:59, Amila Suriarachchi > > <[email protected]> wrote: > > > > > > > > > On Wed, Mar 31, 2010 at 1:40 PM, Andreas Veithen < > > [email protected]> > > > 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: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > > > > > > > > > > > -- > > > Amila Suriarachchi > > > WSO2 Inc. > > > blog: http://amilachinthaka.blogspot.com/ > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Afkham Azeez > Software Architect & Product Manager, WSO2 WSAS; WSO2, Inc.; > http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > email: [email protected] 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Afkham Azeez Software Architect & Product Manager, WSO2 WSAS; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ email: [email protected] 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
