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]
ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
