Bug 132905 - JAX-RPC restrictions on Java bottom-up are unclear
Summary: JAX-RPC restrictions on Java bottom-up are unclear
Status: CLOSED FIXED
Alias: None
Product: WTP Webservices
Classification: WebTools
Component: jst.ws (show other bugs)
Version: 1.5   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.5 RC3   Edit
Assignee: Chris Brealey CLA
QA Contact:
URL:
Whiteboard: 1.5 RC3
Keywords: Documentation
: 112656 126957 135167 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-03-22 17:00 EST by Chris Brealey CLA
Modified: 2006-05-19 10:09 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Brealey CLA 2006-03-22 17:00:02 EST
Actually, the requirements on Java service classes and value types in a bottom-up scenario are fairly clear as described in chapter 5 of the JAX-RPC 1.1 specification [1]. Users should not, however, have to read the JAX-RPC spec to understand what all the limitations are. When JAX-RPC's requirements are violated in a prospective Java service class or in the types it uses, the result today is usually a fairly nasty or cryptic error message or exception from the relevant Java-to-WSDL code generator.

WTP's Web service wizards should validate that a Java service class is acceptable according to JAX-RPC chapter 5 before proceeding attempting to deeply analyze or generate code from the Java.

This bug is meant to tackle those few issues that occur very often to unwary users of the platform. This bug is not meant to provide exhaustive JAX-RPC validation, or to provide an extensible platform for Web service runtime providers to amend the validation rules. Such a goal is quite legitimate, but should be opened as an RFE.

[1] http://java.sun.com/xml/downloads/jaxrpc.html
Comment 1 Chris Brealey CLA 2006-04-05 23:27:48 EDT
*** Bug 135167 has been marked as a duplicate of this bug. ***
Comment 2 Chris Brealey CLA 2006-04-18 12:53:03 EDT
This fix will require changes to the documentation - Not about the specific conditions against which Java will be checked, but about the fact that checking will happen and that the user may get a detailed warning/error dialog for non-JAX-RPC-compliant Java in bottom-up scenarios.
Comment 3 Chris Brealey CLA 2006-04-21 08:50:17 EDT
The following messages have been added to org/eclipse/jst/ws/internal/WSPlugin.properties and org/eclipse/jst/ws/internal/WSPluginMessages.java,
committed and released under tag v200604202152:

MSG_JAXRPC11_NOT_COMPLIANT=The service class "{0}" does not comply to one or more requirements of the JAX-RPC 1.1 specification, and may not deploy or function correctly.

MSG_JAXRPC11_RULE_0001=The service class {0} does not have a public default constructor. Chapter 10.1 of the JAX-RPC 1.1 specification requires a service class to have a public default constructor, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the service class to handle an incoming request message. 

MSG_JAXRPC11_RULE_0002=The value type {0} used via the service class {1} does not have a public default constructor. Chapter 5.4 of the JAX-RPC 1.1 specification requires a value type to have a public default constructor, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the value type during deserialization.

MSG_JAXRPC11_RULE_0003=The method "{0}" on the service class "{1}" is overloaded. Overloaded methods are allowed by chapter 5.5.5 of the JAX-RPC 1.1 specification, however, some JAX-RPC 1.1 compliant tools may not allow overloaded methods or may generate WSDL with overloaded operations as contrary to rule R2304 of the WS-I Basic Profile.

MSG_JAXRPC11_RULE_0004=The service specific exception class "{0}" does not have a public constructor with parameters corresponding in number and type to the getter methods on the class. Chapter 5.5.5 of the JAX-RPC 1.1 specification requires a service specific exception to have a public constructor with the same number of parameters as there are getter methods, and of matching data types, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the exception during deserialization of a fault message.

MSG_JAXRPC11_RULE_0005=The method "{0}" on the service class "{1}" uses a data type, "{2}", that is not supported by the JAX-RPC specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.

MSG_JAXRPC11_RULE_0006=The field or property "{0}" on the value type "{1}" used via the service class "{2}" has a data type, "{3}", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.

MSG_JAXRPC11_RULE_0007=The primitive type "{0}" is not supported by the JAX-RPC 1.1 specification. As stated in chapter 5.1.1 of the specification, the supported primitive types are "boolean", "byte", "short", "int", "long", "float" and "double".

MSG_JAXRPC11_RULE_0008=The wrapper type "{0}" is not supported by the JAX-RPC 1.1 specification. As stated in chapter 5.1.1 of the specification, the supported wrapper types are those corresponding to "boolean", "byte", "short", "int", "long", "float" and "double".

MSG_JAXRPC11_RULE_0009=The Java type "{0}" is not supported by the JAX-RPC 1.1 specification. As stated in chapter 5.1.3 of the specification, the supported standard types are "java.lang.String", "java.util.Date", "java.util.Calendar", "java.math.BigInteger", "java.math.BigDecimal", "javax.xml.namespace.QName" and "java.net.URI".

MSG_JAXRPC11_RULE_0010=Support for collection and map classes such as "{0}" is not required by JAX-RPC 1.1. Due to their non-type safe nature, a JAX-RPC 1.1 compliant Web service engine may not handle collections, or may represent them in WSDL documents and SOAP messages in a manner that impairs interoperability. The use of arrays instead of collections is strongly recommended.

MSG_JAXRPC11_NOT_COMPLIANT will always be displayed when one or more JAX-RPC rules have been violated, and will always be followed by one or more detailed messages from MSG_JAXRPC11_RULE_0001-0006. Furthermore, each MSG_JAXRPC11_RULE_0005-0006 messages will usually be followed by one of MSG_JAXRPC11_RULE_0007-0010 to clarify what the unsupported type is and why.

Note that the messages are in, but not the actual detection logic. Stay tuned.
Comment 4 Chris Brealey CLA 2006-04-25 17:30:58 EDT
*** Bug 126957 has been marked as a duplicate of this bug. ***
Comment 5 Chris Brealey CLA 2006-05-05 17:12:25 EDT
*** Bug 112656 has been marked as a duplicate of this bug. ***
Comment 6 Chris Brealey CLA 2006-05-10 10:51:26 EDT
Committed to HEAD a new preference checkbox inside the "Java2WSDL" group on the Web Services / Axis Emitters page to control JAX-RPC validation. The preference is enabled by default. The preference does not yet result in actual validation. That's next.

AxisEmitterContext.java
AxisEmitterDefaults.java
PersistentAxisEmitterContext.java
AxisConsumptionUI.properties
AxisConsumptionUIMessages.java
AxisEmitterPreferencePage.java
Comment 7 Kathy Chan CLA 2006-05-10 17:02:17 EDT
New preferences released to WTP 1.5 RC3 as v200605102102.
Comment 8 Kathy Chan CLA 2006-05-17 23:23:14 EDT
Conformance and conformance.rules package and changes to BUAxisInputCommand had been committed and released to WTP 1.5 RC3 as v200605180400.
Comment 9 Chris Brealey CLA 2006-05-18 16:57:07 EDT
Clearing Target Milestone field and using Whiteboard field to capture desired target: 1.5 RC4.
Comment 10 Chris Brealey CLA 2006-05-19 10:09:35 EDT
Further changes were committed and released under tag v200605180405. Resolving bug as the core of the change is done, however, there is a JDT model navigation problem with mapping unresolved type names to/from JDT member signatures that prevents the JAX-RPC analysis engine from walking to unresolved types (and most types in compilation units are unresolved). I will open a separate bug for this.
Comment 11 Chris Brealey CLA 2006-05-19 10:09:46 EDT
Closed.