jpos / jpos Goto Github PK

java.lang.NullPointerException
        at org.jpos.q2.qbean.SystemMonitor.lambda$dumpMetrics$0(SystemMonitor.java:271)
        at java.util.HashMap.forEach(HashMap.java:1289)
        at org.jpos.q2.qbean.SystemMonitor.dumpMetrics(SystemMonitor.java:268)
        at org.jpos.q2.qbean.SystemMonitor.dump(SystemMonitor.java:134)
        at org.jpos.util.LogEvent.dump(LogEvent.java:139)
        at org.jpos.util.SimpleLogListener.log(SimpleLogListener.java:51)
        at org.jpos.util.Logger.log(Logger.java:99)
        at org.jpos.util.Log.info(Log.java:81)
        at org.jpos.q2.qbean.SystemMonitor.run(SystemMonitor.java:128)
        at java.lang.Thread.run(Thread.java:748)

how to reproduce?
change <property name="debug" value="true"/> to <property name="debug" value="flase"/> in 30_txnmgr.xml from jpos-gateway.pdf

how to fix?
change <property name="metrics-dir" value="log" /> to <!--<property name="metrics-dir" value="log" />--> in 99_sysmon.xml

Reported by Igor.

We are monitoring ISOServer connections count by calling its getActiveConnections method:

   public int getActiveConnections () {
       return pool.getActiveCount();
   }

