On Sat, Jan 29, 2011 at 9:40 PM, Afkham Azeez <[email protected]> wrote:
> Isuru, > What if our users want to deploy a large number of JAXWS services on AS? > It will get deployed properly and will generate the WSDL for all the services. But in AppServer, user knows that he deployed a JAX-WS service and all those logs are related to his service. But in G-Reg startup, nobody expects to see those JAX-WS logs and those are not relevant to G-Reg. > By deferring the WSDL creation, you are only temporarily postponing the > problem. > Not at all. > The root cause is WSDL generation for JAXWS services taking too long. > No it don't take too long. Please try a JAX-WS sample on AppServer. But this G-Reg JUDDI service has 100s of schemas to be generated. So it takes some time. may be about 5-6 seconds. It comes from the 'wsgen' tool which is used by Axis2 to generate WSDLs. But that deplay is not relevant to G-Reg. > Is this the case for some other Web services frameworks such as CXF too? > I haven't tested this JUDDI servive on CXF. But I know CXF is also using the 'wsgen' tool to generate WSDLs. It also should generate all those 100s of schemas and it will take time. > We should try to fix this problem. > I don't think there's a problem. What I'm trying to tell is, G-Reg is not a natural place to deploy JAX-WS services. But this admin service needs JAX-WS. So we are going to reduce the additional time taken to generate 100s of schemas on G-Reg startup. Thanks, ~Isuru > > 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 > > -- 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
