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
