On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan <[email protected]> wrote: > I agree with this approach, but want to add that I already added some code > for component-scanning to [1] so it's doesn't hurt to add it to the start.
That is a very valuable contribution, but let's first start with the most basic stuff. > If I understand your last point correctly, I don't think this is much of an > implication. In my vision we should make convention leading anyway and in a > Spring-managed environment it shouldn't matter in which order things are > configured. Order configuration should be part of an element as attribute for > instance like servlet filters. With the traditional Axis2 configuration mechanisms, the order in which things are set up is as follows: items from axis2.xml (transports, message receivers, etc.), modules, services and finally the ListenerManager. I don't think that the Axis2 runtime would appreciate if that order is reversed... So order is important, but the developer should not have to care about it. > One questions remains for me; how are non-committers able to contribute? Can > we send sample code somewhere? I think we should soon put together some initial code. We can then start to work with patches. > Stephan van Hugten > > [1] https://issues.apache.org/jira/browse/AXIS2-4662 > > -----Oorspronkelijk bericht----- > Van: Andreas Veithen [mailto:[email protected]] > Verzonden: do 1-4-2010 23:16 > Aan: [email protected] > Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181 > > Devs, > > In order to get the Axis2-Spring thing started without getting lost in > endless discussions, I propose a very simple thing as a starter: > implement a servlet that deploys a JSR-181 annotated bean from a > Spring application context. For simplicity let's take the Axis2 > configuration from a classic axis2.xml file and also don't consider > component scanning yet. Note that the code that does the second part > (JSR-181 annotated Spring bean to Axis service) only takes a couple of > lines and actually already exists [1]. For the first part > (implementing the servlet that manages the Spring application context > and the Axis2 configuration context), there is actually an interesting > design question that I would like to discuss. Indeed, the three > existing codebases use two different approaches to manage the > AxisConfiguration/ConfigurationContext, and we need to select the > better one: > > In WSF/Spring and Axis2M, the servlet looks for beans of a certain > type in the application context. In the case of WSF/Spring [2] this is > a single SpringAxisConfiguration and a single WebServices instance. In > the case of Axis2M [3] these are the ServiceBean and ModuleBean > instances present in the context. Note that all these classes are > framework specific. In both frameworks, the servlet then builds the > AxisConfiguration and ConfigurationContext instances by translating > the framework specific beans into Axis2 objects (using patterns > similar to the traditional axis2.xml, services.xml and/or module.xml > processing). > > In my PoC I've used a different approach (Note that it doesn't have a > servlet yet; only the standalone case is covered): the > ConfigurationContext is itself a Spring managed bean. Obviously, since > ConfigurationContext is not a simple JavaBean, this requires a > BeanFactory [4]. The servlet would then only have to look up the > ConfigurationContext which is already completely initialized by > Spring. > > There are several advantages I see in this second approach: > > * It is more in line with the general paradigms used in Spring. > * The standalone (i.e. non servlet) case is easily covered: since the > ConfigurationContext is part of the application context, it is only > necessary to instantiate a ListenerManager (the lifecycle of which is > also managed by Spring via a FactoryBean that gets the > ConfigurationContext injected): see [5]. > * This will also make support for the client side easier, since we > need a ConfigurationContext as well to create the stub or the JAX-WS > dynamic proxy. > * It would make the implementation of the servlet very easy: just > extend AxisServlet and look up the ConfigurationContext from the > Spring application context. > * Last but not least, it also implies that the components that deploy > the services (or modules if we want to support that) are completely > self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this > class is only known by the bean definition parser and (indirectly) the > namespace handler. On the other hand, the servlet itself doesn't need > to know anything about it. This fact makes the framework much easier > to extend: if somebody comes up with new ways to deploy things, there > is no need to change the core; it is sufficient to add a FactoryBean > and the corresponding namespace handling stuff. > > The only potential issue I see is that compared to WSF/Spring and > Axis2M, this approach provides less control (at least out of the box) > about the order in which things are added to the > AxisConfiguration/ConfigurationContext, but I'm not sure yet about the > possible implications of this. > > Andreas > > [1] > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java > [2] > https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java > [3] > https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java > [4] > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java > [5] > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java > [6] > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
