axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: [AXIS2] Current Axis2 "embeddability"
Date Mon, 17 Apr 2006 15:03:20 GMT

Could you please split up the issues and log separate bugs? so that we
can track them and get them fixed?


On 4/17/06, Jens Schumann <> wrote:
> Hi Axis2-Team,
> First of all I have to say thanks to you to get Axis2 done. After using 0.95
> for a while I have to admit that I am very pleased with the overall progress
> and the way to implement web services in Axis2 land. Good work.
> Anyway - since we are getting close to Axis2 Release 1 it is also time to
> start complaining;). Please read the following lines more or less as a brain
> dump for some of the issues I found. If you think it has some value and
> there is need for volunteer work - let me know. Here we go:
> While looking for the cause of "javax.servlet.ServletException: Invalid
> logging" I found AXIS2-334, which got a "Won't fix" status without further
> details. Therefore I flipped through the related admin sources ... and to be
> honest: the current axis2 admin application is by far the worst web app I
> have seen since early JSP days. Even though the pages itself look good the
> existing code just smells. Where have you guys been in the last couple
> years? ;)
> Of course one could go ahead and remove most of the java code from JSP pages
> (especially security checks or hard wired path references). And fix HTML and
> spelling errors (No - It's not "Invalid Logging". It's "Invalid login". And
> definitely not "Administrations Page" nor "Administartion page").
> However all those cosmetic changes would not solve a fundamental issue which
> comes with it's current design: It's lack of embeddability.
> From my first impression the current implementation strictly focuses on
> getting out a "one-stop-package" provided by axis2.war. While this is good
> for beginners, it doesn't help if have to add webservices support to an
> existing web application. To do so, I have to
>  1. add several jars,
>  2. alter my existing web.xml,
>  3. add axis2.xml,
>  4. (optionally) add axis .mar modules,
>  5. create and add my webservice .aar service archive and
>  6. add several resources such as JSP's stylesheets and images.
> Overall steps 1-4 are pretty straight forward and the way to go. Step 5
> could be improved, but its fine for now (see below for further comments).
> But why should I add several JSP's and images/stylesheets to the root of MY
> web application? And which of them are required, even if I don't need axis2
> admin support?
> Interestingly, I have to to add a few JSPs and resources to MY web app root
> no matter what. Example: Just request the wsdl for an invalid endpoint using
> ?wsdl and listSingleService.jsp is required (to render the error).
> So in an ideal world I would ask for getting rid of step 6 - with or without
> admin support. Therefore all resources should be part of axis2 .jar files -
> which would mean the end of the current JSPs solution.
> Initially I was looking for the reason of AXIS2-334. It turned out to be
> some proprietary security implementation, which is flawed by design several
> times:
> - First of all it is proprietary and requires me to add a username/password
> combination to axis2.xml during build time. Personally I always have a hard
> time with fixed passwords in my deployment unit.
> - Second the security checks itself seem to happen in the VIEW only. After
> the action was processed. So if I am not mistaken I can manually create the
> admin URLs and deactivate services and so on. (Getting a rendering error of
> course afterwards)
> - One could argue that in a production environment you will not enable the
> AdminServlet. However it seems that the current AxisServlet doGet
> implementation will forward processing to the ListingAgent if there is no
> Soap Request. Which in turn means that I can disable services without
> knowing the username/password.
> Since I was browsing the sources only I have to admit that some of the
> security issues aren't proven yet. However I would love to see a more
> distinct security concept in order to avoid future problems (by adding code
> somewhere) and improve embeddability. Standard web security would come to my
> mind (creating a drop-in axis2.war then could be a pain though).
> Nevertheless AxisServlet should never ever be able to execute Admin
> operations;).
> Last but not least a minor note regarding Step 5 - creating .aar archives:
> If I want to add webservices support to my existing web application I have
> to create an .aar archive and deploy it within my .war archive. Of course I
> can alter my existing build process and create the .aar. Since I did not
> find anything in documentation or on the mailing list: Are there any plans
> to support "exploded .aar" deployments, where I just add a directory below
> WEB-INF/services/ which follows the .aar format? This would simplify adding
> axis2 webservice support to an existing web app, because all I need to do is
> to put the services.xml to my existing web app folder and ensure that all
> WSDL2Java generated sources are available.
> Looking forward to get feedback,
> Jens

Davanum Srinivas :

View raw message