We've been getting negative counts, which makes no sense. I think there is a bug in org.jpos.util.ThreadPool causing the inaccurate count. ThreadPool active counter gets decremented inside a synchronized block, but it gets incremented outside a synchronized block:

    if (job instanceof Runnable) {
        setName (name + "-running");
        synchronized (this) {
            currentJob = job;
        }
        try {
            active++;
            ((Runnable) job).run();
            setName (name + "-idle");
        } catch (Throwable t) {
            setName (name + "-idle-"+t.getMessage());
        }
        synchronized (this) {
            currentJob = null;
            available++;
            active--;
        }
    } else {

Java ++ operator is not thread safe. Besides, the synchronized block should not use this as the monitor object, because the attributes being protected from race conditions belong to another class. So, Instead of

synchronized (this) {

it should synchronize on the ThreadPool that owns the counter:

synchronized (ThreadPool.this) {

I'm attaching a simple test case to reproduce the issue.
ThreadPoolTest.zip

https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/Q2.java#L932-L939

The java File.renameTo returns a boolean, and we should use that flag and log the appropriate error if it was renamed or an attempt to rename failed.

Switch participant is described in jPOS programmer's guide section 9.8.1.

Motivation

Switch participant is a highly performant groups selector, but it lacks the ability of handling multiple different but similar entries (e.g. with a common prefix) that should route to the same groups.

I'm writing this issue to have feedback about the best way of implementing this.

I see two options at a first glance:

1. Use some prefix to distinguish between regex properties than common ones, like:

<property name="re:100\.30(\.[0-9]{4})?" value="xxx prepareresponse logit close sendresponse"/>

2. Make Switch implement XMLConfigurable and have something similar to what is done in SelectDestination but just for regexes. e.g.:

<participant class="org.jpos.transaction.participant.Switch"
  logger="Q2" realm="Switch">
  <property name="100.30"
  value="balanceinquiry prepareresponse logit close sendresponse" />
  <regex groups="xxx prepareresponse logit close sendresponse">100\.30\.[0-9]{4}</regex> <!--e.g.: for generic reason code handling-->

In both cases direct properties would have precedence over regex ones, to maintain the efficiency of look up table, if the name is not present as property then we would look iterate over regex in order of definition.

So it behaves efficiently for common transactions but you have the option of leave open cases where there are too many (and infrequent) combinations to list them all one by one, in particular for combinations of function code x reason code.

I'm highly inclined to option 2 but would like better ideas for the syntax.

The byte array initialized with an extra byte is storing an extra 0 in the data when it shouldn't.

Issue seen on the jpos group.
https://groups.google.com/g/jpos-users/c/oAvjQ96tT8w/m/ID8PNl_OBgAJ

Test code

            String origin = "4444445656565655";
            ISOField f = new ISOField(12, origin);
            IFA_LLBNUM packager = new IFA_LLBNUM(16, "Should be blahhhh", false);

            ISOField unpack = new ISOField();
            byte[] x = packager.pack(f);
            System.out.println(ISOUtil.hexdump(x));
            packager.unpack(unpack, packager.pack(f), 0);
            unpack.dump(System.out,"");

Output

0000  31 36 44 44 44 56 56 56  56 55 00                 16DDDVVVVU.

<field id="-1" value="4444445656565655"/>

Is the difference one as a number and the other as a ratio intentional ?

String.format (" in-transit=%d, head=%d, tail=%d, paused=%d, outstanding=%d, active-sessions=%d/%d, %s, elapsed=%dms",
                           getInTransit(), head, tail, pausedCounter.get(), getOutstandingTransactions(),
                           getActiveSessions(), maxSessions,
                           tps.toString(), prof != null ? prof.getElapsedInMillis() : -1
                       )

ps.printf ("%sin-transit=%d/%d, head=%d, tail=%d, paused=%d, outstanding=%d, active-sessions=%d/%d%s%n",
        indent,
        getActiveTransactions(), getInTransit(), head, tail, pausedCounter.get(), getOutstandingTransactions(),
        getActiveSessions(), maxSessions,
        (tps != null ? ", " + tps.toString() : "")
      );

Hello,

I just noticed that there is no IFE_LLLNUM ISOStringFieldPackager, is there a reason for this ? should we implement it ?

Kind regards.

Originally, a VetoException coming from a filter would cause a channel to disconnect.

At some point, we changed the ISOServer behavior to just log the exception without disconnecting (b45ccc4).

In order to be consistent between QServer and ChannelAdaptor, the latter should operate in the same way.

In the future, we may consider adding a disconnect flag to the VetoException.

Hello !

I'm sorry to disturb your time,and I hope you can help me solve some of the problems.

When the number of sub field of a data element is not fixed, I will write all the sub field that may exist, but

it is found that if the number of sub field in this domain and the number of numbers written in the

configuration file are not at the same time, it will throw an exception, and if the length of the sub field

data is inconsistent, there will be an exception.

<isofieldpackager id="61" length="999" name="" class="org.jpos.iso.IFE_LLLCHAR" packager="org.jpos.iso.packager.ISO87BPackager"> <isofield name="" length="1" class="org.jpos.iso.IF_CHAR" id="0"/> <isofield name="" length="1" class="org.jpos.iso.IF_CHAR" id="1"/> <isofield name="" length="5" class="org.jpos.iso.IF_CHAR" id="2"/> </isofieldpackager>

The subfields of the message is not fixed, and there will be up to three subfield. If there are no three sub domains at runtime, an exception will be thrown.

The length of the third subfields is not fixed, and the data length is up to 5. If the message is 3, it will throw an exception.

Best Regards,

org.jpos.iso.ISOException: java.lang.ArrayIndexOutOfBoundsException: 2 (java.lang.ArrayIndexOutOfBoundsException: 2) unpacking field=55, consumed=41

When using TaggedSequencePackager and ISOTaggedField, the dump method produces output such as

<isomsg id="48">
   <!-- org.jpos.tlv.packager.TaggedSequencePackager -->
   <0002><field id="1" value="SUR"/></0002>
   <0003><field id="2" value="SUR"/></0003>
   <0023><field id="3" value="CT6"/></0023>
   <0052><field id="4" value="210"/></0052>
...

This is invalid, badly-formed XML: the tags of type <number> are invalid, and would prevent the XMLPackager and other XML tools from parsing the output of the dump method.

A suggested fix would be to dump them like:

<field id="4" type="tagged" tag="0052" value="210" />

or the type attribute could be "tlv"

NOTE This could be a breaking change for code that expects the old output!
Please comment

org.jpos.rc.CMF defines several error codes used by jPOS systems such as jPOS CMF and jCard that are mostly aligned with ISO-8583 v2003.

jCard and jPTS still don't use this class, it uses jPOS-EE's resultcode module (based on the database tables rc and rc_locale).

As we migrate to this class on source station and destination station implementation, some errors arise:

• 1003 (Card Suspended) should be "Contact acquirer"
• 1004 (Card Stolen - pickup) should be "Restricted Card"
• 1005 (Card Lost) should be "Contact Acquirer Security"
• 1017 (Previously reversed) should be Incorrect PIN
• 1018 (also Previously reversed) should be No card Record

This is a place holder issue to reference commits related to result code changes.

IFEP_LLLBINARY field packager does not support length and description initialization via constructor as in other packagers, in example IFE_LLLEBINARY. To use IFE_LLLBINARY it needs explicit len initialization with a setter call.

Similar to RotateLogListener, it would be nice to have the ability to automatically erase old log files.

Although commit 686be85 solves the problem of unsorted subtags, but it introduces a new problem associated with an infinite loop (100% cpu) when the message contains a new (not yet defined) subtag (then the variable consumed never increases).

Proposed solution (update GenericTaggedFieldsPackager.unpack):

            if (logger != null)  // save a few CPU cycle if no logger available
                evt.addMessage(ISOUtil.hexString(b));

            int consumed = 0;
            TagMap tm = unpackTLV(b);
            for (Tag tag : tm.values()) {
                int i =  tagMapper.getFieldNumberForTag(fieldId, tag.getTagId());
                ISOComponent c = fld[i].createComponent(i);
                byte[] bb = tag.getTLV().getBytes(ISOUtil.CHARSET);
                int unpacked = fld[i].unpack(c, bb, 0);
                consumed = consumed + unpacked;
                m.set(c);
            }
            if (b.length != consumed) {
                evt.addMessage(
                        "WARNING: unpack len=" + b.length + " consumed=" + consumed);
            }
            return consumed;

It require new classes org.jpos.tlv.TagMap, org.jpos.tlv.Tag to handle String encoded TLV data. (Better name suggestions are welcome). They are similar to org.jpos.tlv.TLVList, org.jpos.tlv.TLVMsg but they handle String data not byte arrays and each tag can occur only once.
Example in branch https://github.com/demsey/jPOS/commits/tlvfield commit demsey/jPOS@7d1dbe463

As pointed by this thread in jpos-users mailing list when the transaction manager has set de property debug=false and a paused transactin resumes a NullPointerException is thrown, e.g.:

<log realm="org.jpos.transaction.TransactionManager" at="2018-03-12T17:13:12.916">
  <fatal>
    <exception name="null">
    java.lang.NullPointerException
        at org.jpos.transaction.TransactionManager.run(TransactionManager.java:263)
        at java.lang.Thread.run(Thread.java:745)
    </exception>
  </fatal>
</log>

Sridhar Jena reports (after testing 400 TPS sustained load on the DirPoll):

Whenever a new single file is being placed in request directory, at above DirPoll Line #372 below two functionality are utilizing the more CPU and memory,

It is scanning all the files and getting their names from request directory on each time which is a costly IO operation (Need to handle in batch i,e getting one time the list of file names and use it until all the list iteration didn't get completed, once iteration completed then pick once again the file names from request directory).

FilenameFilter accept method is calling for all the files present in request directory on each time. (If the directory poll file priority is single suppose in my case i am putting only .txt file into /request/ directory , then there won't need to call the FilenameFilter overridden accept() method).

BSHRequestListener is currently returning after the first source is processed no matter the return value.
It should return only if true, and return false after the for ended.

Jmeter with a ISO8583 sampler that uses jpos 2.1.4

I initially logged this at tilln/jmeter-iso8583#24 but seems to be a jpos issue.

java.util.ConcurrentModificationException: null
	at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211) ~[?:1.8.0_152]
	at java.util.TreeMap$KeyIterator.next(TreeMap.java:1265) ~[?:1.8.0_152]
	at org.jpos.iso.ISOMsg.dump(ISOMsg.java:522) ~[jpos-2.1.4.jar:2.1.4]
	at nz.co.breakpoint.jmeter.iso8583.MessagePrinter.asString(MessagePrinter.java:19) ~[jmeter-iso8583-1.1.jar:?]
	at nz.co.breakpoint.jmeter.iso8583.ISO8583Sampler.sample(ISO8583Sampler.java:153) ~[jmeter-iso8583-1.1.jar:?]
	at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:627) ~[ApacheJMeter_core.jar:5.2.1]
	at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:551) ~[ApacheJMeter_core.jar:5.2.1]
	at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:490) [ApacheJMeter_core.jar:5.2.1]
	at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257) [ApacheJMeter_core.jar:5.2.1]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]

