You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Prabhath Suminda (JIRA)" <ji...@apache.org> on 2012/11/28 05:44:57 UTC
[jira] [Created] (AXIS2-5463) Optimizations for Axis2 POJO web
services
Prabhath Suminda created AXIS2-5463:
---------------------------------------
Summary: Optimizations for Axis2 POJO web services
Key: AXIS2-5463
URL: https://issues.apache.org/jira/browse/AXIS2-5463
Project: Axis2
Issue Type: New Feature
Components: adb, kernel
Reporter: Prabhath Suminda
Priority: Minor
Attachments: POJO_optimizations.patch
I did some optimizations for the Axis2 POJO web services as an intern project in last two months. It was a research type project and its idea was to handle POJO web services without using Java Reflection to improve the response time.
The method I followed to accomplish it was, when a POJO service is deployed, Axis2 generates a code which contains the logic to invoke that service. To generate this code Java reflection is used. In the run time service is invoked through the generated code for that service.
The generated code is like the code is like the code generated by wsdl2java tool using ADB. So the idea was to achieve the performance of ADB services for POJO services by this. In wsdl2java tool code is generated as .java files. But in this case those had to be generated as .class files because those have to be invoked at runtime. To do this I used a Java bytecode library called JavaAssist.
Currently this new michanisam support most of the Java types like, primitives, Strings, arrays, lists, maps, enums, Java beans and data handlers. But its not mature enough like the existing mechanism and therefor i integrated it with the existing mechanism instead of replacing it. To use this new method a parameter can be added to the service descriptor like below.
<parameter name=optimizedPOJO> true </parameter>. If this is included service invocation will done using the new mechanism and other wise usual procedure will be followed.
Attached patch contains the changes done by me. To test the new method one can apply this patch to a downloaded trunk in a local environment, build the trunk and create a new war file and deploy it. Then create a POJO service and add <parameter name=optimizedPOJO>true </parameter> to service descriptor and deploy it.
Here the code will be generated as class files in the temp directory. If someone want to look in to them as Java code those can be written as text files in addition to .class files by uncommenting the FileUtils.writetoFile() statements in code generating classes (these classes are included in the patch).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] [Updated] (AXIS2-5463) Optimizations for Axis2 POJO web
services
Posted by "Prabhath Suminda (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Prabhath Suminda updated AXIS2-5463:
------------------------------------
Attachment: POJO_optimizations.patch
> Optimizations for Axis2 POJO web services
> -----------------------------------------
>
> Key: AXIS2-5463
> URL: https://issues.apache.org/jira/browse/AXIS2-5463
> Project: Axis2
> Issue Type: New Feature
> Components: adb, kernel
> Reporter: Prabhath Suminda
> Priority: Minor
> Attachments: POJO_optimizations.patch
>
>
> I did some optimizations for the Axis2 POJO web services as an intern project in last two months. It was a research type project and its idea was to handle POJO web services without using Java Reflection to improve the response time.
> The method I followed to accomplish it was, when a POJO service is deployed, Axis2 generates a code which contains the logic to invoke that service. To generate this code Java reflection is used. In the run time service is invoked through the generated code for that service.
> The generated code is like the code is like the code generated by wsdl2java tool using ADB. So the idea was to achieve the performance of ADB services for POJO services by this. In wsdl2java tool code is generated as .java files. But in this case those had to be generated as .class files because those have to be invoked at runtime. To do this I used a Java bytecode library called JavaAssist.
> Currently this new michanisam support most of the Java types like, primitives, Strings, arrays, lists, maps, enums, Java beans and data handlers. But its not mature enough like the existing mechanism and therefor i integrated it with the existing mechanism instead of replacing it. To use this new method a parameter can be added to the service descriptor like below.
> <parameter name=optimizedPOJO> true </parameter>. If this is included service invocation will done using the new mechanism and other wise usual procedure will be followed.
> Attached patch contains the changes done by me. To test the new method one can apply this patch to a downloaded trunk in a local environment, build the trunk and create a new war file and deploy it. Then create a POJO service and add <parameter name=optimizedPOJO>true </parameter> to service descriptor and deploy it.
> Here the code will be generated as class files in the temp directory. If someone want to look in to them as Java code those can be written as text files in addition to .class files by uncommenting the FileUtils.writetoFile() statements in code generating classes (these classes are included in the patch).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org