[jira] [Commented] (DAEMON-234) Allow the same jsvc binary executable to work with either libcap.so.1 or libcap.so.2 at runtime
[
https://issues.apache.org/jira/browse/DAEMON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208065#comment-13208065
]
Mladen Turk commented on DAEMON-234:
Hmm, not sure why the provided configure doesn't work for you.
... and for version yes, I noticed that file didn't get updated afer
we made release.
So, yes, please open a new JIRA. The configure issue is really interesting.
I was using RHEL4 for generating them so it can work with older systems, so
this might be the reason.
> Allow the same jsvc binary executable to work with either libcap.so.1 or
> libcap.so.2 at runtime
> ---
>
> Key: DAEMON-234
> URL: https://issues.apache.org/jira/browse/DAEMON-234
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Jsvc
>Affects Versions: 1.0.8
>Reporter: Phil Clay
> Fix For: 1.0.9
>
>
> From a recent mail thread on the commons user list...
> http://markmail.org/message/uvkfqd7nkqyhq5eg
> I would like to be able to use jsvc on both debian and redhat machines.
> Ideally, I'd like to be able to compile jsvc once, and use the same binary on
> both platforms.
> The problem I am encountering is that the version of libcap varies across
> machines.
> For example, if I compile jsvc on a RHEL 5.4 machine (which has libcap.so.1),
> and then attempt to run the same binary on a Debian 6 machine (which has
> libcap.so.2), then the execution fails with:
> jsvc: error while loading shared libraries: libcap.so.1: cannot open shared
> object file: No such file or directory
> In order to create a single jsvc executable that works whether or not
> libcap.so.1 or libcap.so.2 is available at runtime, the jsvc code should use
> dlopen("libcap.so") and then dlsym all API's instead linking.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-209) SharedPoolDataSource does not handle null keys correctly
[ https://issues.apache.org/jira/browse/POOL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207997#comment-13207997 ] Mark Thomas commented on POOL-209: -- I have been reviewing the 1.5.4 and 1.5.x pool code against the 3 issues identified above: 1.) Creating new object for latch is not synchronized, so there is a probability that other thread overrides the latch pair (GenericKeyedObjectPool:1177) 2.) Allocate() method does not care if the latch pair is already assigned in 1.) (~1245). 3.) I guess latch accesses should be synchronized to avoid latch changes between lines. re 3: I intend to ignore as per my previous comments until such time as it is substantiated with an explanation of how a problem may occur. re 1: I disagree with the analysis. Setting mayCreate on the latch is performed inside a sync block on the keyed pool. At the same time as mayCreate is set, the latch is removed from the allocation queue. Therefore, another thread cannot provide an object for that latch. Object creation is performed in the borrowObject() method and the latch is a local variable and is therefore only visible to a single thread. I do not see a sequence of events that could result in two threads creating an object for the same latch. re 2: Same argument as 1. All the latch getters and setters are synchronized therefore any attempt to read latch attributes will see the latest values even if the write and read are in separate threads. So far there have been several explanations of how this issue may occur but, as yet, none of them have stood up to scrutiny (assuming my analysis is correct - not always a valid assumption). I wouldn't be surprised if there was a pool bug here somewhere - the code is somewhat complex - but I'm going to need either a test case that demonstrates the issue or an explanation of how the problem occurs before I start changing any code. There have been a few fixes (although none that look relevant to this issue) since 1.5.4 so it would be good to update to the latest 1.5.x (or 1.6.x if you want generics) and repeat the tests. > SharedPoolDataSource does not handle null keys correctly > > > Key: POOL-209 > URL: https://issues.apache.org/jira/browse/POOL-209 > Project: Commons Pool > Issue Type: Bug > Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, > jTDS 1.2.5) >Reporter: Gabor Horvath > Attachments: GenericKeyedObjectPool.java > > > GenericKeyedObjectPool.borrowObject does not invalidate object if > validateObject fails (line ~1200). I guess invalidation would be needed for > objects which are not newly created (newlyCreated flag in the code). > Scenario: > 1.) DB connection put into pool > 2.) Attempt to reuse connection (borrowObject) > 3.) Test on borrow (executing simple SQL query) fails: DB connection closed > on jTDS level but connection remains in the pool > 4.) Subsequent attempts to reuse the connection causes > "java.sql.SQLException: Invalid state, the Connection object is closed" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207985#comment-13207985
]
Simone Tripodi commented on CHAIN-58:
-
it makes a lot of sense, thanks for the hint!
> Update Chain Context interface to use K,V generics
> --
>
> Key: CHAIN-58
> URL: https://issues.apache.org/jira/browse/CHAIN-58
> Project: Commons Chain
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Elijah Zupancic
>Assignee: Simone Tripodi
> Fix For: 2.0
>
> Attachments: CHAIN-58-working-context-generics.patch,
> chain-58-improved-context-generic.diff, chain-58-with-context-generic.diff,
> chain-58.diff
>
>
> As discussed in the mailing list, I am suggesting that we change the
> definition of Context from:
> {noformat}
> public interface Context extends Map {
> {noformat}
> to:
> {noformat}
> public interface Context extends Map {
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-209) SharedPoolDataSource does not handle null keys correctly
[ https://issues.apache.org/jira/browse/POOL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207977#comment-13207977 ] Mark Thomas commented on POOL-209: -- If you see this issue, please also provide details of the version of commons pool that you are using. > SharedPoolDataSource does not handle null keys correctly > > > Key: POOL-209 > URL: https://issues.apache.org/jira/browse/POOL-209 > Project: Commons Pool > Issue Type: Bug > Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, > jTDS 1.2.5) >Reporter: Gabor Horvath > Attachments: GenericKeyedObjectPool.java > > > GenericKeyedObjectPool.borrowObject does not invalidate object if > validateObject fails (line ~1200). I guess invalidation would be needed for > objects which are not newly created (newlyCreated flag in the code). > Scenario: > 1.) DB connection put into pool > 2.) Attempt to reuse connection (borrowObject) > 3.) Test on borrow (executing simple SQL query) fails: DB connection closed > on jTDS level but connection remains in the pool > 4.) Subsequent attempts to reuse the connection causes > "java.sql.SQLException: Invalid state, the Connection object is closed" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-234) Allow the same jsvc binary executable to work with either libcap.so.1 or libcap.so.2 at runtime
[
https://issues.apache.org/jira/browse/DAEMON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207955#comment-13207955
]
Phil Clay commented on DAEMON-234:
--
Hey Mladen,
I downloaded commons-daemon-1.0.9-native-src.tar.gz, extracted it, then ran
./configure
make
...on a rhel5.4 machine (which has libcap.so.1), and ran jsvc on a debian 6
machine (which has libcap.so.2), and still received the same error. :(
I noticed that the configure file needs to be regenerated for the source
distribution.
After regenerating configure using autoconf, then running
./configure
make
The produced binary works on both platforms.
(Also, as a side note, I noticed that jsvc -help shows the version as 1.0.8
instead of 1.0.9. I think version.h needs updating.)
Not sure how you want to handle this. New bug?
> Allow the same jsvc binary executable to work with either libcap.so.1 or
> libcap.so.2 at runtime
> ---
>
> Key: DAEMON-234
> URL: https://issues.apache.org/jira/browse/DAEMON-234
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Jsvc
>Affects Versions: 1.0.8
>Reporter: Phil Clay
> Fix For: 1.0.9
>
>
> From a recent mail thread on the commons user list...
> http://markmail.org/message/uvkfqd7nkqyhq5eg
> I would like to be able to use jsvc on both debian and redhat machines.
> Ideally, I'd like to be able to compile jsvc once, and use the same binary on
> both platforms.
> The problem I am encountering is that the version of libcap varies across
> machines.
> For example, if I compile jsvc on a RHEL 5.4 machine (which has libcap.so.1),
> and then attempt to run the same binary on a Debian 6 machine (which has
> libcap.so.2), then the execution fails with:
> jsvc: error while loading shared libraries: libcap.so.1: cannot open shared
> object file: No such file or directory
> In order to create a single jsvc executable that works whether or not
> libcap.so.1 or libcap.so.2 is available at runtime, the jsvc code should use
> dlopen("libcap.so") and then dlsym all API's instead linking.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-161) ContextClassLoader problems for the Evictor thread
[ https://issues.apache.org/jira/browse/POOL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-161. -- Resolution: Fixed Fix ported to 1.5.x and 2.x > ContextClassLoader problems for the Evictor thread > -- > > Key: POOL-161 > URL: https://issues.apache.org/jira/browse/POOL-161 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Sylvain Laurent > Fix For: 1.6.1, 2.0, 1.5.8 > > Attachments: TestGenericObjectPoolClassLoader.patch.txt, > patch_Evictor_CCL.txt > > > Since a single Timer is used for several GenericObjectPool instances, this > may create classloader issues and a memory leak of one classloader : > Let's imagine the following scenario : > - commons-pool.jar is in the classpath of a webapp container (e.g. tomcat). > - 2 webapps A and B are deployed, each creating an instance of > GenericObjectPool for its own usage. > - each webapp makes use of the idle object evictor and sets a positive number > for minIdle > - first, webapp A instantiates its GenericObjectPool. Since this is the first > TimerTask to be created, the Timer instance is created, thus creating a > Thread whose ContextClassLoader is the current one, that is webapp A's > ContextClassLoader. > The TimerTask properly creates instances of idle objects in the pool, making > use of the ObjectFactory provided by A. > - then B instantiates its GenericObjectPool. A new TimerTask is created, and > it tries to invoke the ObjectFactory provided by B. But when it needs a class > that only exists in B webapp, it cannot find it because the > ContextClassLoader of the Timer Thread is A's classloader. > Other side effect : if webapp A is undeployed, but B is still running, then > A's webappClassLoader cannot be GCed because the Timer Thread keeps a strong > reference to A's classloader (as its context classloader). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-203) GenericKeyedObjectPool.ObjectDeque could be better encapsulated
[ https://issues.apache.org/jira/browse/POOL-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-203. -- Resolution: Won't Fix > GenericKeyedObjectPool.ObjectDeque could be better encapsulated > --- > > Key: POOL-203 > URL: https://issues.apache.org/jira/browse/POOL-203 > Project: Commons Pool > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > GenericKeyedObjectPool.ObjectDeque is currently basically just a collection > of Objects with getters. > This necessarily exposes the implementation, and makes adding invariant > checks a lot harder - e.g. ensuring createCount >=0. > The suggestion is to replace the getters with functional methods, for example: > objectDeque.getCreateCount().incrementAndGet() => objectDeque.createdEntry(); > objectDeque.getAllObjects().put(t, p); => objectDeque.addNew(t, p); > objectDeque.getIdleObjects().addFirst(p)/addLast(p) => > objectDeque.idle(p,getLifo()) > The new methods could include assertions for invariants, and adding debug > would be a doddle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-444) Change base package name
[ https://issues.apache.org/jira/browse/MATH-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207809#comment-13207809 ] Gilles commented on MATH-444: - Change performed in revision 1244107. > Change base package name > > > Key: MATH-444 > URL: https://issues.apache.org/jira/browse/MATH-444 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Priority: Trivial > Fix For: 3.0 > > > "org.apache.commons.math" to become "org.apache.commons.math3" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-300) FileUtils.moveDirectoryToDirectory removing source directory
[
https://issues.apache.org/jira/browse/IO-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilina Dampahala updated IO-300:
-
Attachment: IO-300.patch
With this patch, you can move the directory to any directory, even to a
directory which exists inside the source directory.
Patch Logic:
1. If the source directory lies on the destination directory, a temporary
source directory will be created (inside the system temporary folder).
2. Deletes original source directory.
3. Move from temporary source directory to the destination directory as per the
usual way.
> FileUtils.moveDirectoryToDirectory removing source directory
>
>
> Key: IO-300
> URL: https://issues.apache.org/jira/browse/IO-300
> Project: Commons IO
> Issue Type: Bug
>Reporter: dennis lucero
> Attachments: IO-300.patch
>
>
> Since moveDirectoryToDirectory performs a copy then delete, if you specify a
> target directory that is a subdirectory of the source, everything under the
> source directory is deleted.
> Steps to recreate:
> File dest = new File("/tmp/dir1/dir2");
> File src = new File("/tmp/dir1/");
> dest.mkdirs();
> System.out.println(src.exists());
> FileUtils.moveDirectoryToDirectory(src, dest, false);
> System.out.println(src.exists());
> Output:
> true
> false
> If you try the same thing with a move command on Linux, you receive: "mv:
> cannot move `dir1/' to a subdirectory of itself, `dir1/dir2/dir1'"
> Maybe throw an exception if
> dest.getCanonicalPath().startsWith(src.getCanonicalPath())
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207761#comment-13207761
]
Sebb commented on CHAIN-58:
---
I recommend leaving the package rename until last, as that makes it easier to
generate reports that highlight the changes.
> Update Chain Context interface to use K,V generics
> --
>
> Key: CHAIN-58
> URL: https://issues.apache.org/jira/browse/CHAIN-58
> Project: Commons Chain
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Elijah Zupancic
>Assignee: Simone Tripodi
> Fix For: 2.0
>
> Attachments: CHAIN-58-working-context-generics.patch,
> chain-58-improved-context-generic.diff, chain-58-with-context-generic.diff,
> chain-58.diff
>
>
> As discussed in the mailing list, I am suggesting that we change the
> definition of Context from:
> {noformat}
> public interface Context extends Map {
> {noformat}
> to:
> {noformat}
> public interface Context extends Map {
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-65) Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 of chain
[ https://issues.apache.org/jira/browse/CHAIN-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elijah Zupancic updated CHAIN-65: - Attachment: CHAIN-65.patch Patch for package rename. > Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 > of chain > > > Key: CHAIN-65 > URL: https://issues.apache.org/jira/browse/CHAIN-65 > Project: Commons Chain > Issue Type: Task >Affects Versions: 2.0 >Reporter: Elijah Zupancic > Fix For: 2.0 > > Attachments: CHAIN-65.patch > > > Since we are breaking binary compatibility in chain 2.0, we will rename the > package so that users of the 1.0 libraries are not adversely affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CHAIN-65) Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 of chain
Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 of chain Key: CHAIN-65 URL: https://issues.apache.org/jira/browse/CHAIN-65 Project: Commons Chain Issue Type: Task Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 Since we are breaking binary compatibility in chain 2.0, we will rename the package so that users of the 1.0 libraries are not adversely affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207749#comment-13207749
]
Elijah Zupancic commented on CHAIN-58:
--
Hi Simo,
I will use your above comments as a checklist. The first thing that I will do
is rename the package, since it looks like we broke binary compatibility.
-Elijah
> Update Chain Context interface to use K,V generics
> --
>
> Key: CHAIN-58
> URL: https://issues.apache.org/jira/browse/CHAIN-58
> Project: Commons Chain
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Elijah Zupancic
>Assignee: Simone Tripodi
> Fix For: 2.0
>
> Attachments: CHAIN-58-working-context-generics.patch,
> chain-58-improved-context-generic.diff, chain-58-with-context-generic.diff,
> chain-58.diff
>
>
> As discussed in the mailing list, I am suggesting that we change the
> definition of Context from:
> {noformat}
> public interface Context extends Map {
> {noformat}
> to:
> {noformat}
> public interface Context extends Map {
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-744. - Resolution: Fixed Fix Version/s: 3.0 Fix committed in revision 1243912. Added unit tests. > BigFraction.doubleValue() returns Double.NaN for large numerators or > denominators > - > > Key: MATH-744 > URL: https://issues.apache.org/jira/browse/MATH-744 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Thundre > Fix For: 3.0 > > Attachments: src.patch > > > The current implementation of doubleValue() divides numerator.doubleValue() / > denominator.doubleValue(). BigInteger.doubleValue() fails for any number > greater than Double.MAX_VALUE. So if the user has 308-digit numerator or > denominator, the resulting quotient fails, even in cases where the result > would be well inside Double's range. > I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-449) Storeless covariance
[
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-449:
Fix Version/s: (was: 3.1)
3.0
Waiting for an imminent patch by Patrick Meyer.
> Storeless covariance
>
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.0
>
> Attachments: MATH-449.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance.
> However, Pebay (2008) describes algorithms for on-line covariance
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have
> provided a simple class for implementing this algorithm. It would be nice to
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> //This code is granted for inclusion in the Apache Commons under the terms of
> the ASL.
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
> this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
>
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DIGESTER-162) ObjectCreateRule doesn't allow create objects wich type are specified in attributeName only
ObjectCreateRule doesn't allow create objects wich type are specified in
attributeName only
---
Key: DIGESTER-162
URL: https://issues.apache.org/jira/browse/DIGESTER-162
Project: Commons Digester
Issue Type: Bug
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Current {{ObjectCreateRule}} implementation doesn't allow create objects wich
type are specified in {{attributeName}} only.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-302) ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without BOM multiple times
[
https://issues.apache.org/jira/browse/IO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Steuerwald updated IO-302:
--
Attachment: testfileNoBOM.xml
testfileBOM.xml
> ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without
> BOM multiple times
> ---
>
> Key: IO-302
> URL: https://issues.apache.org/jira/browse/IO-302
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.1
> Environment: Win7 64bit, Java 6 32bit
>Reporter: Jan Steuerwald
> Attachments: Test.java, testfileBOM.xml, testfileNoBOM.xml
>
>
> Resetting the BOMInputStream doesn't reset the _fbLength_ member variable.
> This causes _fbLength_ to grow bigger than the _firstBytes_ array (when the
> file doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException
> in the _readFirstBytes_ method.
> The following test code reveals the problem:
> {code:title=Test.java}
> import java.io.InputStream;
> import org.apache.commons.io.input.BOMInputStream;
> public class Test {
> public static void main(String[] args) {
> try {
> // read the file with BOM twice - works
> readFile("testfileWithBOM.xml");
> // read the file without BOM twice - crashes
> readFile("testfileWithoutBOM.xml");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> private static void readFile(String testFile) throws Exception {
> InputStream inputStream =
> Test.class.getClassLoader().getResourceAsStream(testFile);
> BOMInputStream bomStream = new BOMInputStream(inputStream);
> bomStream.mark(100);
> // read for the first time => ok
> int bytes = 0;
> byte[] bytesFromStream = new byte[100];
> do {
> bytes = bomStream.read(bytesFromStream);
> } while (bytes > 0);
> // reset and read a second time => crashes when file has no BOM
> bomStream.reset();
> do {
> bytes = bomStream.read(bytesFromStream);
> } while (bytes > 0);
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-302) ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without BOM multiple times
[
https://issues.apache.org/jira/browse/IO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Steuerwald updated IO-302:
--
Description:
Resetting the BOMInputStream doesn't reset the _fbLength_ member variable. This
causes _fbLength_ to grow bigger than the _firstBytes_ array (when the file
doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException in the
_readFirstBytes_ method.
The attached test case reveals the problem.
was:
Resetting the BOMInputStream doesn't reset the _fbLength_ member variable. This
causes _fbLength_ to grow bigger than the _firstBytes_ array (when the file
doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException in the
_readFirstBytes_ method.
The following test code reveals the problem:
{code:title=Test.java}
import java.io.InputStream;
import org.apache.commons.io.input.BOMInputStream;
public class Test {
public static void main(String[] args) {
try {
// read the file with BOM twice - works
readFile("testfileWithBOM.xml");
// read the file without BOM twice - crashes
readFile("testfileWithoutBOM.xml");
} catch (Exception e) {
e.printStackTrace();
}
}
private static void readFile(String testFile) throws Exception {
InputStream inputStream =
Test.class.getClassLoader().getResourceAsStream(testFile);
BOMInputStream bomStream = new BOMInputStream(inputStream);
bomStream.mark(100);
// read for the first time => ok
int bytes = 0;
byte[] bytesFromStream = new byte[100];
do {
bytes = bomStream.read(bytesFromStream);
} while (bytes > 0);
// reset and read a second time => crashes when file has no BOM
bomStream.reset();
do {
bytes = bomStream.read(bytesFromStream);
} while (bytes > 0);
}
}
{code}
> ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without
> BOM multiple times
> ---
>
> Key: IO-302
> URL: https://issues.apache.org/jira/browse/IO-302
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.1
> Environment: Win7 64bit, Java 6 32bit
>Reporter: Jan Steuerwald
> Attachments: Test.java, testfileBOM.xml, testfileNoBOM.xml
>
>
> Resetting the BOMInputStream doesn't reset the _fbLength_ member variable.
> This causes _fbLength_ to grow bigger than the _firstBytes_ array (when the
> file doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException
> in the _readFirstBytes_ method.
> The attached test case reveals the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-302) ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without BOM multiple times
[
https://issues.apache.org/jira/browse/IO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Steuerwald updated IO-302:
--
Attachment: Test.java
> ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without
> BOM multiple times
> ---
>
> Key: IO-302
> URL: https://issues.apache.org/jira/browse/IO-302
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.1
> Environment: Win7 64bit, Java 6 32bit
>Reporter: Jan Steuerwald
> Attachments: Test.java, testfileBOM.xml, testfileNoBOM.xml
>
>
> Resetting the BOMInputStream doesn't reset the _fbLength_ member variable.
> This causes _fbLength_ to grow bigger than the _firstBytes_ array (when the
> file doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException
> in the _readFirstBytes_ method.
> The following test code reveals the problem:
> {code:title=Test.java}
> import java.io.InputStream;
> import org.apache.commons.io.input.BOMInputStream;
> public class Test {
> public static void main(String[] args) {
> try {
> // read the file with BOM twice - works
> readFile("testfileWithBOM.xml");
> // read the file without BOM twice - crashes
> readFile("testfileWithoutBOM.xml");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> private static void readFile(String testFile) throws Exception {
> InputStream inputStream =
> Test.class.getClassLoader().getResourceAsStream(testFile);
> BOMInputStream bomStream = new BOMInputStream(inputStream);
> bomStream.mark(100);
> // read for the first time => ok
> int bytes = 0;
> byte[] bytesFromStream = new byte[100];
> do {
> bytes = bomStream.read(bytesFromStream);
> } while (bytes > 0);
> // reset and read a second time => crashes when file has no BOM
> bomStream.reset();
> do {
> bytes = bomStream.read(bytesFromStream);
> } while (bytes > 0);
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
