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]> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