I think the ISOServer.fireEvent should have a generic exception handler while iterating through the listeners that could log the exception but not let it bubble up.

In my case the handleISOServerEvent was throwing a NPE, leading to it being caught at https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/iso/ISOServer.java#L532

and then it starts from the outer while loop that tries to create the server socket again leading to a bind exception.

Is there a way how to define an IsoFieldPackager that contains a variable length IsoField? Specifically, I am trying to parse DE35. According to the specs, the first and last fields (Fields 1 and 5, PAN and Discretionary Data) have variable lengths between 15-19 and 1-10. The current configuration I have is the following:

<isofieldpackager id="35"
                      name="TRACK 2 DATA"
                      length="37"
                      class="org.jpos.iso.IFE_LLNUM"
                      emitBitmap="false"
                      pad="true"
                      packager="org.jpos.iso.packager.GenericSubFieldPackager">
        <isofield id="1" length="19" name="PAN" class="org.jpos.iso.IF_CHAR"/>
        <isofield id="2" length="1" name="Separator" class="org.jpos.iso.IF_CHAR"/>
        <isofield id="3" length="4" name="Expiration Data" class="org.jpos.iso.IF_CHAR"/>
        <isofield id="4" length="3" name="Extended Service Code" class="org.jpos.iso.IF_CHAR"/>
        <isofield id="5" length="10" name="Discretionary Data" class="org.jpos.iso.IF_CHAR"/>
    </isofieldpackager>

