It is still at the same place: https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
Andreas On Tue, Apr 20, 2010 at 12:45, Tharindu Mathew <[email protected]> wrote: > Hi Andreas, > > Is your code committed to a new project/sub-project? > > On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi > <[email protected]> wrote: >> >> >> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen >> <[email protected]> wrote: >>> >>> All, >>> >>> I've committed the code that implements the proposed design to [1]. I >>> had to do a slight change to points 3.b. and 4, because construction >>> of an AxisService in general requires an existing AxisConfiguration. >>> To get around this problem, I've introduced a factory interface >>> (AxisServiceFactory) and these points now become: >>> >>> 3.b. It will then scan the Spring application context for beans of >>> type AxisServiceFactory, invoke these factories to create AxisService >>> instances and add those to the AxisConfiguration (at the right moment >>> expected by the Axis2 runtime). >>> 4. The Spring components that are used to deploy services >>> (services.xml like, JSR-181, etc.) are implemented as bean definitions >>> that contribute AxisServiceFactory implementations to the application >>> context (so that they are found in 3.b.). This still makes these >>> components self-contained, because the custom AxisConfigurator only >>> looks up AxisServiceFactory instances from the application context, >>> but doesn't need to have any knowledge about how they are created. >>> >>> You can use WeatherServiceServletRunner to run a sample context in an >>> embedded Jetty instance. >>> >>> Please review and let me know if you think that the code is suitable >>> as a baseline for further development. In particular I would like >>> Sagara as well as the people who worked on WSF/Spring to check if the >>> code is OK as a foundation to build the features that these two >>> frameworks provide. >> >> +1. this looks good. >> >> Does spring runtime guarantees that all the namespace handlers get invoked >> before the FactoryBean afterPropertiesSet() methods get invoked? >> >> I think this design assumes that all the AxisServiceFactory (and other >> possbile future factories) has properly registerd when >> springAxisConfigurator get invoked. >> >> thanks, >> Amila. >> >> >> >>> >>> Andreas >>> >>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/ >>> >>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen >>> <[email protected]> wrote: >>> > After thinking about this a bit more, here is a design that should be >>> > able to take into account the different concerns: >>> > >>> > 1. The ConfigurationContext is stored in the Spring application >>> > context -> makes it easy to get hold of the ConfigurationContext in >>> > the servlet, the standalone ListenerManager and/or clients. >>> > 2. The ConfigurationContext is created by a FactoryBean that relies on >>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes >>> > sure that things are set up in the order expected by the Axis2 runtime >>> > and that the Axis2 runtime has a chance to make the necessary >>> > initializations. >>> > 3. The custom AxisConfigurator is implemented as follows: >>> > 3.a. It will first delegate to an existing one >>> > (FileSystemConfigurator, URLBasedAxisConfigurator or >>> > WarBasedAxisConfigurator, depending on the runtime environment) to >>> > load axis2.xml. Once we have support for all-Spring configuration, >>> > this would become an optional step. >>> > 3.b. It will then scan the Spring application context for beans of >>> > type AxisService and add those to the AxisConfiguration (at the right >>> > moment expected by the Axis2 runtime). >>> > 4. The Spring components that are used to deploy services >>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions >>> > that contribute AxisService instances to the application context (so >>> > that they are found in 3.b.). This still makes these components >>> > self-contained, because the custom AxisConfigurator only looks up >>> > AxisService instances from the application context, but doesn't need >>> > to have any knowledge about how they are created. >>> > >>> > Notes: >>> > - Point 1 does not imply that the Spring configuration will have an >>> > element representing the ConfigurationContext bean. The necessary bean >>> > definition could be added by a bean factory post processor. Also, by >>> > giving a well defined name to the ConfigurationContext bean, there is >>> > no need for explicit references to it in the configuration file; they >>> > would be automatically added by the namespace support. Thus the >>> > existence of the ConfigurationContext as a bean in the application >>> > context would be transparent to the developer. >>> > - Point 3.b. would later be generalized/extended to support modules, >>> > as well as transport declarations and other things appearing in >>> > axis2.xml. >>> > - Stephan's code for automatic deployment of JSR-181 annotated beans >>> > would become inconsistent with the strategy described in points 3.b. >>> > and 4, because it takes already initialized JSR-181 annotated beans, >>> > build AxisService descriptions and adds them to an already initialized >>> > AxisConfiguration. Although this should still work, it is probably >>> > better to make this consistent again by replacing the bean >>> > postprocessor by a bean factory postprocessor that scans the bean >>> > factory for bean definitions that produce JSR-181 annotated beans and >>> > that adds the necessary bean definitions to contribute the AxisService >>> > instances to the application context. >>> > >>> > I will try to translate this design into code to check if it works in >>> > practice. >>> > >>> > Andreas >>> > >>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi >>> > <[email protected]> wrote: >>> >> >>> >> >>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen >>> >> <[email protected]> >>> >> wrote: >>> >>> >>> >>> On Tue, Apr 6, 2010 at 18:56, 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. >>> >>> >>> >>> There are indeed three different approaches: >>> >>> >>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of >>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely >>> >>> cause the issues I described. >>> >>> * Let Spring manage AxisConfiguration, but create the >>> >>> ConfigurationContext outside of Spring (in the servlet and by the >>> >>> component that creates the ListenerManager in the standalone >>> >>> scenario). >>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext. >>> >>> This is what I've chosen in my PoC. >>> >>> >>> >>> Since using the servlet and using ListenerManager are mutually >>> >>> exclusive, you are right that as long as the ListenerManager is the >>> >>> only component that requires a ConfigurationContext, the second >>> >>> approach works well. Since the components that deploy services only >>> >>> need access to the AxisConfiguration, but not the >>> >>> ConfigurationContext, we indeed need to check what exactly is >>> >>> required >>> >>> to create a client proxy. >>> >> >>> >> Any message sending requires a configuration context. But I think even >>> >> for >>> >> that case it is possible to >>> >> register configuration context pragmatically after initialisation and >>> >> use it >>> >> at the message sending time. >>> >> >>> >> Axis2 specifies axis configuration details in axis2.xml and it creates >>> >> the >>> >> configuration context after creating the AxisConfiguration. When >>> >> creating >>> >> the configuration it initialise all the services and modules. There is >>> >> no >>> >> point in changing that if there are no problems could not solve in >>> >> this >>> >> method. >>> >> >>> >>> >>> >>> > 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. >>> >>> >>> >>> Personally, I'm unsure about the right answer to this question. I >>> >>> think someone argued that creating this as a separate project would >>> >>> allow us to have more frequent releases. However, one can also argue >>> >>> that instead of spending our energy in managing the releases of >>> >>> different projects, we should spend that energy to do more frequent >>> >>> releases of the Axis2 core project. Of course we would have to >>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)... >>> >> >>> >> I think you have missed what Saranga has pointed out. It is not only >>> >> about >>> >> having frequent releases. >>> >> Axis2 spring will supposed to have a spring based axis2 configuration >>> >> and a >>> >> service deployment. So it is worth >>> >> to have it as a different project. >>> >> >>> >> thanks, >>> >> Amila. >>> >> >>> >>> >>> >>> > 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? >>> >>> >>> >>> There are several advantages of using namespace handlers even for >>> >>> beans that are fairly simple: >>> >>> * More flexibility to change the implementation, since backward >>> >>> compatibility only needs to be handled at the namespace handler >>> >>> level. >>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get >>> >>> autocompletion for free. Also, with the appropriate >>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse >>> >>> editor will show the documentation for each tag. >>> >>> >>> >>> > 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/ >>> >>> > >>> >>> >>> >>> --------------------------------------------------------------------- >>> >>> 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] >>> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ > > > > -- > Regards, > > Tharindu > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
