Gabriel,
Thank you for your input, option B is definitely a possibility. I
should note that due to the drastic changes going into JAXRPC 2.0,
existing applications may have to do some porting to build with the new
JAXRPC as generated signatures, WSDLS, etc. maybe
different since we will be using JAXB to do data binding between XML
schema and Java classes. However, existing services
and clients that are not recompiled will of course run with the 2.0
runtime. We plan on writing a porting guide specifying the changes
between 1.x and 2.0. If we change the default behavior of the tools, we
would definitely highlight such a change in the porting
guide. Another way that users can get old signatures, behavior, etc, is
to use the -source option on wscompile, however, doing
this will basically just give you 1.x functionality.
Thanks again for your feedback.
Gabriel Bauman wrote:
>Hi Doug...
>
>On Wed, 2004-07-14 at 15:06 -0700, Doug Kohlert wrote:
>
>
>>Should wscompile and wsdeploy leave the default mode as rpc/encoded for
>>backwards compatibility reasons, or should the default be changed to
>>document/literal?
>>
>>
>
>The default should absolutely not be changed. If you are at all worried
>about backwards compatibility, build tools should not change behaviour
>just because new features are added.
>
>My suggestion would be to have both -f:rpcencoded and -f:documentliteral
>defined by the tools. If neither option is specified, default to
>rpcencoded to maintain compatibility, but print a big warning to the
>console telling people to explicitly specify their preference. This way
>current build scripts would continue to function entirely as expected,
>and everyone would be made aware that the emerging document/literal
>standard is not being used, but is available.
>
>The absolute most drastic measure I would consider reasonable would be
>removing the concept of a "default format" and forcing users to choose
>what they want for output. This would break build scripts, but it would
>only break them once. Just making documentliteral the default would not
>cause the build to fail, but introduces unexpected behaviour, which is a
>Very Bad Thing. If you change the default behaviour in the next version,
>you MUST ENSURE THAT EXISTING BUILD SCRIPTS FAIL. I can't emphasize this
>enough.
>
>To summarize, I suggest either:
>
>A. Leave the default as-is and print an informational message to the
>console when output type is not explicitly specified,
>
>or
>
>B. Remove the default behaviour and force users to specify the type of
>output they require.
>
>In a perfect world, my preference would be B, but A is probably the
>friendliest.
>
>Thanks for inviting input, and for the excellent product.
>
>==
>Gabriel Bauman <gabe_at_bravenet.com>
>Bravenet Web Services, Inc.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Doug Kohlert
Sun Microsystems, Inc.
doug.kohlert_at_sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net