I'm so glad you got it going, and so sorry that it was so much trouble.
I guess they changed alot in the newer Axis version as compared with the
Axis version for which that example was created and tested.
I'm sure your tips will be useful for others out there (and useful to me
or whoever at NAC ends up updating that example).
Yes, webapps offer many advantages over "Legacy".
You can configure things once, and if your code is written wisely, you
don't ever have to configure things again.
No more worrying about all the pieces being in the right places, etc....
A formal webapp is quite superior really.
And yes... you can share them between instances (portability).
That is to say that ASI #1 can point to and deploy:
And then ASI #2, #3, ... #n can all point to and deploy that same webapp... all
using the same web.xml configuration settings defined by that
But each ASI will maintain it's own sessions... have it's own JVM.
Thus the app would be running in various ASIs (i.e. various VMs).
They would not "share" their sessions or application scope, or
request scope or anything like that.
If you need them to share sessions, then use the JdbcSessionManager (see the SE
5.0 User Guide).
Most people do not need this.
I'd consider that to be a very advanced setup, and not one that you are
likely to need.
The webapps folder is the "auto-deploy" folder (see the SE 5.0 User
Guide for more info about auto-deployed webapps).
Inside it is a folder for every SE Virtual Server.
By default, an SE installation starts out with just one SE Virtual
Server which is named "default".
So it's ...\webapps\<SE Virtual Server Name>\
Most people have no need to create and use additional SE Virtual Servers
(doing so is an advanced setup)...
they just use the one named "default".
How about making the instance root
C:\ServletExec AS\se-<some instance>\webapps\default\default-app
If you did that, then you'd just be making the default-app behave like a
normal webapp (telling it to use its own root as it's document root).
Which sort of defeats the whole purpose of even using the webapp named
If you wanted that, then you should just use the SE admin UI to remove/undeploy
the default-app and then deploy your own app using a single forward slash
"/" as the context path.
So you could have:
which you would treat as the document root of the "/" context.
The advantages to placing your webapps in a location that is NOT beneath the SE
installation folders is that it is then much easier to uninstall SE and
reinstall a newer version of SE.
Otherwise your data (i.e. your webapps) are at risk of being deleted (unless
you remember to save copies of them prior to uninstalling SE).
In my opinion it is always best to separate data, from what you do with that
data or the useage of that data (when possible).
Putting your apps under \webapps\default\ has the drawback that you must then
cycle SE for SE to auto-deploy the app.
The advantage of course is that you (or whoever) doesn't have to do
anything to "deploy" the app... SE just sees it there and
auto-deploys it for you/them. Keeping in mind that manually deploying an app is
just a one-time thing per ASI.
The people that really like auto-deploy are those that build their own
installer for their servlet-based product, and then embed SE's installer
in their installer.
When the end user runs the installer, it kicks off SE's installer, then
once SE is installed, their installer drops their servlet-based product
(already packaged in the form of a webapp) into the auto-deploy folder.
So then the end user cranks up SE and "magically" the application
they bought is there, deployed, ready for use.
New Atlanta Communications, LLC
Kelly, Michael (DSI) wrote:
>Thanks for the references. I read everything you pointed me at and it
>was all helpful.
>By your suggestion, I could distribute my web apps as
>I see an advantage in your way. If I put the source at
>I can reuse that source for any number of instances (assuming I can
>share web apps between instances).
>I notice that a lot of examples use the webapp folder as the root folder
>(at least I think so since I spotted files like index.html there).
>How about making the instance root
>C:\ServletExec AS\se-<some instance>\webapps\default\default-app
>And placing the web app sources at
>C:\ServletExec AS\se-<some instance>\webapps\webappA
>C:\ServletExec AS\se-<some instance>\webapps\webappB
>C:\ServletExec AS\se-<some instance>\webapps\webappC
>What do you see as the advantages of placing your web app in
>C:\ServletExec AS\se-<some instance>\webapps\webAppA
>I assume the C:\ServletExec AS\se-<some instance>\webapps\default
>is meant to contain web apps set up by default by SE when a new instance
>The problems I was having with executing the batch files had to do with
>missing activation.jar and mail.jar in the classpath, which is kind of
>obvious from the error message. I just made the dumb assumption that if
>I followed the steps of the example all the jar files would be in place.
>In the end here is what I did (and it worked) for those who come after:
>1) Get the Axis download and unzip
>2) Create a servletexec instance on the web app server.
>3) Place the Axis code in a convenient location. I used the
>command copy <axisunziplocation>/webapps/axis <SE instance
>location>/webapps/axis. You may, of course, put it at
>4) Use the SE admin console to create a web application at the
>location you copied to. In my case I called the web application
>(If you copied to C:\myWebapps\webappA\ you would probably call the web
>5) Create a .jws file (I called mine Wrapper.jws) at the location
>you copied to. In the jws file define your services. This jws file can
>of course call any code you have in the classes folder or in jar files.
>6) That's all. You can now call the service Wrapper.jws.
>ServletExec-Interest. For archives and unsubscribe instructions, visit:
ServletExec-Interest. For archives and unsubscribe instructions, visit: