Re: [AXIS2] Current Axis2 "embeddability"

[Davanum Srinivas <da...@gmail.com>]

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 <ml...@void.fm> 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/

Re: [AXIS2] Current Axis2 "embeddability"

[Jens Schumann <ml...@void.fm>]

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 <da...@gmail.com>:

> 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 <ml...@void.fm> 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/
>