Isuru, What if our users want to deploy a large number of JAXWS services on AS? By deferring the WSDL creation, you are only temporarily postponing the problem. The root cause is WSDL generation for JAXWS services taking too long. Is this the case for some other Web services frameworks such as CXF too? We should try to fix this problem.
Thanks Azeez On Sat, Jan 29, 2011 at 7:53 AM, Kasun Weranga <[email protected]> wrote: > > > On Sat, Jan 29, 2011 at 5:34 PM, Isuru Suriarachchi <[email protected]>wrote: > >> >> >> On Fri, Jan 28, 2011 at 10:26 PM, Afkham Azeez <[email protected]> wrote: >> >>> >>> >>> On Fri, Jan 28, 2011 at 3:01 AM, Isuru Suriarachchi <[email protected]>wrote: >>> >>>> Hi all, >>>> >>>> I've added the following Axis2 related properties into the Carbon core >>>> axis2.xml which should be filtered at product level. >>>> >>>> 1. <parameter >>>> name="EnableChildFirstClassLoading">${childfirstCL}</parameter> >>>> >>> >>> Shouldn't this default to true? If a user includes the same JARs in his >>> deployment artifact, it essentially means that he wants those JARs to get >>> precedence. Also, you should think about the MT case when adding such params >>> to axis2.xml. >>> >> >> In Axis2 we've set this property to 'false' by default. And also, AFAIK, >> in all other app servers like Tomcat, WebSphere and JBoss, parent first >> class loading is used by default. If the user wants it to be child first, he >> has to change it. Anyway, with the use of OSGi, I agree that most of the >> time it is safe to set this to 'true >> > +1, If this is not true, When same *libraries* exist in deployment > artifact and carbon plugins directory, it gives class loading issues. > >> Specially it is safe in MT case. >> >> >>> >>> >>> >>>> >>>> This is a very important property when deploying complex services which >>>> contains libraries in the lib folder of the service archive. I've added >>>> this >>>> parameter and set the value as a property to be filtered at product level. >>>> Default value for this should be 'false' and if the user wants to use it, >>>> he >>>> has to set it to 'true'. But only for G-Reg, I had to make it 'true' by >>>> default because they are going to ship a JAX-WS service for UDDI >>>> implementation. >>>> >>> >>> Why shouldn't this be set to true for AS? >>> >>> >>>> >>>> 2. <parameter name="useGeneratedWSDLinJAXWS">${jaxwsparam}</parameter> >>>> >>>> >>> Again, you must think about MT here. Also, if there is a service out >>> there, the expectation is people would call ?wsdl. Why cannot we simply have >>> the WSDL geenrated at deployment time and have it ready? Why do we need this >>> additional complexity for JAXWS services? >>> >> >> No, it's not an aditional complexity. This parameter doesn't only mean the >> WSDL generation time. Let me explain. Earlier in Axis2, the wsdl is >> generated from the annotated class only if you call ?wsdl. So it didn't use >> the AxisService object in WSDL generation at all. But in AppServer, you can >> engage policies through the management console and after that when you call >> ?wsdl, the policy should be in the WSDL. Therefore, I added this property >> into Axis2 to generate the WSDL at deployment time and create the >> AxisService object using that WSDL. When you call ?wsdl, it will serialize >> the AxisService object. So all the policies will be there in the WSDL. But >> in Axis2 level, it's not a must to have this property set to true. >> >> So let me explain why I set it to 'false' in G-Reg. G-Reg is not a service >> hosting environment. It uses this JUDDI service as kind of an admin service. >> And the users can't change the behaviour of that service through the G-Reg >> console. In addition to that, this JUDDI jaxws service is a huge service and >> Axis2 generates about 100 separate schema files for it when generating the >> WSDLs (there are about 10 services in the same jar). So if we set the above >> property to 'true' in G-Reg, all these schema's will be generated each time >> the G-Reg starts up. And also 100s of lines printed on the console and it >> takes a considerable amount of time. So that's why I set this value to >> 'false' in G-Reg to avoid the additional unnecessary overhead. It will >> generate the WSDL only if someone calls ?wsdl. >> > +1, Having this property is important for GREG to reduce the startup time > and to avoid printing huge amount of schema retrieving information while > deploying the UDDI services. > >> >> Thanks, >> ~Isuru >> >> >>> >>> >>>> This property specifies whether the WSDL for a JAX-WS service is >>>> generated at deployment time or it is generated only if someone calls >>>> ?wsdl. >>>> Default value for this property in AppServer is 'true'. But for G-Reg I've >>>> set this to 'false' as it is not a must for it's JUDDI servie to generated >>>> WSDL at deployment time. >>>> >>>> Please use proper filter values at product levels. >>>> >>>> Thanks, >>>> ~Isuru >>>> >>>> -- >>>> Isuru Suriarachchi >>>> Technical Lead & Product Manager, WSO2 Application Server >>>> WSO2 Inc. http://wso2.com >>>> email : [email protected] >>>> blog : http://isurues.wordpress.com/ >>>> >>>> lean . enterprise . middleware >>>> >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> [email protected] >>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com >>> , >>> * >>> * >>> *Member; Apache Software Foundation; >>> **http://www.apache.org/*<http://www.apache.org/> >>> * >>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>> * >>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>> * >>> * >>> *Lean . Enterprise . Middleware* >>> >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> Isuru Suriarachchi >> Technical Lead & Product Manager, WSO2 Application Server >> WSO2 Inc. http://wso2.com >> email : [email protected] >> blog : http://isurues.wordpress.com/ >> >> lean . enterprise . middleware >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *Kasun Weranga* > Software Engineer > ** > *WSO2, Inc. > *lean.enterprise.middleware. > mobile : +94 772314602 > <http://sanjeewamalalgoda.blogspot.com/>blog > :<http://sanjeewamalalgoda.blogspot.com/> > http://kasunweranga.blogspot.com/ > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- *Afkham Azeez* Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation; **http://www.apache.org/*<http://www.apache.org/> * email: **[email protected]* <[email protected]>* cell: +94 77 3320919 blog: **http://blog.afkham.org* <http://blog.afkham.org>* twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware*
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