Parsing fails (or corrupts) if the value of either field 1 or field 5 is smaller than 19 or 10 respectively, as jPOS expects the field to be exactly 19 or 10 characters in length. How can I fix this configuration to handle variable lengths?

Thank you

Galih reports:

hi guys,
it seems like the log time at time exceeded - log rotated and iso msg seems like have a different format time
<?xml version="1.0" encoding="UTF-8"?>
<logger class="org.jpos.util.DailyLogListener">
<log realm="rotate-log-listener" at="Mon Dec 09 00:00:14 WIB 2019">
  maxage feature is disabled.
</log>
<log realm="rotate-log-listener" at="Tue Dec 10 00:00:21 WIB 2019">
  time exceeded - log rotated
</log>
</logger>
~
<log realm="channel/10.100.111.181:7990" at="2019-12-10T09:45:16.937">
 <send>
   <isomsg direction="outgoing">
     <!-- org.jpos.iso.packager.GenericPackager[iso_spec_pce.xml] -->
     <field id="0" value="0800"/>
     <field id="7" value="1210094516"/>
     <field id="11" value="088717"/>
     <field id="70" value="001"/>
   </isomsg>
 </send>
</log>

Alcarraz points out we use this (new Date()) at rotate time:

 protected synchronized void logDebug (String msg) {
        if (p != null) {
            p.println ("<log realm=\"rotate-log-listener\" at=\""+new Date().toString() +"\">");
            p.println ("   "+msg);
            p.println ("</log>");
        }
    }

but

sb.append("" at="");
sb.append(LocalDateTime.ofInstant(dumpedAt, ZoneId.systemDefault()));

on regular events.

We need to use ZoneId at rotate time too.

I am use v2.1.3 to do some TPS benchmark, with around 10 simultanously continuous hit. After several point of time, there's error on client side said: unable to connect, meanwhile the server socket remain listening.

For tags are have PACKED_NUMERIC, PACKED_NUMERIC_DATE_YYMMDD and PACKED_NUMERIC_TIME_HHMMSS formats, the BERTLVPackager unpackValue method is dropping any leading 0.

This is breaking the date and time patterns. Eg: 21530 is not a valid HHMMSS.

What is the reason that this truncation is happening?

User wants to have the ability to stop Q2 from scanning the deploy directory for a while (while multiple files get edited) and then restore the normal behaviour.

This can be done through JMX (calling stop on Q2 and then start) but a more operator-friendly way of doing this is desirable (i.e. special NOSCAN file).

When QFactory initializes a QBean, it checks for possible ConfigurationException and properly remove the QBean from the MBeanServer. But if setConfiguration throws an unchecked exception, the MBean remains registered.

This happens here: https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/QFactory.java#L102-L122

(reported by Kyle Tham)

Hello,

While Unpacking a DE with IFE_LLLCHAR today this exception was thrown

Exception in thread "main" org.jpos.iso.ISOException: org.jpos.iso.IFE_LLLCHAR: Problem unpacking field 61 (java.lang.IndexOutOfBoundsException) unpacking field=61, consumed=241

