+1
Cheeers,
Michel
(Too bad I have only one vote... ;-)
On 3 May 2006, at 9:25, Frank Cornelis (JIRA) wrote:
[ http://issues.apache.org/jira/browse/AXIS2-655?
page=comments#action_12377532 ]
Frank Cornelis commented on AXIS2-655:
--------------------------------------
I've tested the new interface approach and it works just as
expected. If you revert back to the situation where the skeleton
does not implement from the interface, could you please keep the
generated interface? That way I can extend the skeleton (that does
not implements the interface) and also implement the interface in
my 'Impl' class... Please consider this alternative approach...
dropping the interface again is just bad... keep it... OK if you
don't want to make the skeleton implement the interface per
default.... but please don't drop it.... it's too important in
production builds.... where you want to detect wrongly implemented
'Impl's at compile time.... runtime it just too late...
Frank.
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
