[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377546 ]
Ajith Harshana Ranabahu commented on AXIS2-655: ----------------------------------------------- Hi Frank, This is a delicate situation, I mean there is preparation for the 1.0 release and there is a tendency not to add last minute features (we've expereinced how these "last minute" feature additions back fire on us too often). It is my fault that I added this feature at the last moment and specially not with the approval of other community members. So I feel that we should be reverting this change after all. As for your situation would you be comfortable working with the code out of SVN head? I'll revert the change in the SVN head and once the SVN is tagged for the 1.0 release I'll commit it back in. However you'll have to work with the SVN head and the 1.0 release will not have what yo want! I can also attach a patch here that will have the necessary code changes which you can apply on top of the 1.0 code (if that helps rather than getting all the code from SVN) thoughts ? > Generated Skeleton difficult to use > ----------------------------------- > > Key: AXIS2-655 > URL: http://issues.apache.org/jira/browse/AXIS2-655 > Project: Apache Axis 2.0 (Axis2) > Type: Improvement > Reporter: Frank Cornelis > > When generating code starting from a WSDL you end up with a Skeleton. The > idea is to use this 'xxxSkeleton' to create your own 'xxxImpl', hence the > name skeleton I guess... > But, the problem with this is that this generated skeleton class is hardcoded > in a cast in in the generated xxxMessageReceiverInOut. So copying the > skeleton to your own Impl and letting services.xml point to this new Impl > 'ServiceClass' simply won't work. It really has to be 'xxxSkeleton'. So why > make it configurable in services.xml if it's hardcoded anyway? I also don't > thing I should manually change 'xxxMessageReceiverInOut' for each new 'Impl' > class I want to try out. Also, each time I run my codegen, the skeleton is > overwritten... is simply doesn't work this skeleton thing... it's pointless... > Also, it would be much better if you would have a nicely generated interface > to implement, instead of that skeleton thingy. The generated skeleton should > implement this interface. The 'xxxMessageReceiverInOut' should cast to the > interface type instead of cast to the 'skeleton'. That way you can point to > whatever 'xxxImpl' you want to, as long as you implement the correct > interface. Another benefit of using this interface approach is that a change > in the WSDL is directly reflected in a change of the interface you have to > implement. Thus you detect required changes in the 'Impl' during compilation > instead of runtime. > The above issues are really critical for Axis2 to be fully usable in a > production environment. If JAX-WS can do it, Axis2 should too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