After some investigating, it turned out that the DE value was signaling that it has a length of a 100 but in reality it was only 26 bytes in length.

Since java.lang.IndexOutOfBoundsException does not tell us much, i think that it would be useful if ISOStringFieldPackager compared how many bytes are still array to how much it is expecting to extract and threw a more comprehensive error message like :

Trying to extract X bytes but the message contains only Y bytes

I will gladly work on this issue if the JPos project accepts PRs.

kind regards.

ditto, the OneShotChannelAdaptor should expose a ready indicator. If a connection is refused, indicator should be removed, and an emergency thread should regularly check the remote host in order to verify it is back online.

My track2 data has been encrypted (like this: 6225551353908773=1903669D5A90717EB7B0).
I try to use isoMsg.pack() to pack the msg.
However,the msg i send out is incorrect but without any exception.

here is part of my code to definate ISOFieldPackager.

/*035*/ new IFB_LLNUM(37, "Track 2 data", false),
/*036*/ new IFB_LLLNUM(104, "Track 3 data", false),

I also tried IFB_LLCHAR and IFB_LLBINARY.
I have no idea about which kind of class should i use.
The jpos version in my code is 2.0.4.

In ISOStringFieldPackager.unpack() unpacked string is created via Literal.uninterpret() method with
new String(rawData, offset, length, ISOUtil.CHARSET), i.e. using ISO_8859_1 charset.

Right after that ISOComponent value is setted via setValue() method and in case if component is ISOMsg the code is following ((String) obj).getBytes(), i.е. with default (UTF-8) encoding.

At this point if data contained any non-ASCII characters it became broken.

I suggest to specify encoding in setValue() method to prevent such behaviour.
I attached simple patch to illustrate the proposed change

When running a Spring Boot app locally that use jPOS 2.1.0 or 2.1.1, I encounter a warning right at the start of the app. It looks like a problem in the MANIFEST.MF file:

Class-Path: lib/jdom2-2.0.6.jar lib/jdbm-1.0.jar lib/je-7.0.6.jar lib/
 commons-cli-1.3.1.jar lib/jline-3.2.0.jar lib/bsh-2.0b6.jar lib/javat
 uples-1.2.jar lib/org.osgi.core-6.0.0.jar lib/bcprov-jdk15on-1.56.jar
  lib/bcpg-jdk15on-1.56.jar lib/sshd-core-1.3.0.jar lib/slf4j-api-1.7.
 22.jar lib/javassist-3.21.0-GA.jar lib/HdrHistogram-2.1.9.jar

Dependency used:

            <dependency>
                <groupId>org.jpos</groupId>
                <artifactId>jpos</artifactId>
                <version>2.1.0</version>
            </dependency>

Warning message:

The Class-Path manifest attribute in
C:\Users\username\.m2\repository\org\jpos\jpos\2.1.0\jpos-2.1.0.jar referenced one or more files that do not exist: 
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/jdom2-2.0.6.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/jdbm-1.0.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/je-7.0.6.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/commons-cli-1.3.1.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/jline-3.2.0.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/bsh-2.0b6.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/javatuples-1.2.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/org.osgi.core-6.0.0.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/bcprov-jdk15on-1.56.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/bcpg-jdk15on-1.56.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/sshd-core-1.3.0.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/slf4j-api-1.7.22.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/javassist-3.21.0-GA.jar,
file:/C:/Users/username/.m2/repository/org/jpos/jpos/2.1.0/lib/HdrHistogram-2.1.9.jar

Issue linked to this one: spring-projects/spring-boot#11057

ditto (issue raised by Alcarraz - thank you!)

I run one program using jpos dependency by maven. I check the path of the maven also even though it is not executing.. while compiling in eclipse it show the error like "A java Exception has occured". What should i do to execute my program???....

ditto

Hello,

I am working with Visa Base I and I encountered a situation where the logger wasn't logging the header component of ISOMsg while sending an ISOMsg with overrided header. Although the header bytes are sent correctly to the endpoint.

FYI, I am using logon manager to send sign on and echo message.

I checked my 10_visa_client_channel.xml configuration

