Hi everyone, It's been sometime and it seems like this thread is dying. I'd like to contribute to this effort with a few patches. Doesn't the initial code need to be committed to the project for us to continue?
2010/4/25 van Hugten, Stephan <[email protected]> > Hello all, > > Some time has passed and I'm wondering if we're also going to set a target > date or dates for some milestones on this subprojects. I really want to > contribute to this, but I am a bit new to all of this and don't know where > to continue from here. If shown some direction I could focus my effort on > that and make something pretty. > > Regards, > > Stephan van Hugten > > -----Original Message----- > From: Andreas Veithen [mailto:[email protected]] > Sent: maandag 12 april 2010 12:48 > To: [email protected] > Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + > JSR-181 > > On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <[email protected]> wrote: > > Hi Andreas, > > I've made some comments inline. > > > > On Sun, Apr 11, 2010 at 5:36 PM, 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. > > > > +1 for this approach. Going according to your notes, this point seems > > +to > > conform with making axis2 more Spring oriented. Until we can get the > > whole configuration into Spring, defaulting to an existing option > > seems to be the best option. > > > >> > >> 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 thought Stephen's idea was interesting. Any reason as to why you are > > going back on this idea? I'm still a bit unsure about what exactly the > > requirement is for this section to choose which approach is better. > > Stephan's idea is interesting and I want to have this feature. What I'm > saying is that we should make sure that explicit deployment (pojoService > element in the current code) and automatic deployment (as per Stephan's > suggestion) should work in the same way behind the scenes, so that we can > avoid subtle differences. > > >> > >> 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/ja > >> >> > va/amila/axis2-spring > >> >> >> > >> >> >> Andreas > >> >> >> > >> >> >> [1] > >> >> >> > >> >> >> > >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j > >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a > >> >> >> xis2/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/SpringAxi > >> >> >> s2Servlet.java > >> >> >> [4] > >> >> >> > >> >> >> > >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j > >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a > >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java > >> >> >> [5] > >> >> >> > >> >> >> > >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j > >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a > >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java > >> >> >> [6] > >> >> >> > >> >> >> > >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j > >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a > >> >> >> xis2/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] > >> > > > > > > > > -- > > Regards, > > > > Tharindu > > > > --------------------------------------------------------------------- > 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] > -- Regards, Tharindu
