Jens, Could you please split up the issues and log separate bugs? so that we can track them and get them fixed?
thanks, dims On 4/17/06, Jens Schumann <[EMAIL PROTECTED]> 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 : http://wso2.com/blogs/
