Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <188617194.1100708125746.JavaMail.apache@nagoya>
Date: Wed, 17 Nov 2004 08:15:25 -0800 (PST)
From: =?ISO646-US?Q?S=3Fbastien_Tardif_=28JIRA=29?= <axis-dev@ws.apache.org>
To: axis-dev@ws.apache.org
Subject: [jira] Updated: (AXIS-1609) No option available to map all MIME type
 to javax.activation.DataHandler as required by JAX-RPC 1.1 specification.
In-Reply-To: <987245625.1097767312494.JavaMail.apache@nagoya>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

     [ http://nagoya.apache.org/jira/browse/AXIS-1609?page=3Dhistory ]

S=E9bastien Tardif updated AXIS-1609:
-----------------------------------

    Attachment: diff.txt

Here the patch following the official instruction to submit a patch. All un=
it tests are passing.
This patch add a new parameter to WSDL2Java:
  -m, --dataHandlerOnly
          always map attachments to the DataHandler type

With this patch Axis will be more JAX-RPC compliant.

> No option available to map all MIME type to javax.activation.DataHandler =
as required by JAX-RPC 1.1 specification.
> -------------------------------------------------------------------------=
-----------------------------------------
>
>          Key: AXIS-1609
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1609
>      Project: Axis
>         Type: Bug
>   Components: WSDL processing
>     Versions: 1.2 Beta
>  Environment: Axis 09/23/2004
>     Reporter: S=E9bastien Tardif
>  Attachments: diff.txt, docHarbor.wsdl
>
> My use case is to use SwA and doing streaming from end to end. The type o=
f attachment is not known. So as suggested by many documents I use the mime=
 type: "application/octet-stream". Wsdl2Java utility use org.apache.axis.at=
tachments.OctetStream to represent the data. It's a class specific to Axis =
which is one of my concern.
> Take a look a the class:
> public class OctetStream {
>     private byte[] bytes =3D null;
>     public OctetStream() {
>     }
>     public OctetStream(byte[] bytes) {
>         this.bytes =3D bytes;
>     }
>     public byte[] getBytes() {
>         return this.bytes;
>     }
>     public void setBytes(byte[] bytes) {
>         this.bytes =3D bytes;
>     }
> }
> It doesn't support streaming! It's probably the reason why people will us=
e attachment instead of the most compatible way: "xsd:base64Binary".
> As a third issues:
> The JAX-RPC 1.1 specification said:
> 7.5 Mapping between MIME types and Java types
> The following table specifies the standard Java mapping for a subset of t=
he MIME types.
> The Java to WSDL/XML and WSDL/XML to Java mapping for the MIME types is
> required to conform to the above mapping. This mapping is reflected in th=
e mapped Java
> method signatures and WSDL description. A WSDL/XML to Java mapping tool i=
s
> required to provide an option to map the above set of MIME types to the
> javax.activation.DataHandler class. The DataHandler class provides method=
s to
> get access to the stream representation of the data for a MIME type.
> A Java to WSDL mapping tool is required to provide a facility for specify=
ing metadata
> related to the above mapping between Java and MIME types. This metadata i=
dentifies
> whether a Java type is mapped to a MIME type (using the WSDL MIME binding=
) or is
> mapped to an XML schema type (based on the section 4.2, "XML to Java Type
> Mapping"). For example, a java.lang.String can be mapped to either an xsd=
:string
> or MIME type text/plain. The mapping metadata identifies a specific mappi=
ng.
> If a MIME type is mapped to the javax.activation.DataHandler, the getCont=
ent
> method of the DataHandler class must return instance of the corresponding=
 Java type
> for a specific MIME content type.
> A JAX-RPC implementation is required to support the above MIME types (as =
specified
> in the TABLE 7-1) and provide implementation of the required
> javax.activation.DataContentHandler classes.
> ...
> A JAX-RPC implementation is not required to support MIME types beyond tha=
t
> specified in the above table. These additional MIME types may be mapped a=
nd
> supported using the javax.activation.DataHandler class and Java Activatio=
n
> Framework.
> TABLE 7-1 Mapping of MIME Types
> MIME Type Java Type
> image/gif java.awt.Image
> image/jpeg java.awt.Image
> text/plain java.lang.String
> multipart/* javax.mail.internet.MimeMultipart
> text/xml or application/xml javax.xml.transform.Source
> Here the approch of another stack:
> From: https://jax-rpc.dev.java.net/whitepaper/1.1.2/attachments-howto.htm=
l
> JAXRPC specification uses the JavaBeans Activation Framework to support v=
arious MIME content types. The DataHandler class provides a consistent inte=
rface to the data represented in various MIME types. A DataHandler class us=
es the DataContentHandler interface to convert between a stream and specifi=
c Java object based on the MIME type. JAXRPC uses SAAJ, which provides Data=
ContentHandlers for the MIME types supported by JAXRPC. If the MIME type is=
 not one of the JAXRPC supported MIME types, then the user has to register =
corresponding DataContentHandlers. Here "text/plain" and "text/xml" are bot=
h JAXRPC supported MIME types and is taken care of automatically. A DataHan=
dler can be instantiated using the constructor DataHandler(Object obj, Stri=
ng mime_type). The method DataHandler.getContentType returns the MIME type =
of the encapsulatd data and DataHandler.getContent method retruns a Java ob=
ject based on the MIME type of the encapsulated data. If you do not want th=
e MIME types to map to coresponding Java types, you can use wscompile with =
-datahandleronly option to map all MIME types to DataHandler.

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira