axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vidyanand Murunikkara" <Vidyan...@infravio.com>
Subject RE: isolation of web services deployed on axis
Date Thu, 31 Oct 2002 23:37:06 GMT
Hi Steve 

We have been doing exactly like this .. but if you are running in
somethign like tomcat it chokes after the 7th app .. this is without
using any of the X options while running tomcat ... is this a problem
with tomcat or is it becoz axis eats too much of the resources ??? is
hosting them in different boxes the only solution then ???

thanx
Vidyanand.

-----Original Message-----
From: Steve Loughran [mailto:steve_l@iseran.com]
Sent: Thursday, October 31, 2002 3:33 PM
To: axis-user@xml.apache.org
Subject: Re: isolation of web services deployed on axis



----- Original Message -----
From: "Peake, Chris" <Chris.Peake@ca.com>
To: <axis-user@xml.apache.org>
Sent: Thursday, October 31, 2002 15:08
Subject: RE: isolation of web services deployed on axis

>Steve Loughran wrote:
>>the trick is to stop having multiple apps in the axis webapp, and move
to
>>one webapp per app, each with the axis libs (and servlets in web.xml)

>Is this what people are doing in a production world?

yes.

>I've been wondering what folks are doing in a complex environment with
multiple web services. (i.e. 20+)

hosting them on different boxes.

>There are also the questions related to where a an applications jar has
to
be.  Currently the \lib dir.  >There's always the possiblity a web
service
application jar could be named the same as another jar.  Yes, >standards
fixes this, but...
>So the separation could prevent this issue.

Separation is fundamental to isolation. It lets you
-hot restart one webapp while another one keeps going
-have different debug options for the different app
-use completely different versions of common libraries.

>But the duplication of axis jars is unpleasant.

no more unpleasant than duplicating xerces.jar,castor.jar, log4j.jar.
Keep
them all under SCM, have a property file driven build process where each
project pulls in the appropriate version, so I can switch from castor
0.9.3
to 0.9.4 just by changing castor.version=0.9.4 and having the build
process
pull in lib\castor-${castor.version}\castor.jar

The important thing is that by keeping all libraries you use under SCM,
you
can always roll back to a working image.

>And the very similar URLs might be confusing to an organization.

what is confusing about

http://serverA/zermatt/services/getSnowConditions?wsdl and
http://serverA/SennenCove/services/getSurfConditions?wsdl

Or do you mean duplication of other URLs, like happyaxis? When you build
your own app, you only need to include the files you need. Thinks like
admin
client requests need to go to the right place, but that is something
else
you automate in your build file. Automation of deployment is almost a
prerequisite of a production process.

>Is there a semblance of a 'production' environment out there that has
lessons learned which could be >shared?

yes, mine.

http://www.iseran.com/Steve/papers/when_web_services_go_bad.html
    why automated deployment matters
http://www.iseran.com/Steve/papers/interop/
    how to test for interop
http://www.manning.com/antbook
    ch15: how to add axis to a webapp. ch17, automating deployment,
ch12,
httpunit testing. happyaxis.jsp originated from chapters 12 and 15, BTW.








Mime
View raw message