[jira] [Created] (DAEMON-389) JnaPCSCException when using jnasmartcardio
Miguel Febres created DAEMON-389:
Summary: JnaPCSCException when using jnasmartcardio
Key: DAEMON-389
URL: https://issues.apache.org/jira/browse/DAEMON-389
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Environment: MacOS Sierra 10.12.4
Reporter: Miguel Febres
The following code works properly when running the JAR directly in console. The
connection to the smart card reader works fine and the card info is printer on
screen.
{code:java}
public static void main(String[] args) throws CardException, GPException,
NoSuchAlgorithmException {
GlobalPlatform gp;
Card card;
CardTerminal terminal = TerminalManager.getTheReader(null);
card = terminal.connect("*");
card.beginExclusive();
gp = new GlobalPlatform(card.getBasicChannel());
gp.select(null);
byte[] info = gp.getCPLC();
String cardInfo = HexUtils.encodeHexString_imp(info);
card.disconnect(true);
System.out.println("Hexa Card Info: " + cardInfo);
}
{code}
However, when using JSVC to launch the JAR as a daemon, I get a
JnaPCSCException (SCardEstablishContext got response 0x8010001d
(SCARD_E_NO_SERVICE: The Smart card resource manager is not running.)
The full code is:
{code:java}
package com.st.simple.card.client;
import java.security.NoSuchAlgorithmException;
import javax.smartcardio.Card;
import javax.smartcardio.CardException;
import javax.smartcardio.CardTerminal;
import org.apache.commons.daemon.Daemon;
import org.apache.commons.daemon.DaemonContext;
import org.apache.commons.daemon.DaemonInitException;
import apdu4j.HexUtils;
import apdu4j.TerminalManager;
import pro.javacard.gp.GPException;
import pro.javacard.gp.GlobalPlatform;
public class Client implements Daemon {
public static void main(String[] args) throws CardException,
GPException, NoSuchAlgorithmException {
GlobalPlatform gp;
Card card;
CardTerminal terminal = TerminalManager.getTheReader(null);
card = terminal.connect("*");
card.beginExclusive();
gp = new GlobalPlatform(card.getBasicChannel());
gp.select(null);
byte[] info = gp.getCPLC();
String cardInfo = HexUtils.encodeHexString_imp(info);
card.disconnect(true);
System.out.println("Hexa Card Info: " + cardInfo);
}
@Override
public void destroy() {
// TODO Auto-generated method stub
}
@Override
public void init(DaemonContext arg0) throws DaemonInitException,
Exception {
// TODO Auto-generated method stub
}
@Override
public void start() throws Exception {
// TODO Auto-generated method stub
main(null);
}
@Override
public void stop() throws Exception {
// TODO Auto-generated method stub
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CODEC-246) ColognePhoneticTest.testIsEncodeEquals missing assertions
[ https://issues.apache.org/jira/browse/CODEC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492814#comment-16492814 ] Oscar Luis Vera Pérez commented on CODEC-246: - Actually, the test passes because there is no assertion. I took a look at the Cologne Phonetic algorithm and the fix might be to change the first pair by "Mueller" and "M\u00fcller". Then add assertTrue inside the loop for every comparison being made in the test method. > ColognePhoneticTest.testIsEncodeEquals missing assertions > - > > Key: CODEC-246 > URL: https://issues.apache.org/jira/browse/CODEC-246 > Project: Commons Codec > Issue Type: Improvement >Reporter: Oscar Luis Vera Pérez >Priority: Trivial > > The test method ColognePhoneticTest.isEncodeEquals misses an assertion to > properly verify the ColognePhonetic.isEncodeEquals method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-246) ColognePhoneticTest.testIsEncodeEquals missing assertions
[
https://issues.apache.org/jira/browse/CODEC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492786#comment-16492786
]
Gary Gregory commented on CODEC-246:
With SVN trunk, the test {{ColognePhoneticTest}} passes for me. Does it not for
you?
> ColognePhoneticTest.testIsEncodeEquals missing assertions
> -
>
> Key: CODEC-246
> URL: https://issues.apache.org/jira/browse/CODEC-246
> Project: Commons Codec
> Issue Type: Improvement
>Reporter: Oscar Luis Vera Pérez
>Priority: Trivial
>
> The test method ColognePhoneticTest.isEncodeEquals misses an assertion to
> properly verify the ColognePhonetic.isEncodeEquals method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (POOL-338) GenericObjectPool constructor may throw an exception under OSGi
[
https://issues.apache.org/jira/browse/POOL-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael C closed POOL-338.
--
> GenericObjectPool constructor may throw an exception under OSGi
> ---
>
> Key: POOL-338
> URL: https://issues.apache.org/jira/browse/POOL-338
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2, 2.4.3, 2.5.0
> Environment: Java 8, Liferay DXP (an OSGi environment).
>Reporter: Michael C
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.6.0
>
> Attachments: commons-pool-2.5.1.patch, commons-pool-2.6.0.patch,
> commons-pool-gg.patch, commons-pool-mc.patch
>
>
> Version 2.4.3 GenericObjectPool constructor throws this exception:
> {{java.lang.IllegalArgumentException:
> [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement
> EvictionPolicy}}
> {{ at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
>
> Version 2.5.0 throws the same exception. Version 2.4.2 or older's
> setEvictionPolicyClassName method fail silently for the same reason. This
> line in BaseGenericObjectPool evaluates to false for all versions:
> {{ if (policy instanceof EvictionPolicy) {}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (JEXL-259) Shorter ant-ish variables prevent longer ant-ish variables from being resolved properly
[
https://issues.apache.org/jira/browse/JEXL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-259.
--
Resolution: Workaround
Fix Version/s: 3.1
I have worked this out for my case, and I think we can close this issue, as
further improvements to ant-ish variables, if any, could be made under separate
task. For now, may be its worth mentioning somewhere in documentation that such
variables have its limitations in naming
> Shorter ant-ish variables prevent longer ant-ish variables from being
> resolved properly
> ---
>
> Key: JEXL-259
> URL: https://issues.apache.org/jira/browse/JEXL-259
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
> Fix For: 3.1
>
>
> The following script is evaluated successfully
> {code}
> a.b.c = 2; a.b = 1; return a.b
> {code}
> While the following scripts are terminated with error {{unsolvable property
> 'c'}}
> {code}
> a.b = 1; a.b.c = 2; return a.b
> {code}
> {code}
> a.b.c = 2; a.b = 1; return a.b.c
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CODEC-246) ColognePhoneticTest.testIsEncodeEquals missing assertions
[ https://issues.apache.org/jira/browse/CODEC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492570#comment-16492570 ] Oscar Luis Vera Pérez edited comment on CODEC-246 at 5/28/18 11:31 AM: --- I wus trying to make the pull request but I ran into an issue: This test case involves several string pairs. Apparently, it is testing pairs where isEncodeEqual should return true. It is not the case for the very first pair : "Meyer", "M\u00fcller". Is this pair reflecting an existing bug in ColognePhonetic.colognePhonetic method? Is it a wrong pair? Is this the reason why this test has no assertion? was (Author: oscarlvp): This test case involves several string pairs. Apparently, it is testing pairs where isEncodeEqual should return true. It is not the case for the very first pair : "Meyer", "M\u00fcller". Is this pair reflecting an existing bug in ColognePhonetic.colognePhonetic method? Is it a wrong pair? Is this the reason why this test has no assertion? > ColognePhoneticTest.testIsEncodeEquals missing assertions > - > > Key: CODEC-246 > URL: https://issues.apache.org/jira/browse/CODEC-246 > Project: Commons Codec > Issue Type: Improvement >Reporter: Oscar Luis Vera Pérez >Priority: Trivial > > The test method ColognePhoneticTest.isEncodeEquals misses an assertion to > properly verify the ColognePhonetic.isEncodeEquals method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CODEC-246) ColognePhoneticTest.testIsEncodeEquals missing assertions
[ https://issues.apache.org/jira/browse/CODEC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492570#comment-16492570 ] Oscar Luis Vera Pérez edited comment on CODEC-246 at 5/28/18 11:31 AM: --- I was trying to make the pull request but I ran into an issue: This test case involves several string pairs. Apparently, it is testing pairs where isEncodeEqual should return true. It is not the case for the very first pair : "Meyer", "M\u00fcller". Is this pair reflecting an existing bug in ColognePhonetic.colognePhonetic method? Is it a wrong pair? Is this the reason why this test has no assertion? was (Author: oscarlvp): I wus trying to make the pull request but I ran into an issue: This test case involves several string pairs. Apparently, it is testing pairs where isEncodeEqual should return true. It is not the case for the very first pair : "Meyer", "M\u00fcller". Is this pair reflecting an existing bug in ColognePhonetic.colognePhonetic method? Is it a wrong pair? Is this the reason why this test has no assertion? > ColognePhoneticTest.testIsEncodeEquals missing assertions > - > > Key: CODEC-246 > URL: https://issues.apache.org/jira/browse/CODEC-246 > Project: Commons Codec > Issue Type: Improvement >Reporter: Oscar Luis Vera Pérez >Priority: Trivial > > The test method ColognePhoneticTest.isEncodeEquals misses an assertion to > properly verify the ColognePhonetic.isEncodeEquals method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-246) ColognePhoneticTest.testIsEncodeEquals missing assertions
[ https://issues.apache.org/jira/browse/CODEC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492570#comment-16492570 ] Oscar Luis Vera Pérez commented on CODEC-246: - This test case involves several string pairs. Apparently, it is testing pairs where isEncodeEqual should return true. It is not the case for the very first pair : "Meyer", "M\u00fcller". Is this pair reflecting an existing bug in ColognePhonetic.colognePhonetic method? Is it a wrong pair? Is this the reason why this test has no assertion? > ColognePhoneticTest.testIsEncodeEquals missing assertions > - > > Key: CODEC-246 > URL: https://issues.apache.org/jira/browse/CODEC-246 > Project: Commons Codec > Issue Type: Improvement >Reporter: Oscar Luis Vera Pérez >Priority: Trivial > > The test method ColognePhoneticTest.isEncodeEquals misses an assertion to > properly verify the ColognePhonetic.isEncodeEquals method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DBCP-491) Ensure DBCP ConnectionListener can deal with transaction managers which invoke rollback in a separate thread
[ https://issues.apache.org/jira/browse/DBCP-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Feng updated DBCP-491: External issue URL: https://github.com/apache/commons-dbcp/pull/12 External issue ID: 12 > Ensure DBCP ConnectionListener can deal with transaction managers which > invoke rollback in a separate thread > > > Key: DBCP-491 > URL: https://issues.apache.org/jira/browse/DBCP-491 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.3.0 >Reporter: Zheng Feng >Priority: Major > > By using the ManagedDataSource with the [Narayana|http://narayana.io], the > CompletionListener in DBCP is resetting too much of the state of the > connection in afterCompletion when it should be waiting until the connection > is also closed by the user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CSV-227) first column always quoting when multilingual language, when not on second column
Jisun, Shin created CSV-227:
---
Summary: first column always quoting when multilingual language,
when not on second column
Key: CSV-227
URL: https://issues.apache.org/jira/browse/CSV-227
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.5
Reporter: Jisun, Shin
when including multilingual character (utf-8 encoding),
CSVPrinter always quote only first column, not other columns.
{code:java}
// example code
CSVFormat format = CSVFormat.DEFAULT.withQuoteMode(QuoteMode.MINIMAL);
CSVPrinter printer = new CSVPrinter(System.out, format);
List temp = new ArrayList();
temp.add(new String[] { "ㅁㅎㄷㄹ", "ㅁㅎㄷㄹ", "", "test2" });
temp.add(new String[] { "한글3", "hello3", "3한글3", "test3" });
temp.add(new String[] { "", "hello4", "", "test4" });
for (String[] temp1 : temp) {
printer.printRecord(temp1);
}
printer.close();
{code}
result =>
"ㅁㅎㄷㄹ",ㅁㅎㄷㄹ,,test2
"한글3",hello3,3한글3,test3
"",hello4,,test4
i found the code.
multilingual charaters are out of 0x7E. first record and multilinguage always
print quotes.
{code:java}
// CSVFormat.class
...
1173: char c = value.charAt(pos);
1174:
1175: // RFC4180 (https://tools.ietf.org/html/rfc4180) TEXTDATA = %x20-21 /
%x23-2B / %x2D-7E
1176: if (newRecord && (c < 0x20 || c > 0x21 && c < 0x23 || c > 0x2B && c <
0x2D || c > 0x7E)) {
1177: quote = true;
1178: } else if (c <= COMMENT) {
...{code}
would you fix this bug?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1380) FastDateParser too strict on abbreviated short month symbols
[
https://issues.apache.org/jira/browse/LANG-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492329#comment-16492329
]
ASF GitHub Bot commented on LANG-1380:
--
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-lang/pull/331
+1
> FastDateParser too strict on abbreviated short month symbols
>
>
> Key: LANG-1380
> URL: https://issues.apache.org/jira/browse/LANG-1380
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.7
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 3.8
>
> Attachments: LANG-1380.patch
>
>
> The date format symbols of the French locale adds a . (dot) when short month
> names are really abbreviated.
> {code}
> janv.
> févr.
> mars
> avr.
> mai
> juin
> juil.
> août
> sept.
> oct.
> nov.
> déc.
> {code}
> But in real world examples, the dot is frequently omitted.
> FastDateParser should be lenient in the case where the dot isn't there, e.g.
> "14 avr 2014".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #331: LANG-1380: FastDateParser too strict on abbreviated...
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/331 +1 ---
[jira] [Closed] (DAEMON-387) "not a valid win 32 application" after Windows 10 Update
[ https://issues.apache.org/jira/browse/DAEMON-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Molnár closed DAEMON-387. Resolution: Not A Bug Fix Version/s: 1.1.0 I was using an older version. With the latest 1.1 version, it's OK. > "not a valid win 32 application" after Windows 10 Update > > > Key: DAEMON-387 > URL: https://issues.apache.org/jira/browse/DAEMON-387 > Project: Commons Daemon > Issue Type: Bug > Environment: Windows 10 >Reporter: Attila Molnár >Priority: Major > Fix For: 1.1.0 > > > After Windows 10 Update my installed java service with ACD does not start > with "not a valid win 32 application" (error 193). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