<?xml version="1.0" ?>
<channel-adaptor name='visa-channel' class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
 <channel class="org.jpos.iso.channel.VAPChannel" logger="Q2" realm="visa-channel" packager="org.jpos.iso.packager.GenericPackager" >
  <property name="packager-config" value="jar:packager/base1.xml" />
  <property name="packager-logger" value="Q2" />
  <property name="host" value="@visa_remote_host@"/>
  <property name="port" value="@visa_remote_port@" />
  <property name="timeout" value="300000" />
  <property name="trailer" value="false" />
  <property name="srcid" value="@src_station_id@" />
  <property name="override-header" value="true"/> 
 </channel>  
 <in>visa-send</in>
 <out>visa-receive</out>
 <reconnect-delay>10000</reconnect-delay>
</channel-adaptor>

Found out that VAPChannel.sendMessageHeader doesn't set the header of the ISOMsg. The following trick resolves the issue for me.

protected void sendMessageHeader(ISOMsg m, int len)
        throws IOException {
    ISOHeader h = !isOverrideHeader() && m.getHeader() != null ?
            m.getISOHeader() :
            new BASE1Header(srcid, dstid, headerFormat);
 
    if (h instanceof BASE1Header)
        ((BASE1Header) h).setLen(len);

    //ASK: set the header to the ISOMsg object so it can be logged by Logger
    m.setHeader(h);
    serverOut.write(h.pack());
}

Please let me know if there is anything I am missing in my configuration.

Thanks

@sumeetphadnis reported:

If the TM is re-deployed in a running application, if there are already some paused transactions then the counter goes below zero when they get resumed.

This pausedCounter is info-only, so no other side effect than a wrong counter.

Seems this issue has been introduced after a #315 fix.

We have a list of tags which doesn't belong to a standard EMV tags and have an UnknownTagNumberException in the "2.1.5-20201001" version, while the version "2.1.4" doesn't have a such issue.

protected byte[] packValue(String tagNameHex, final ISOComponent c) throws ISOException,
UnknownTagNumberException {
final int tagNumber = Integer.parseInt(tagNameHex, 16);
final TLVDataFormat dataFormat = getTagFormatMapper().getFormat(tagNumber);
String tagValue;
byte[] packedValue;

    if (c.getComposite() == null) {
        if (c.getValue() instanceof String) {
            tagValue = (String) c.getValue();
            EMVStandardTagType tagType = EMVStandardTagType.forHexCode(tagNameHex);
            int length = Math.max(tagValue.length(), tagType.getDataLength().getMinLength());
            switch (dataFormat) {

obviously custom tag doesn't belong to the EMVStandardTagType and this component throws an exception.

java.util.ConcurrentModificationException
	at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744)
	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742)
	at org.jpos.transaction.Context.dumpMap(Context.java:250)
	at org.jpos.transaction.Context.dump(Context.java:147)
	at org.jpos.util.LogEvent.dump(LogEvent.java:139)
	at org.jpos.util.LogEvent.toString(LogEvent.java:219)
	at org.jpos.util.LogEvent.toString(LogEvent.java:224)
	at org.jpos.util.FrozenLogEvent.<init>(FrozenLogEvent.java:28)
	at org.jpos.transaction.TransactionManager.run(TransactionManager.java:397)
	at java.lang.Thread.run(Thread.java:745)

jPOS-Users discussion

ditto

Probably we don't need both.

When there's a configuration error, Q2 renames the QBean descriptor to .BAD or .DUP and raises a ConfigurationException. In some scenarios, it is desirable to actually exit Q2 (so that the problem can be eagerly detected).

This should be an option (either configuration property or Q2 start-up flag.

Whenever a tag is specified with a length of zero, rather than the tag getting ignored, the implementation is throwing a divide by zero exception.

Looking through the code, I believe that changing lines 259 - 272 from:

if (length > 0) {
    System.arraycopy(b, consumed, value, 0, value.length);
}

int uninterpretLength = getUninterpretLength(length, valueInterpreter);
byte[] rawValueBytes =
        valueInterpreter.uninterpret(value, 0, uninterpretLength);

tlvSubFieldData = unpackValue(tag, rawValueBytes, subFieldNumber, length);


consumed = consumed + length;
ISOTaggedField tlv = new ISOTaggedField(tag, tlvSubFieldData);
m.set(tlv);

to:

if (length > 0) {
    System.arraycopy(b, consumed, value, 0, value.length);


    int uninterpretLength = getUninterpretLength(length, valueInterpreter);
    byte[] rawValueBytes =
            valueInterpreter.uninterpret(value, 0, uninterpretLength);

    tlvSubFieldData = unpackValue(tag, rawValueBytes, subFieldNumber, length);


    consumed = consumed + length;
    ISOTaggedField tlv = new ISOTaggedField(tag, tlvSubFieldData);
    m.set(tlv);
}

should solve the issue.

The problem here is that both getUninterpretLength() and unpackValue() will fail with this exception, however, there's no need to call them if the data length is indeed zero.

FSDMsg copy doesn't support a default value in case the source object doesn't contain the field.

In 686756e we made a change that breaks classloading from Wildfly 10.

In jpos-users Rama mentions that this change fixes the problem:

public Q2 (String[] args, BundleContext bundleContext) {
        super();
        this.args = args;
        startTime = System.currentTimeMillis();
        instanceId = UUID.randomUUID();
        parseCmdLine (args);
        libDir     = new File (deployDir, "lib");
        dirMap     = new TreeMap ();
        deployDir.mkdirs ();

---     mainClassLoader = getClass().getClassLoader();
+++   mainClassLoader = Thread.currentThread().getContextClassLoader();

        this.bundleContext = bundleContext;
    }

We'll consider using one or the other one depending on bundleContext being null.

This needs some deep review.

EMVTagSequence is unable to parse non standart EMV tags

Nested:org.jpos.emv.UnknownTagNumberException: 57092
at org.jpos.emv.EMVStandardTagType.forCode(EMVStandardTagType.java:614)
at org.jpos.emv.EMVStandardTagType.forHexCode(EMVStandardTagType.java:620)
at org.jpos.emv.EMVTagSequence.createLiteralTagValuePair(EMVTagSequence.java:45)
at org.jpos.emv.EMVTagSequence.createLiteralTagValuePair(EMVTagSequence.java:27)
at org.jpos.tlv.TagSequenceBase.readFrom(TagSequenceBase.java:181)
at org.jpos.tlv.TagSequenceBase.readFrom(TagSequenceBase.java:174)
at org.jpos.tlv.packager.bertlv.BERTLVPackagerTest.decode(BERTLVPackagerTest.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:206)
at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:131)
at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:65)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:129)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:127)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:126)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:84)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:143)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:129)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:127)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:126)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:84)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:143)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:129)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:127)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:126)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:84)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)

