Tracking system don't like XQConstants.CONTENT_TYPE_BYTE

What is the Java type of myObject? is it a byte[]? if not ESB will try convert it to a byte[] using a data content handler based on the mime type. But the mime type says it already is a byte[]. So it gives up.

Thomas

MyObject is a java serializable object (class with private members; setters and getters) used to store message and session informations.

The idea is to transfer to next custom service an object.

If the problem is due to the XQConstants.CONTENT_TYPE_BYTES, what is the type to use if you want to transfert an object?

It is not so much about the content type.

Data Content Handlers serialization (what the multipart messages tries to use) and serializable objects serialization have nothing in common.

So what you need to to is to serialize it yourself to a byte[] and store that as part content.

Alternatively, the part content can be an JMS ObjectMessage (progress.jclient*) and that would serialize it for you.

Either way.

Thomas

I am facing this kind of problem when I try to create a binary part from a pdf file.

Ihave also tried to use a ByteArrayDataSource but I get the same output.

contentDownload is a byte[]

Code :

partDl =msg.createPart();

partDl.setDataHandler(new DataHandler(new ByteArrayDataSource(this.contentDownload, "application/pdf"))); // replacing "application/pdf by  XQConstants.CONTENT_TYPE_BYTES don't work too.

// I get a similar error if I use :

partDl.setContent(this.contentDownload; XQConstants.CONTENT_TYPE_BYTES);

msg.addPart(partDl);
ctx.addOutgoing(msg);

here is the error trace

[10/03/26 17:56:11] ID=dev_ESBTest (info) [Dispatch] Message Rejected, rejected message could not be created for XQDispatcher for application FTPConnector

[10/03/26 17:56:11] ID=dev_ESBTest (info) [Dispatch] Cause of rejected message: XQ_ENDPOINT_EXCEPTION

[10/03/26 17:56:11] ID=dev_ESBTest (info) Trace follows...
com.sonicsw.xq.XQEndpointException: no object DCH for MIME type application/pdf: DestinationName=MgmtBroker::$ISYS.USERS.TemporaryTopicsAdministrator$TMPAPPID$147$$CONNECTION$.582971472 (no object DCH for MIME type application/pdf) (no object DCH for MIME type application/pdf)
    at com.sonicsw.xq.connector.jms.JMSEndpoint$EndpointConnection.sendWithUnbound(JMSEndpoint.java:1621)

regards

Chan Jeremy

Jeremy,

can you attach the full code so we can reproduce it?

Also, do you have the full stack (e.g. including any caused by)?

Thomas

Sorry for the late answer Thomas.

I had missed something in an other service when I ran my test (with contentType as byte) .

Using bytearraydatasource to construct an XQmessage seems not to be a good way.

Thanks

Chan Jeremy

I think I'm encountering the same or similar issue as the original poster.  I have a set of member objects that need to be asynchronously dispatched as independent messages, each message containing one member - fire and forget fashion.  When I either disable intra-container messaging to achieve the asynchronous behavior or dispatch to the destination endpoint name vs the destination process name, there are serialization errors and I get an XQDispatchException driven by an XQEndpointException:

XQEndpointException (no object DCH for MIME type application/octet-stream: DestinationName=C2CRequestForResourceForwardedRequestService.Entry (no object DCH for MIME type application/octet-stream)) (no object DCH for MIME type application/octet-stream: DestinationName=C2CRequestForResourceForwardedRequestService.Entry (no object DCH for MIME type application/octet-stream) (no object DCH for MIME type application/octet-stream))

There doesn't appear to be an XQConstants value which will treat the part as a general object for an ObjectMessage type and leave the implementor to cast it properly in the destination process/service.  Is this correct?

Even if I use the XQServiceContext.getMessageFactory().createMessage() to create a JMS Message flavor, when I add my object part content, I will still have to specify some string value that maps to a DataContentHandler.  You mentioned a progress.message.jclient.ObjectMessage type.  How do we specify this?

Thanks.

I did this before the dispatch of myObject type:

                byte[] bArray = null ;
                ObjectOutputStream out = null ;
                try {
                    ByteArrayOutputStream b = new ByteArrayOutputStream() ;
                    out = new ObjectOutputStream( b ) ;
                    out.writeObject( myObject ) ;       
                    bArray = b.toByteArray() ;
                } catch (Exception e) {
                    log.error( "Exception processing myObject", e ) ;
                } finally {
                        try { if (out != null) out.close() ; } catch ( IOException e ) {}       
                }

then you can create a new message, add myObject, and use the XQConstants.CONTENT_TYPE_BYTES.

On the receiving end, it needs to be deserialized from the byte[] type and cast to myObject type:

        ByteArrayInputStream in = null ;
        ObjectInputStream oi = null ;
        try {
            in = new ByteArrayInputStream( (byte[]) this.getObject( a_XQEnvelope ) ) ;
            oi = new ObjectInputStream( in ) ;
            myObject myObj = (myObject) oi.readObject() ;
           
        } catch ( XQMessageException xqme ) {
            log.error( "Exception processing forwarded R2I2 originating request", xqme ) ;
        } catch ( Exception e ) {
            log.error( "Exception processing forwarded R2I2 originating request", e ) ;
        } finally {
            try { if (oi != null) oi.close() ; } catch ( IOException e ) {}       
        }

The ObjectOutputStream and ObjectInputStream objects do need to be deliberately closed in the finally block so that the resources are made available.  The API states this explicitly.

Wrapping this serialization and deserialization into an ObjectUtils class for quick re-use, get can do something really simple in custom services with send and receive to get:

ObjectUtils.toBytes( Object a_object ) and

ObjectUtils.toObject( byte[] a_bytes )