axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michel Drescher <Michel.Dresc...@uk.fujitsu.com>
Subject Re: [jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Date Wed, 03 May 2006 09:26:40 GMT
+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
>


Mime
View raw message