Will do so. However I had a hard to time separate the stuff from each other so I decided to get the stuff on the list first.
Jens Am 4/17/06 5:03 PM schrieb "Davanum Srinivas" unter <[EMAIL PROTECTED]>: > 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/ >
