Hi Scott,
Thanks very much for your feedback. It was much appreciated.
Regards,
Nick
Scott S. McCoy wrote:
This is fine,
In the past I've used a similar mechanism. This sounds like a
simple contract-first build process. The missing piece, or so it
seems, is that the generated code should probably be generated as a
part of the build process in order to simplify development. This
would prevent your generated source files from requiring revision
control, since the WSDL is the actual source of that source code.
This is a means in which to prevent modification of the code generated
by Axis; which is preferable for this type of development. To do
anything else would be a bad practice.
When using WSDL2Java, (given the appropriate options in axis2, and
iirc by default in axis 1.4 and earlier) a service deployment
descriptor is generated along side your generated java sources. This
deployment descriptor (wsdd) is then included in your web application
archive (war file). This eliminates the need to keep the quite
possibly dangerous configuration services that dynamic deployment
includes. These services, used in some of the axis examples, should
/never/ be present in a production environment.
Additionally, jetty is surely more efficient and over all more
robust than axis's included bare-bones http implementation. Also,
jetty is better suited for other things, as it's a suitable stand
alone http server and servlet container.
Anyway, to me this set up sounds normal. You might want to double
check that the code is generated from your wsdl as a part of your
build process. To do anything else would be risky, at least.
On Nov 15, 2007 4:55 PM, Nicholas Hogg <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi,
I would really appreciate some feedback on how a project I am working
has been set up - I suspect badly. I have recently taken over the
project and can make major changes if necessary.
- We currently run a Jetty6 web server standalone.
- We build our axis2 based webservice using maven2, building with a
compile time dependency of the axis2-adb artifact. This dependency is
required for two reasons:
1. To compile adb generated service code.
2. For deployment in Jetty (see below).
- We deploy by packaging the webapp as a WAR file, complete with
axis2-adb classes, and drop that WAR file into Jetty's webapps
directory.
- The webapps WEB-INF/web.xml has:
<servlet>
<display-name>Apache-Axis Servlet</display-name>
<servlet-name>AxisServlet</servlet-name>
<servlet-class>org.apache.axis2.transport.http.AxisServlet</servlet-class>
</servlet>
And it maps requests to the AxisServlet with:
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>/services/*</url-pattern>
</servlet-mapping>
- So request comes in, Jetty receives it, passes it off to the
AxisServlet, which passes it off to our implementing service class.
This is quite different to information in the Axis2 Installation
Guide,
where the options seem to be:
1. Install Axis2 as a standalone server and deploy webapps to it.
2. Install the Axis2 web application to a servlet container, and
deploy
webapps to it.
My questions are:
- 1. Is there a good reason why I should the way we deploy our
webapps
in Jetty? ie are there things in axis2 we are missing out on
because of
the way we deploy?
- 2. There was talk on the developers mail list about a year ago
about
using Jetty as Axis2's default container, due to load problems
using the
existing simple HTTP server. Did this happen?
My gut feeling is that Jetty is a best container for us to be
using. If
there were a way for axis2 to use Jetty then we could run axis2
standalone.
Any comments are greatly appreciated.
Regards,
Nick
--
Nicholas Hogg
KE Software (Australia)
www.kesoftware.com <http://www.kesoftware.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
