On Thu, Apr 1, 2010 at 1:44 PM, van Hugten, Stephan <stephan.vanhugten@atosorigin.com> 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"
            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 />

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)?

I went through the jira but did not have time to go through your code. will do at the week end try to put more comments.

First of all how you managed to provide the jsr 181 support? What is the message receiver used in this case?

In your case the difference between deploying sping beans as a .aar file and use your approach is to let users to specify even the configuration details as spring beans. Anyway the simple http server is not something recomended in a production envirionment.

But embeding Axis2 in a spring envirionment is different from this. It let users to expose existing spring beans in a spring container as web services.

In a spring users point of view what is most important is the later case.



Stephan van Hugten

[1] https://issues.apache.org/jira/browse/AXIS2-4662

-----Oorspronkelijk bericht-----
Van: Afkham Azeez [mailto:afkham@gmail.com]
Verzonden: do 1-4-2010 8:52
Aan: java-dev@axis.apache.org
CC: java-user@axis.apache.org
Onderwerp: Re: Axis2-Spring integration

+1 for designing & building this from scratch while bringing in ideas from
these different implmentations.


On Thu, Apr 1, 2010 at 12:31 AM, Andreas Veithen

> On Wed, Mar 31, 2010 at 19:59, Amila Suriarachchi
> <amilasuriarachchi@gmail.com> wrote:
> >
> >
> > On Wed, Mar 31, 2010 at 1:40 PM, Andreas Veithen <
> andreas.veithen@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-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-user-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@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: azeez@wso2.com cell: +94 77 3320919
blog: http://afkham.org
twitter: http://twitter.com/afkham_azeez
: http://lk.linkedin.com/in/afkhamazeez

Lean . Enterprise . Middleware

To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/