jPOS Users Google Group

Re: problem unpaking field 2

2008-05-16T12:37:14Z

Prem wrote:
This seems unlikely, are you certain all of you classes match across the
environments?
Is this a hexdump of the binary raw data data, or is it ASCII character?
As 'FINAL_PACKET' and 'RAW_PACKET' seem to match perhaps it is an
ASCII message.
The length of your field 2 is being extracted as a negative value.

problem unpaking field 2

2008-05-16T10:01:52Z

Hi ,
Any one can help me,'

My same pakager and listener is working fine with jpos
but when I am using with JPOSEE, I am getting the below error.

[java] <log realm="simulator_10000.server. channel/127.0.0.1:1824"
at="Fri M
16 15:23:06 PDT 2008.656">
[java] <receive>
[java] <HEADER>

Re: Unpacking error on special character

2008-05-15T15:26:48Z

Thanks for all suggestions. It works now. We implement the
getMessageLength() and getMessageTrailler() methods in our channel
class (which extends the Basechannel class). This works for the
session handshake message and we'll check to see if it also works for
key exchange messages.

Thanks a lot,

Re: Cascading transaction managers

2008-05-15T10:50:12Z

thanks Alejandro,
still have a problem though with : call resume on the context
i am using the Context implementation from the jpos guide and i do not think
it implements a resume method,
is there an implementation somewhere.
secondly if the second TM aborts in one of the participants, does this
bubble all the way?

Re: Cascading transaction managers

2008-05-15T10:20:19Z

Forwarding to a second transaction manager is as simple as calling its
queue method and passing it a Context (can be the same context as the
original one).
After doing so, you can return PAUSE. Once done on your second
transaction manager, you can call resume() on the context.
I don't think a recover could work on such a setup, you may want to set

Re: Unpacking error on special character

2008-05-15T08:21:03Z

I think this unpacking exception is down to a mismatch between message
and packager. The end sentinel will not cause this exception on it's own.
Can you share a hexdump of the raw message received? As your message is
so small it won't take long to match everything up and hopefully see the
issue.
As you have no variable length fields defined, I suspect the bitmap

Cascading transaction managers

2008-05-15T08:03:47Z

is there a sample anywhere where one transaction manager hands over to
another transactionmanager and continues after the second
transactionmanager has finshed processing

RE: Unpacking error on special character

2008-05-14T21:42:01Z

Do you need to override getMessageLength() - since you are including the
last byte as a part of your ISOMSG() ?
--DAve
[link]
the
org.jpos.iso.ISOBasePackager.u npack(ISOBasePackager.java:235 )
org.jpos.iso.ISOBasePackager.u npack(ISOBasePackager.java:235 )

Re: Unpacking error on special character

2008-05-14T21:36:30Z

Nope. It prints out "31" in hex - which is the one byte before the
trailer.

Re: Unpacking error on special character

2008-05-14T21:02:51Z

Do you get to see a "The trailer is: 03" in that println?

Re: Unpacking error on special character

2008-05-14T21:02:42Z

Thanks for your suggestion. I have an IMNChannel class which extends
the BaseChannel class. So I implement the following code into the
IMNChannel class. But I still get the same error. Can you please
help?

protected void getMessageTrailler() throws IOException {
byte[] b = new byte[1];

Re: Unpacking error on special character

2008-05-14T20:19:22Z

That's not part of the ISO-8583 and must be handled as a trailer y your
ISOChannel interface (see BaseChannel's sendMessageTrailler() and
getMessageTrailler())

Unpacking error on special character

2008-05-14T19:59:36Z

Hi,

We have an incoming message from the Host which ends up with a special
character ? which has a value of 03 in hex network log (we took the
log using Ethereal). We try to unpack the message using the
ISOFiedldPackager and getting an exception.

This is the exception:
error unpacking field 70

Re: problem starting Transaction Manager

2008-05-13T06:06:37Z

Thanks,
It worked afeter changing Package name to
org.jpos.transaction.Transacti onManager

-- vijayp

Re: watching for connection events

2008-05-12T20:05:06Z

I believe you need to hook to the server first, then hook to the channel
once each connection gets accepted.
The good news is that the ISOServer is an Observable too and it notifies
its observers once a new channel is created. The parameter is actually
the newly created channel.