[GitHub] commons-lang issue #194: add isAllBlank,isNotAllBlank method for String "nul...
Github user wangdongxun commented on the issue: https://github.com/apache/commons-lang/pull/194 Thank you for your reply @kinow @PascalSchumacher @britter I feel very honore to receive your reply. I completely agree with @PascalSchumacher . You are right! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (WEAVER-4) org.apache.commons.weaver.privilizer.example.UsingBlueprintsTest#testMoreGetTopStackElementClassName() fails on IBM JDKs
[ https://issues.apache.org/jira/browse/WEAVER-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson closed WEAVER-4. > org.apache.commons.weaver.privilizer.example.UsingBlueprintsTest#testMoreGetTopStackElementClassName() > fails on IBM JDKs > > > Key: WEAVER-4 > URL: https://issues.apache.org/jira/browse/WEAVER-4 > Project: Commons Weaver > Issue Type: Improvement > Components: privilizer >Affects Versions: 1.0 >Reporter: Matt Benson >Assignee: Matt Benson > Fix For: 1.1 > > > discovered by Jorg Schaible: > org.apache.commons.weaver.privilizer.example.UsingBlueprintsTest#testMoreGetTopStackElementClassName() > fails on IBM JDKs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WEAVER-2) Upgrade to ASM 5
[ https://issues.apache.org/jira/browse/WEAVER-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson closed WEAVER-2. > Upgrade to ASM 5 > > > Key: WEAVER-2 > URL: https://issues.apache.org/jira/browse/WEAVER-2 > Project: Commons Weaver > Issue Type: Task > Components: normalizer, privilizer >Affects Versions: 1.0 >Reporter: Matt Benson >Assignee: Matt Benson > Fix For: 1.1 > > > For Java 8 support and general up-to-date-ness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WEAVER-3) Upgrade to latest xbean-finder (3.18)
[ https://issues.apache.org/jira/browse/WEAVER-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson closed WEAVER-3. > Upgrade to latest xbean-finder (3.18) > - > > Key: WEAVER-3 > URL: https://issues.apache.org/jira/browse/WEAVER-3 > Project: Commons Weaver > Issue Type: Task > Components: core >Affects Versions: 1.0 >Reporter: Matt Benson >Assignee: Matt Benson > Fix For: 1.1 > > > Necessary for Java 8 support (by using ASM 5 for scanning); also latest > xbean-finder exposes additional metadata that we can use to avoid putting the > finder into a mode where it has problems with dependency classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WEAVER-1) Enhance [weaver] documentation
[ https://issues.apache.org/jira/browse/WEAVER-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson closed WEAVER-1. > Enhance [weaver] documentation > -- > > Key: WEAVER-1 > URL: https://issues.apache.org/jira/browse/WEAVER-1 > Project: Commons Weaver > Issue Type: Improvement > Components: site >Affects Versions: 1.0 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: documentation > Fix For: 1.1 > > Attachments: WEAVER-1.patch, weaver.png, weaver.svg > > > Enhance the documentation of [weaver] component. We can maybe add a user's > guide, a 5 minute introduction, images or re-format the existing > documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CSV-196) Store the info of whether a field is enclosed by quotes
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566230#comment-15566230 ] Matt Sun edited comment on CSV-196 at 10/11/16 6:40 PM: Add to what I just said, the CSV parser already takes care of spaces (if any). So if we format the parser not to remove leading and trailing spaces during parser initialization, we will get info of the original data. Whether or not the field was encapsulated is the only missing info. was (Author: mattsun): Add to what I just said, the CSV parser also takes care of spaces (if any). So if we format the parser not to remove leading and trailing spaces during initialization, we will get info of the original data. Whether or not the field was encapsulated is the only missing info. > Store the info of whether a field is enclosed by quotes > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: easyfix, features, patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-196) Store the info of whether a field is enclosed by quotes
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566230#comment-15566230 ] Matt Sun commented on CSV-196: -- Add to what I just said, the CSV parser also takes care of spaces (if any). So if we format the parser not to remove leading and trailing spaces during initialization, we will get info of the original data. Whether or not the field was encapsulated is the only missing info. > Store the info of whether a field is enclosed by quotes > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: easyfix, features, patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-196) Store the info of whether a field is enclosed by quotes
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566209#comment-15566209 ] Matt Sun commented on CSV-196: -- You're right, parser reads characters. But as downstream users, they can count bytes by characters read. As I said, as a integration with Hadoop API, we want to know the original data read by the parser. What I asked is not having parsing to count the bytes, but only to set a flag indicating whether the field was enclosed by quotes. > Store the info of whether a field is enclosed by quotes > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: easyfix, features, patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IMAGING-190) ImageDataReader.decompress() overwrites its input
[ https://issues.apache.org/jira/browse/IMAGING-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IMAGING-190. -- Resolution: Fixed Fix Version/s: 1.0 URL: http://svn.apache.org/viewvc?rev=1764288=rev Log: IMAGING-190 ImageDataReader.decompress() overwrites its input Modified: commons/proper/imaging/trunk/src/changes/changes.xml commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/tiff/datareaders/ImageDataReader.java > ImageDataReader.decompress() overwrites its input > - > > Key: IMAGING-190 > URL: https://issues.apache.org/jira/browse/IMAGING-190 > Project: Commons Imaging > Issue Type: Bug >Reporter: Sebb > Fix For: 1.0 > > > The ImageDataReader.decompress() method rewrites its input data if the fill > order is set to FILL_ORDER_VALUE_REVERSED. > However AFAICT the fill order is not then updated, so calling the method > mulitple times will redo the conversion. > The method should probably use a new array if the output has to be reversed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OGNL-256) OGNL 3.0.19 (and many previous) do not work with SecurityManager Enabled
[ https://issues.apache.org/jira/browse/OGNL-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564596#comment-15564596 ] Lukasz Lenart commented on OGNL-256: Also reported [here|https://github.com/jkuhnert/ognl/issues/31] > OGNL 3.0.19 (and many previous) do not work with SecurityManager Enabled > > > Key: OGNL-256 > URL: https://issues.apache.org/jira/browse/OGNL-256 > Project: Commons OGNL > Issue Type: Bug > Components: Core Runtime >Affects Versions: 3.0.13 >Reporter: Michael Smith > > When using SecurityManager, we get the following error. > java.lang.IllegalAccessException: Method [public java.lang.String > com.opensymphony.xwork2.ActionSupport.execute() throws java.lang.Exception] > cannot be accessed. > We used profilingSecurityManager to generate our policy file.. (but there > could be issues).. > Do you have a suitable example policy file for ognl that could be used.. we > dont want to have to set the OgnlRunTime.securityManger(null) hack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
