[AXIS2] Current Axis2 "embeddability"

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

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

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/
> 

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/