It is quite easy to stop the system by using DefaultTimer.schedule(). The TimerTask passed there cannot throw any exceptions or errors (e.g. SpaceError).
It is documented in Timer javadoc

If the timer's task execution thread terminates unexpectedly, for example, because its stop method is invoked, any further attempt to schedule a task on the timer will result in an IllegalStateException, as if the timer's cancel method had been invoked.

As example the JDMBSpace implement TimerTasks

    public void run () {
        try {
            gc();
        } catch (Exception e) {
            e.printStackTrace(); // this should never happen
        }
    }

but at the end of the gc() method we have ... SpaceError

    public void gc () {
        final String GCKEY = "GC$" + Integer.toString (hashCode());
        final long TIMEOUT = 24 * 3600 * 1000;
        Object obj;
        try {
            synchronized (this) {
                ...
            }

            ...
        } catch (IOException e) {
            throw new SpaceError (e);
        }
    }

To force this error for JDBMSpace, just change the name (in operation) of the directory where space is saved.

This type of error often appears and causes the DefaultTimer singleton to stop working.

I think that the passed TimerTask should be protected against such a situation. You would have to add a wrapper to TimerTask with error handling with e.printStackTrace() logging;

On the other hand, SpaceError itself doesn't seem like a good idea to me. See PMD DoNotExtendJavaLangError and Error javadoc

is also a subclass of Error because most applications should not try to catch it.

and should be converted to unchecked eg. SpaceException.

Could anyone guide me how to configure client server simulator in jPOS.
our requirement is to simulate a ATM transaction message and then we need to parse it using ISO message parser.
Thanks in advance
Arun Balaji NM

SimpleConfigurationTest.testReadEnvironmentVariable test fails on MS Windows Environments, due to MS Windows Systems not having a "HOME" env varible which is used in this test.

There's a protection against shutting down Q2 when logged via SSH.
That protection gives a false positive when using --command and prevents shutdown.

When using TaggedSequencePackager and ISOTaggedField, the dump method produces output such as