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 "Frank Cornelis (JIRA)" <ji...@apache.org> on 2006/05/02 14:52:46 UTC
[jira] Created: (AXIS2-655) Generated Skeleton difficult to use
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
Priority: Blocker
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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377587 ]
Sanjiva Weerawarana commented on AXIS2-655:
-------------------------------------------
Ajith please don't forget to add the option to the eclipse and idea plugins!
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377521 ]
Deepal Jayasinghe commented on AXIS2-655:
-----------------------------------------
Ohhh , I did not notice the problem in first place and we agreed that we are not going to add any more new features. But finally we have added a new feature and all the users who use RC4 , need to code gen again.
I know this a required feature , but at this point we should add none of new features. So we have to revert the changes and we can do the changes after 1.0.
Ajith : Can you please make the necessary changes to get the code back to previous status.
I am sorry for asking to remove the changes , in the mean while I will reduce the priority.
> 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
> Priority: Blocker
>
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Frank Cornelis (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377407 ]
Frank Cornelis commented on AXIS2-655:
--------------------------------------
Wow! That was fixes very fast. Thanks.
> 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
> Priority: Blocker
>
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Dennis Sosnoski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12378348 ]
Dennis Sosnoski commented on AXIS2-655:
---------------------------------------
I agree that the current approach is very awkward. If you're using scripted builds (such as Ant) you can use text substitution on the generated message receiver and services.xml to change the service implementation class to be whatever you want, but it's ugly to have to do this. Generating an interface and allowing the user to specify the actual implementation class for the services.xml seems like a step in the right direction.
> 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
> Assignee: Ajith Harshana Ranabahu
>
> 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
[jira] Assigned: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=all ]
Deepal Jayasinghe reassigned AXIS2-655:
---------------------------------------
Assign To: Ajith Harshana Ranabahu
> 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
> Assignee: Ajith Harshana Ranabahu
>
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377428 ]
Sanjiva Weerawarana commented on AXIS2-655:
-------------------------------------------
One more thought .. while I understand the need to be able gen an interface, I'm not in agreement to make that the default. IMO the simple case is that a person fills in the skeleton .. and as such there's no interface involved. I'm certainly +1 for having an option to generate an implementation interaface and for the message receiver to depend on that.
> 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
> Priority: Blocker
>
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12378830 ]
Deepal Jayasinghe commented on AXIS2-655:
-----------------------------------------
Ajith : I think we can reslove this issue , as I know u have fixed this
> 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
> Assignee: Ajith Harshana Ranabahu
>
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377561 ]
Ajith Harshana Ranabahu commented on AXIS2-655:
-----------------------------------------------
Hi,
I see that this is an important feature and it'll be unfair if it wont make to 1.0. At the same time Sanjiva raised an important side-effect which we also need to consider.
So here is the compromise. I added a parameter to switch the interface genration (see Sanjiva's second sugession). This will cause the codegen to behave as usual for the normal case but if the users care to specify the new switch, they'll get the behavior they need.
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377576 ]
Sanjiva Weerawarana commented on AXIS2-655:
-------------------------------------------
OK I won't -1 this but I'm VERY uncomfortable with this solution. Let's hope nothing gets screwed up ..
Also, going back to a comment made by Frank a bit above, I don't see how gen'ing the interface gives you compile time validation of the correct impl class being given. If you use services.xml and point to a random foo class, that won't be detected until the cast occurs in the message receiver- which is at runtime. Am I missing something??
> 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
[jira] Resolved: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=all ]
Ajith Harshana Ranabahu resolved AXIS2-655:
-------------------------------------------
Resolution: Fixed
The issue has been solved and already included in the 1.0 release
> 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
> Assignee: Ajith Harshana Ranabahu
>
> 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
[jira] Updated: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=all ]
Deepal Jayasinghe updated AXIS2-655:
------------------------------------
Priority: Major (was: Blocker)
We will implemnt the feature after 1.0
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377525 ]
Ajith Harshana Ranabahu commented on AXIS2-655:
-----------------------------------------------
Ok I have to agree that the timing of this change is somewhat tight and since Sanjiva mentioned a clear workaround for the current code (and I'm not too happy about the fact that users would be needing to change their skeleton implementations for 1.0) I will be reverting the change.
> 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
Re: [jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by Michel Drescher <Mi...@uk.fujitsu.com>.
+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
>
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Frank Cornelis (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Tom Jordahl (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12378024 ]
Tom Jordahl commented on AXIS2-655:
-----------------------------------
I am confused why this is an issue at all since we had this well implemented in Axis 1.x in a way that users understood and were (mostly) happy with.
I am against inventing new switches and methods when Axis already has a 'standard' way of generating skeletons and *Impl classes (which don't get overwritten if they already exist).
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377419 ]
Sanjiva Weerawarana commented on AXIS2-655:
-------------------------------------------
I'm very uncomfortable with this change because its invasive and it affects all generated code and it affects all the 1.0 testing we've done.
There is a workaround for now: just have your class extend the generated class. Its not beautiful but it works!
> 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
> Priority: Blocker
>
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Frank Cornelis (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12377559 ]
Frank Cornelis commented on AXIS2-655:
--------------------------------------
Ajith,
Last minute features indeed make up for an unnecessary risk.
I'm using the SVN anyway, so if it's available in SVN then I can do my thing.
Until 1.0 has been released, the availability of a patch would be nice so I can put in this feature again in my source tree. Thanks.
What I'm a little worried about is that such a feature wouldn't make it into a 1.0.x, but will be postponed until a 1.1, which can take a while. In the meanwhile JAX-WS is offering this feature... and for production systems this really makes the difference when there is the need to choose between JAX-WS or Axis2. I can only hope for a frequence release schedule for Axis2 to keep up with other WS frameworks... Axis2 has a superior design... thus it would be a waste if people had to wait too long for a certain feature to make it into a release.
Anyway, it's your call. I'm just an outsider, making some noise every now and then. :)
BTW: same interface feature could be applied to the generated xxxCallbackHandler class at the client-side.
> 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
[jira] Commented: (AXIS2-655) Generated Skeleton difficult to use
Posted by "Mike McAngus (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-655?page=comments#action_12378953 ]
Mike McAngus commented on AXIS2-655:
------------------------------------
My only complaint about the generated interface is its name. XxxxSkeletonInterface links this interface too closely with the Skeleton class.
A few name suggestions I have are:
XxxxInterface
XxxxI - To indicate that this is an interface without spelling out the word.
XxxxService - since the class(es) that extend(s) the interface will be responsible for the Business Logic of the web service (I expect the Implementation class(es) to be named something like XxxxServiceImpl).
My personal preference for the interface name is the last one.
> 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
> Assignee: Ajith Harshana Ranabahu
>
> 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