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/
