Thanks for your reply!

I've included log output into the client and the bean: it's both Java 1.6 and the same patch level, still I'm getting this exception-

I've tried that with EAP 6.0.1 on command line, for Eclipse I've tried both, EAP 6.0.1 and AS 7.1.1

Originally I've used the jboss-client.jar from 7.1.1, I've updated that now to the one from EAP 6.0.1, there

is no change in behavior.

Please find attached the output of my ant call with "-v -d"

java -version returns:

java version "1.6.0_45"

Java(TM) SE Runtime Environment (build 1.6.0_45-b06)

Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

set JAVA_HOME returns:

JAVA_HOME=C:\jdk1.6.0_45

I've just updated my JDK to patch 45, but that did not change anything

I still have not solved this problem. One thing I found out: when I throw a RuntimeException in the bean's method body

instead of causing an exception in the commit protocol, then the River unmarshaller reports a different exception:

Caused by: java.io.EOFException: Read past end of file

    at org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:126)

    at org.jboss.marshalling.SimpleDataInput.readUnsignedByteDirect(SimpleDataInput.java:263)

    at org.jboss.marshalling.SimpleDataInput.readUnsignedByte(SimpleDataInput.java:224)

    at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:646)

    at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)

    at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)

    at org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments(ProtocolMessageHandler.java:58)

    at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:85)

    at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)

    at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)

    at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)

    at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)

    at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)

    at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)

    at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)

    at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)

    at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)

It works fine from within Eclipse as before.

As a workaround, would it be possible, to configure another marshaller/unmarshaller than the RiverMarshaller?

I'm currently debugging into the RiverUnmarshaller:

InvocationExceptionResponseHandler.MethodInvocationExceptionResultProducer.getResult()

l.82: Object result = unmarshaller.readObject();

In Eclipse as well as on command line, "result" contains the correctly deserialized Exception

l.85 final Map<String, Object> attachments = InvocationExceptionResponseHandler.this.readAttachments(unmarshaller);

In Eclipse, readAttachments() immediately returns, because:

        final int numAttachments = input.readByte();

        if (numAttachments == 0) {

            return null;

        }

the number of attachments is 0.

When run from command line, the number of attachments is 57 - but no bytes follow.

So either the stream is not correctly initialized, or there are 57 attachments missing.

Btw. what information is transmitted as attachments?

In which class and method is the attachment encoded? (In case, I need to debug that as well)

Thank you!

Christian

After some more debugging and analysis, I've filed:

https://issues.jboss.org/browse/WFLY-1456

After I verified the fix for WFLY-1456, which turned out to be a duplicate and was fixed in EAP 6.1, the problem persisted,

but after a lot of debugging I figured out, what caused it:

Oour two environments (Eclipse and command line)

which showed different behavior (worked vs. StreamCorruptedException) had 2 different versions of javax.ejb.EJBException

in the classpath (and the 2 environments ordered the classpath differently)

one of the EJBException classes has a field:

private java.lang.Exception causeException;

the other has no declared fields

After serializing all other fields, JBoss serialized this field (here: 2 bytes) but only

the client with the right EJBException version deserialized everything correctly, the other

one deserialized everything less the 2 bytes. So when "readAttachments" was called, a wrong value

was read, because the position in the bytestream was wrong.