axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Gordie <>
Subject RE: Possibility of creating stand-alone and embeddable versions o f Ax is was RE: cvs commit: xml-axis/java/samples/attachments EchoAttach m ent. java
Date Fri, 26 Apr 2002 13:38:11 GMT

(This is a long email, but I felt it was important enough to warrant more
detail than before, so please look this over and let's keep the thread going
until we arrive at a some decision point.  Thanks)

I'm also leaning away from NotSoSimpleAxisServer since that would require
considerable effort to implement and debug fully.  

Currently, the SimpleAxisServer is used for unit testing the rest of Axis so
it is a critical component, IMHO.  However, since it is not a servlet
container at present, one could argue that the tests that are currently in
place, which use SAS, are not really doing a good job of simulating how Axis
is going to behave once placed in a full servlet container.  Again, an
argument for either making it a full container, or adding one to the

If we were to add Jetty (or some other lightweight, embeddable container) to
the Axis project, then we could modify the unit tests to run with either SAS
or Jetty...or both.  

The way I see it, there are several different ways that we could integrate /
distribute Jetty with Axis.

A)  We would create an additional axis-jetty.jar distro (similar to the way
the JBoss guys package JBoss with Tomcat (jboss-tomcat.jar), with Jetty
(jboss-jetty.jar) and standalone (jboss.jar) for embedding in your own app
server / container.  This new distro would contain a JettyAxisServer.class
that would instantiate Jetty, map Axis into a WebApplicationContext and
start listening for requests.  Of course, we would provide a launch
mechanism via an Ant task or shell scripts to make it easy for a user to get
at this new functionality.

B)  We could add the Jetty .jar's to the main distro, but provide the
end-user with launch mechanisms for SAS (we don't want to remove that IMO)
and the new JettyAxisServer as I mentioned in option A).  This would bloat
the primary distro and I don't really see any benefits to doing it this way
other than keeping the sheer number of .jar's to a minimum.

I feel much more comfortable with A) since we could also add axis-tomcat.jar
at some point.  Tomcat is much more difficult to embed from what I gather
from others...and I'd prefer to embed Jetty first since I have experience
with it already.

Please understand that I can setup the in a day or so,
depending upon how much time I can squeeze into it.  

If you guys would like, I can create an axis-jetty.jar from the latest CVS
build, that would include my GUI patches, as well as JettyAxisServer along
with a jetty.xml for launching the whole thing via "ant jetty.xml server
-Dport=8080" or something similar.  Then you guys could examine how I did
it, provide feedback, vote on it and let's see where it goes.

Bottomline, my patches are being committed due to the inability of SAS to
host the AxisServlet and there are very few easy ways past that.  I would
much rather spend my time making the AxisServlet GUI with the ability to
manage services, operations, invoke operations, etc. that puts us on level
playing ground with .NET rather than spending alot of time working on
implementing a servlet container in SAS.

Please look this over and let me know what you think.


-----Original Message-----
From: Tom Jordahl []
Sent: Thursday, April 25, 2002 5:21 PM
To: ''
Subject: RE: Possibility of creating stand-alone and embeddable versions
o f Ax is was RE: cvs commit: xml-axis/java/samples/attachments
EchoAttachm ent. java

I am partial to the Jetty idea, sounds pretty neat.

I am not a big fan of the NotSoSimpleAxisServer, but it might not be so bad.
I have no sense of how much work it is to make a simple servlet container.
Could we steal Jetty code and use it in SimpleAxisServer?

I would support the Jetty idea only if there was a clear distinction (via
jar files, docs and such) as to where axis.jar ended and
axis-with-a-servlet-container.jar started. One of the design goal of Axis is
to try and keep it small.

Tom Jordahl


-----Original Message-----
From: Alan Gordie []
Sent: Monday, April 22, 2002 10:43 AM
To: ''
Subject: Possibility of creating stand-alone and embeddable versions of
Ax is was RE: cvs commit: xml-axis/java/samples/attachments
EchoAttachment. java

Ahh, this seems like a good time for us to discuss SimpleAxisServer a bit.
I'll also throw my ideas about stand-alone / embeddable Axis in as well.

It appears to me that the SimpleAxisServer is being used primarily for
automated testing, as well as quick-and-dirty service deployment for some
folks (again, I'm sure this is for testing).  Now, in order to add support
for testing the servlet-based GUI that I've been working on via
SimpleAxisServer without requiring Axis to be deployed to a
Tomcat/Websphere/etc server, I need to do one of the following:  

a)  Add query string / parameter parsing and then manually drive my classes
in a non-servlet manner behind the scenes.
b)  Evolve SimpleAxisServer into a basic-servlet container and then host
AxisServlet as a servlet.
c)  Use a free, embeddable servlet container that already fits the bill.

My comments...

a)  This would be a one-off type of change that would only serve my purposes
and would not necessarily be reusable in other contexts.  Therefore, I'm
leaning away from this method.

b)  This solution could be a Good Thing(tm) if the concensus is that we
should grow SimpleAxisServer into NotSoSimpleAxisServer.  What do you guys
think?  I'm ok with implementing a very basic container if need be, but this
is not my preference.

c)  We could use an http server / servlet container that supports
HTTP/HTTPS, MIME, as well as the Servlet API to provide a one-stop shop for
serious testing and even small production deployments.  Imagine if a user
could simply download Axis and begin deploying WS's.  

I know, I know, most folks doing serious work will already have a server for
deploying Axis, but I would argue that a large majority of newcomers would
find this type of "single jar" solution attractive.

The benefits of c) would be multi-faceted...
 *  Automated testing could be taken up a notch for things like MIME & HTTPS
 *  We could create an "Axis Server" distro that folks could use for
actually deploying WS's.
 *  We could create an "Embeddable Axis" distro that folks could use for
trivially adding support for WS's, both client _and_ server-side into their
existing, and future, applications.  
----These last two could also help to get press/attention for the Axis
project in general.  

Note:  I'm already experienced with embedding Jetty
( into our application server and would be glad to
contribute the integration work to make this happen in Axis.  

FYI, Here's the high-level feature list for Jetty (from their website):
*  100% Java Server
*  Open Source
*  HTTP Protocol 1.1
*  Servlet API 2.3
*  Java Server Pages 1.2
*  SSL Support
*  Modular Architecture
*  Embeddable
*  Small & Efficient
*  Flexible Configuration
*  HTML Generation. 
*  EJB & JMX Integration

Also note that I'm not affiliated with Jetty in any way, shape or form.
It's just a really great tool and seems to be appropriate for this type of
thing, IMHO.

Thanks for reading this far, please let me know what you think of these

Am I way off base here?


-----Original Message-----
From: Glen Daniels []
Sent: Friday, April 19, 2002 2:50 PM
To: ''
Subject: RE: cvs commit: xml-axis/java/samples/attachments
EchoAttachment. java

>   Add a functional test for attachments but comment it out since
>   SimpleAxisServer doesn't support it.  If we ever switch to
>   a real server (like Tomcat) ...

...or add MIME support to SimpleAxisServer....


View raw message