On Tue, Apr 6, 2010 at 10:53 PM, Sagara Gunathunga < [email protected]> wrote:
> > > On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi < > [email protected]> wrote: > >> >> >> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen < >> [email protected]> wrote: >> >>> 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. >>> >> >> I had some time to go through your sample code. I agree with you that >> appropriately usage of FactoryBeans and >> Namespace handlers is a better approach. >> >> But I think binding Configuration context to spring runtime and mange it >> using configuration files is not a good idea. >> >> First of all axis2.xml file is used to load the description hierarchical >> things rather than context. And configuration >> context is created after creating the axisConfiguration. If you see the >> ConfigurationContextFactory.createConfigurationContext it does some >> initialisations of modules and transports which should be there at that >> time. And also this would confuse users goes from normal axis2 to spring >> axis2. >> >> >>> >>> There are several advantages I see in this second approach: >>> >>> * It is more in line with the general paradigms used in Spring. >>> >> I think this is reated to usage of Factory beans and namespace handlers >> rather than whether the AxisConfiguration or ConfigurationContext to be >> used. >> >> * 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]. >>> >> please see here[1] where I have done a poc with using axisConfiguration. >> It is also just a matter of creating a >> configuration context and starting the listners. >> >> >>> * 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. >>> >> yes. possibly but need to figure out with a working code. >> >> >>> * It would make the implementation of the servlet very easy: just >>> extend AxisServlet and look up the ConfigurationContext from the >>> Spring application context. >>> >> >> If you see the AxisServlet it starts the listener manager in the init >> method. so need to override that method too. Otherwise it is enogh to >> override initConfigContext method. >> >> >>> * 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. >>> >> >> yes. but no relation to whether we use ConfigurationContext or >> AxisConfiguration isn't? >> >>> >>> 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. >>> >> see the createConfigurationContext I think it assumes axisConfiguration is >> finished by the time configuration context is created. And also I think this >> would make debug the application make difficult. >> >> >> And also here are some other things I saw with your code. >> 1. It has developed as an axis2 module. I think we need to decide on this >> at first place since project structure has to change accordingly. I think we >> need to put it as a seperate project. >> > > +1 , I also have mentioned this idea in a different thread. > > > >> 2. Why there is a namespace handler to >> webServiceAnnotationBeanPostProcessor. I just registered the >> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has >> anyside short commings? >> > > Yes , it is possible to define and use those beans as in traditional bean > definition , some people prefer to this traditional style and some other > prefer namespace support . There are some advantages with namespace style > over traditional beans definition such as less number of XML codes , self > descriptive tags and also users doesn't aware with internal class names and > their properties of the framework. When we change the internal > implementation those changes doesn't effect for the users. [1] this post > provide more details . > Thanks Sagara. nice link. thanks, Amila. > > > http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html > > Thanks , > > > >> >> thanks, >> Amila. >> >> >> [1] >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring >> >>> >>> 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] >>> >>> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ >> > > > > -- > Sagara Gunathunga > > Blog - http://ssagara.blogspot.com > Web - http://people.apache.org/~sagara/<http://people.apache.org/%7Esagara/> > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
