[jira] [Updated] (MATH-711) Merge xxxDistribution and xxxDistributionImpl in package distribution
[
https://issues.apache.org/jira/browse/MATH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-711:
---
Description:
This ticket follows the general trend aiming at removing unnecessary
interfaces. In this package, the concerned interfaces are
(/) {{BetaDistribution}}: done in r1205739
(/) {{BinomialDistribution}}: done in r1205963
(/) {{CauchyDistribution}}: done in r1206053
(/) {{ChiSquaredDistribution}}: done in r1206060
(/) {{ExponentialDistribution}}: done in r1206399
(/) {{FDistribution}}: done in r1206399
(/) {{GammaDistribution}}: done in r1206399
(/) {{HypergeometricDistribution}}: done in r1206406
(x) {{KolmogorovSmirnovDistribution}}
(x) {{NormalDistribution}}
(x) {{PascalDistribution}}
(x) {{PoissonDistribution}}
(x) {{TDistribution}}
(x) {{WeibullDistribution}}
(x) {{ZipfDistribution}}
Corresponding implementations {{xxxDistributionImpl}} will be renamed
{{xxxDistribution}}.
was:
This ticket follows the general trend aiming at removing unnecessary
interfaces. In this package, the concerned interfaces are
(/) {{BetaDistribution}}: done in r1205739
(/) {{BinomialDistribution}}: done in r1205963
(/) {{CauchyDistribution}}: done in r1206053
(/) {{ChiSquaredDistribution}}: done in r1206060
(/) {{ExponentialDistribution}}: done in r1206399
(/) {{FDistribution}}: done in r1206399
(/) {{GammaDistribution}}: done in r1206399
(/) {{HypergeometricDistribution}}: done in r1206406
(x) {{IntegerDistribution}}
(x) {{KolmogorovSmirnovDistribution}}
(x) {{NormalDistribution}}
(x) {{PascalDistribution}}
(x) {{PoissonDistribution}}
(x) {{TDistribution}}
(x) {{WeibullDistribution}}
(x) {{ZipfDistribution}}
Corresponding implementations {{xxxDistributionImpl}} will be renamed
{{xxxDistribution}}.
> Merge xxxDistribution and xxxDistributionImpl in package distribution
> -
>
> Key: MATH-711
> URL: https://issues.apache.org/jira/browse/MATH-711
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>
> This ticket follows the general trend aiming at removing unnecessary
> interfaces. In this package, the concerned interfaces are
> (/) {{BetaDistribution}}: done in r1205739
> (/) {{BinomialDistribution}}: done in r1205963
> (/) {{CauchyDistribution}}: done in r1206053
> (/) {{ChiSquaredDistribution}}: done in r1206060
> (/) {{ExponentialDistribution}}: done in r1206399
> (/) {{FDistribution}}: done in r1206399
> (/) {{GammaDistribution}}: done in r1206399
> (/) {{HypergeometricDistribution}}: done in r1206406
> (x) {{KolmogorovSmirnovDistribution}}
> (x) {{NormalDistribution}}
> (x) {{PascalDistribution}}
> (x) {{PoissonDistribution}}
> (x) {{TDistribution}}
> (x) {{WeibullDistribution}}
> (x) {{ZipfDistribution}}
> Corresponding implementations {{xxxDistributionImpl}} will be renamed
> {{xxxDistribution}}.
--
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-711) Merge xxxDistribution and xxxDistributionImpl in package distribution
[
https://issues.apache.org/jira/browse/MATH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-711:
---
Description:
This ticket follows the general trend aiming at removing unnecessary
interfaces. In this package, the concerned interfaces are
(/) {{BetaDistribution}}: done in r1205739
(/) {{BinomialDistribution}}: done in r1205963
(/) {{CauchyDistribution}}: done in r1206053
(/) {{ChiSquaredDistribution}}: done in r1206060
(/) {{ExponentialDistribution}}: done in r1206399
(/) {{FDistribution}}: done in r1206399
(/) {{GammaDistribution}}: done in r1206399
(/) {{HypergeometricDistribution}}: done in r1206406
(x) {{IntegerDistribution}}
(x) {{KolmogorovSmirnovDistribution}}
(x) {{NormalDistribution}}
(x) {{PascalDistribution}}
(x) {{PoissonDistribution}}
(x) {{TDistribution}}
(x) {{WeibullDistribution}}
(x) {{ZipfDistribution}}
Corresponding implementations {{xxxDistributionImpl}} will be renamed
{{xxxDistribution}}.
was:
This ticket follows the general trend aiming at removing unnecessary
interfaces. In this package, the concerned interfaces are
(/) {{BetaDistribution}}: done in r1205739
(/) {{BinomialDistribution}}: done in r1205963
(/) {{CauchyDistribution}}: done in r1206053
(/) {{ChiSquaredDistribution}}: done in r1206060
(/) {{ExponentialDistribution}}: done in r1206399
(/) {{FDistribution}}: done in r1206399
(/) {{GammaDistribution}}: done in r1206399
(x) {{HypergeometricDistribution}}
(x) {{IntegerDistribution}}
(x) {{KolmogorovSmirnovDistribution}}
(x) {{NormalDistribution}}
(x) {{PascalDistribution}}
(x) {{PoissonDistribution}}
(x) {{TDistribution}}
(x) {{WeibullDistribution}}
(x) {{ZipfDistribution}}
Corresponding implementations {{xxxDistributionImpl}} will be renamed
{{xxxDistribution}}.
> Merge xxxDistribution and xxxDistributionImpl in package distribution
> -
>
> Key: MATH-711
> URL: https://issues.apache.org/jira/browse/MATH-711
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>
> This ticket follows the general trend aiming at removing unnecessary
> interfaces. In this package, the concerned interfaces are
> (/) {{BetaDistribution}}: done in r1205739
> (/) {{BinomialDistribution}}: done in r1205963
> (/) {{CauchyDistribution}}: done in r1206053
> (/) {{ChiSquaredDistribution}}: done in r1206060
> (/) {{ExponentialDistribution}}: done in r1206399
> (/) {{FDistribution}}: done in r1206399
> (/) {{GammaDistribution}}: done in r1206399
> (/) {{HypergeometricDistribution}}: done in r1206406
> (x) {{IntegerDistribution}}
> (x) {{KolmogorovSmirnovDistribution}}
> (x) {{NormalDistribution}}
> (x) {{PascalDistribution}}
> (x) {{PoissonDistribution}}
> (x) {{TDistribution}}
> (x) {{WeibullDistribution}}
> (x) {{ZipfDistribution}}
> Corresponding implementations {{xxxDistributionImpl}} will be renamed
> {{xxxDistribution}}.
--
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-711) Merge xxxDistribution and xxxDistributionImpl in package distribution
[
https://issues.apache.org/jira/browse/MATH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-711:
---
Description:
This ticket follows the general trend aiming at removing unnecessary
interfaces. In this package, the concerned interfaces are
(/) {{BetaDistribution}}: done in r1205739
(/) {{BinomialDistribution}}: done in r1205963
(/) {{CauchyDistribution}}: done in r1206053
(/) {{ChiSquaredDistribution}}: done in r1206060
(/) {{ExponentialDistribution}}: done in r1206399
(/) {{FDistribution}}: done in r1206399
(/) {{GammaDistribution}}: done in r1206399
(x) {{HypergeometricDistribution}}
(x) {{IntegerDistribution}}
(x) {{KolmogorovSmirnovDistribution}}
(x) {{NormalDistribution}}
(x) {{PascalDistribution}}
(x) {{PoissonDistribution}}
(x) {{TDistribution}}
(x) {{WeibullDistribution}}
(x) {{ZipfDistribution}}
Corresponding implementations {{xxxDistributionImpl}} will be renamed
{{xxxDistribution}}.
was:
This ticket follows the general trend aiming at removing unnecessary
interfaces. In this package, the concerned interfaces are
(/) {{BetaDistribution}}: done in r1205739
(/) {{BinomialDistribution}}: done in r1205963
(/) {{CauchyDistribution}}: done in r1206053
(/) {{ChiSquaredDistribution}}: done in r1206060
(x) {{ExponentialDistribution}}
(x) {{FDistribution}}
(x) {{GammaDistribution}}
(x) {{HypergeometricDistribution}}
(x) {{IntegerDistribution}}
(x) {{KolmogorovSmirnovDistribution}}
(x) {{NormalDistribution}}
(x) {{PascalDistribution}}
(x) {{PoissonDistribution}}
(x) {{TDistribution}}
(x) {{WeibullDistribution}}
(x) {{ZipfDistribution}}
Corresponding implementations {{xxxDistributionImpl}} will be renamed
{{xxxDistribution}}.
> Merge xxxDistribution and xxxDistributionImpl in package distribution
> -
>
> Key: MATH-711
> URL: https://issues.apache.org/jira/browse/MATH-711
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>
> This ticket follows the general trend aiming at removing unnecessary
> interfaces. In this package, the concerned interfaces are
> (/) {{BetaDistribution}}: done in r1205739
> (/) {{BinomialDistribution}}: done in r1205963
> (/) {{CauchyDistribution}}: done in r1206053
> (/) {{ChiSquaredDistribution}}: done in r1206060
> (/) {{ExponentialDistribution}}: done in r1206399
> (/) {{FDistribution}}: done in r1206399
> (/) {{GammaDistribution}}: done in r1206399
> (x) {{HypergeometricDistribution}}
> (x) {{IntegerDistribution}}
> (x) {{KolmogorovSmirnovDistribution}}
> (x) {{NormalDistribution}}
> (x) {{PascalDistribution}}
> (x) {{PoissonDistribution}}
> (x) {{TDistribution}}
> (x) {{WeibullDistribution}}
> (x) {{ZipfDistribution}}
> Corresponding implementations {{xxxDistributionImpl}} will be renamed
> {{xxxDistribution}}.
--
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] [Issue Comment Edited] (MATH-703) Splitting up the distribution hierarchy
[
https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157368#comment-13157368
]
Sébastien Brisard edited comment on MATH-703 at 11/26/11 6:01 AM:
--
@Christian: how do you want to proceed? I intend to be done with MATH-711 in
the hours to come, so if you can wait until then, it would ease the patching
process. Otherwise, your instructions for manual patching were *great*, and I
can deal with that.
Thanks again,
Sébastien
PS: our distributions are immutable, yes, but not their potential children. See
eg {{GammaDistributionImpl}}: none of the accessors are final.
was (Author: celestin):
@Christian: how do you want to proceed? I intend to be done with MATH-711
in the hours to come, so if you can wait until then, it would ease the patching
process. Otherwise, your instructions for manual patching were *great*, and I
can deal with that.
Thanks again,
Sébastien
> Splitting up the distribution hierarchy
> ---
>
> Key: MATH-703
> URL: https://issues.apache.org/jira/browse/MATH-703
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Christian Winter
>Priority: Minor
> Attachments: MATH-703_patch.zip
>
>
> As discussed on the mailing list
> (http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html),
> the distribution interfaces should be restructured.
> The most important point is to create one root interface for each domain.
> There should *not* be a common super-interace because different domains
> require different functionality. Additionally, a super-inferface would
> require to parametrize the domain which makes things more complicated (e.g.,
> "double" would have to be replaced by "Double"). Currently, Commons Math
> supports distributions with real domain and distributions with integer
> domain. Thus there will be the interfaces RealDistribution and
> IntegerDistribution.
> Another point is to drop the special cases of distributions with real domain
> in order to simplify the structure. There won't be an interface for
> absolutely continuous distributions, and there won't be an interface for
> discrete distributions on the real domain. All the functionality required by
> the special cases can be defined in RealDistribution.
--
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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157369#comment-13157369
]
Sébastien Brisard commented on MATH-699:
{quote}
Great observation by Christian - we can switch on plateau detection iff
isSupportConnected is false. Otherwise, I would say the "new" implementation is
good to go.
{quote}
Yes, it is indeed a very neat way to proceed. I'll make the changes once
Christian's patch for MATH-703 is committed.
{quote}
I would also be happy to celebrate dropping all of the getXxx(p) methods, which
are not needed any more.
{quote}
Good! So I do not need to post on the mailing list on this issue?
{quote}
We can all thank Mikkel, btw, for suggesting a while back that we add the
numerical mean, variance and connected support properties. Came in very handy
here!
{quote}
I would also thank the guy who suggested Chebyshev's inequality (I wonder who
that is ;)). Overall, I personnally enjoyed working on this issue, as it truly
was team work.
Sébastien
> inverseCumulativeDistribution fails with cumulative distribution having a
> plateau
> -
>
> Key: MATH-699
> URL: https://issues.apache.org/jira/browse/MATH-699
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>Priority: Minor
> Attachments: AbstractContinuousDistributionTest.java,
> inv-cum-new-impl.zip
>
>
> This bug report follows MATH-692. The attached unit test fails. As required
> by the definition in MATH-692, the lower-bound of the interval on which the
> cdf is constant should be returned. This is not so at the moment.
--
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-703) Splitting up the distribution hierarchy
[ https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157368#comment-13157368 ] Sébastien Brisard commented on MATH-703: @Christian: how do you want to proceed? I intend to be done with MATH-711 in the hours to come, so if you can wait until then, it would ease the patching process. Otherwise, your instructions for manual patching were *great*, and I can deal with that. Thanks again, Sébastien > Splitting up the distribution hierarchy > --- > > Key: MATH-703 > URL: https://issues.apache.org/jira/browse/MATH-703 > Project: Commons Math > Issue Type: Improvement >Reporter: Christian Winter >Priority: Minor > Attachments: MATH-703_patch.zip > > > As discussed on the mailing list > (http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html), > the distribution interfaces should be restructured. > The most important point is to create one root interface for each domain. > There should *not* be a common super-interace because different domains > require different functionality. Additionally, a super-inferface would > require to parametrize the domain which makes things more complicated (e.g., > "double" would have to be replaced by "Double"). Currently, Commons Math > supports distributions with real domain and distributions with integer > domain. Thus there will be the interfaces RealDistribution and > IntegerDistribution. > Another point is to drop the special cases of distributions with real domain > in order to simplify the structure. There won't be an interface for > absolutely continuous distributions, and there won't be an interface for > discrete distributions on the real domain. All the functionality required by > the special cases can be defined in RealDistribution. -- 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] [Issue Comment Edited] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157355#comment-13157355 ] Sebb edited comment on LANG-774 at 11/26/11 1:02 AM: - The patch contains a spurious (and incorrect) change to Validate.java, but that can be ignored. Otherwise generally looks OK, though it might be better to use a positive check for isStarted. i.e instead of bq. return this.runningState != STATE_UNSTARTED && this.runningState != STATE_STOPPED; one could use bq. return this.runningState == STATE_RUNNING || this.runningState == STATE_SUSPENDED; It occurs to me that the code would be easier to read if the states were expressed as enums (the code predates them). In which case, the enum itself could have methods for reporting whether it was started/stopped/etc. was (Author: s...@apache.org): The patch contains a spurious (and incorrect) change to Validate.java, but that can be ignored. Otherwise generally looks OK, though it might be better to use a positive check for isStarted. i.e instead of bq. return this.runningState != STATE_UNSTARTED && this.runningState != STATE_STOPPED; one could use return this.runningState == STATE_RUNNING || this.runningState == STATE_SUSPENDED; It occurs to me that the code would be easier to read if the states were expressed as enums (the code predates them). In which case, the enum itself could have methods for reporting whether it was started/stopped/etc. > Add isStarted isStopped and isSuspended to StopWatch > > > Key: LANG-774 > URL: https://issues.apache.org/jira/browse/LANG-774 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* >Affects Versions: 3.1 >Reporter: Michael Akerman >Priority: Minor > Labels: features > Fix For: 3.2 > > Attachments: LANG774.diff > > Original Estimate: 2h > Remaining Estimate: 2h > > It would be nice to have: >isStarted >isStopped >isSuspended > On StopWatch -- 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] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157355#comment-13157355 ] Sebb commented on LANG-774: --- The patch contains a spurious (and incorrect) change to Validate.java, but that can be ignored. Otherwise generally looks OK, though it might be better to use a positive check for isStarted. i.e instead of bq. return this.runningState != STATE_UNSTARTED && this.runningState != STATE_STOPPED; one could use return this.runningState == STATE_RUNNING || this.runningState == STATE_SUSPENDED; It occurs to me that the code would be easier to read if the states were expressed as enums (the code predates them). In which case, the enum itself could have methods for reporting whether it was started/stopped/etc. > Add isStarted isStopped and isSuspended to StopWatch > > > Key: LANG-774 > URL: https://issues.apache.org/jira/browse/LANG-774 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* >Affects Versions: 3.1 >Reporter: Michael Akerman >Priority: Minor > Labels: features > Fix For: 3.2 > > Attachments: LANG774.diff > > Original Estimate: 2h > Remaining Estimate: 2h > > It would be nice to have: >isStarted >isStopped >isSuspended > On StopWatch -- 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-703) Splitting up the distribution hierarchy
[ https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157311#comment-13157311 ] Phil Steitz commented on MATH-703: -- I would say yes to removing toRealDistribution. I may be missing a range of practical use cases for this, though. How might the need for this arise in applications? I am also +1 for merging *Default* into the children. I agree with Sebastian's first point. Lets drop the caching support in the parent for the characteristics. While we have agreed within [math] that our distributions should be immutable, there is no guarantee that someone else might not want to implement a mutable one. Sebastien's second point is what I mean be merging the *Default* into the children. With those changes, I am +1 to applying the patch. THANKS! > Splitting up the distribution hierarchy > --- > > Key: MATH-703 > URL: https://issues.apache.org/jira/browse/MATH-703 > Project: Commons Math > Issue Type: Improvement >Reporter: Christian Winter >Priority: Minor > Attachments: MATH-703_patch.zip > > > As discussed on the mailing list > (http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html), > the distribution interfaces should be restructured. > The most important point is to create one root interface for each domain. > There should *not* be a common super-interace because different domains > require different functionality. Additionally, a super-inferface would > require to parametrize the domain which makes things more complicated (e.g., > "double" would have to be replaced by "Double"). Currently, Commons Math > supports distributions with real domain and distributions with integer > domain. Thus there will be the interfaces RealDistribution and > IntegerDistribution. > Another point is to drop the special cases of distributions with real domain > in order to simplify the structure. There won't be an interface for > absolutely continuous distributions, and there won't be an interface for > discrete distributions on the real domain. All the functionality required by > the special cases can be defined in RealDistribution. -- 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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157310#comment-13157310 ] Phil Steitz commented on MATH-699: -- Wow, we can really improve the code when we put our heads together :) Great observation by Christian - we can switch on plateau detection iff isSupportConnected is false. Otherwise, I would say the "new" implementation is good to go. I would also be happy to celebrate dropping all of the getXxx(p) methods, which are not needed any more. We can all thank Mikkel, btw, for suggesting a while back that we add the numerical mean, variance and connected support properties. Came in very handy here! > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Attachments: AbstractContinuousDistributionTest.java, > inv-cum-new-impl.zip > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- 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] [Issue Comment Edited] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
[
https://issues.apache.org/jira/browse/DAEMON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157302#comment-13157302
]
Mladen Turk edited comment on DAEMON-229 at 11/25/11 9:02 PM:
--
Give it couple of hours till the server sync is made and
http://commons.apache.org/daemon/binaries.html
will have better explanation for cpu subdir
In the mean time:
adm64 - AMD64/EMT64
ia64 - Intel Itanium 64
FYI ia64 is standard naming for Itanium processor.
amd64 was used for what we now know as x86_64 (or just x64)
However we will stick with amd64 for 1.0.x branch because
many users depend on the naming scheme.
was (Author: mt...@apache.org):
Give it couple of hours till the server sync is made and
http://commons.apache.org/daemon/binaries.html
will have better explanation for cpu subdir
In the mean time:
adm64 - AMD64/EMT64
ia64 - Intel Itanium 64
FYI ia64 is standard naming for Itanium processor.
amd64 was used for as we now know as x86_64 (or just x64)
However we will stick with amd64 for 1.0.x branch because
many users depend on the naming scheme.
> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.7
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
> )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
> initialized
> [2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51] [info] ( :0 ) Starting service...
> [2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
> 'D:\apps\jre6\bin\server\jvm.dll'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin\server'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin'
> [2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
> D:\apps\jre6\bin\server\jvm.dll
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
> [2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun
> finished
> {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] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
[
https://issues.apache.org/jira/browse/DAEMON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk resolved DAEMON-229.
Resolution: Fixed
Give it couple of hours till the server sync is made and
http://commons.apache.org/daemon/binaries.html
will have better explanation for cpu subdir
In the mean time:
adm64 - AMD64/EMT64
ia64 - Intel Itanium 64
FYI ia64 is standard naming for Itanium processor.
amd64 was used for as we now know as x86_64 (or just x64)
However we will stick with amd64 for 1.0.x branch because
many users depend on the naming scheme.
> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.7
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
> )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
> initialized
> [2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51] [info] ( :0 ) Starting service...
> [2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
> 'D:\apps\jre6\bin\server\jvm.dll'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin\server'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin'
> [2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
> D:\apps\jre6\bin\server\jvm.dll
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
> [2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun
> finished
> {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] [Issue Comment Edited] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157292#comment-13157292 ] Erhan Bagdemir edited comment on LANG-774 at 11/25/11 8:31 PM: --- here is my patch. I appriciate any comments about it. was (Author: ebagdemir): here is my patch. I appriciate for any comments about it. > Add isStarted isStopped and isSuspended to StopWatch > > > Key: LANG-774 > URL: https://issues.apache.org/jira/browse/LANG-774 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* >Affects Versions: 3.1 >Reporter: Michael Akerman >Priority: Minor > Labels: features > Fix For: 3.2 > > Attachments: LANG774.diff > > Original Estimate: 2h > Remaining Estimate: 2h > > It would be nice to have: >isStarted >isStopped >isSuspended > On StopWatch -- 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] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erhan Bagdemir updated LANG-774: Attachment: LANG774.diff here is my patch. I appriciate for any comments about it. > Add isStarted isStopped and isSuspended to StopWatch > > > Key: LANG-774 > URL: https://issues.apache.org/jira/browse/LANG-774 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* >Affects Versions: 3.1 >Reporter: Michael Akerman >Priority: Minor > Labels: features > Fix For: 3.2 > > Attachments: LANG774.diff > > Original Estimate: 2h > Remaining Estimate: 2h > > It would be nice to have: >isStarted >isStopped >isSuspended > On StopWatch -- 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-690) Remove methods from "MathUtils"
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157271#comment-13157271 ] Gilles commented on MATH-690: - Revision 1206274: * Implemented "copySign" methods. * Removed "indicator" methods. > Remove methods from "MathUtils" > --- > > Key: MATH-690 > URL: https://issues.apache.org/jira/browse/MATH-690 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Labels: api-change > Fix For: 3.0 > > > I propose to remove the following methods from "MathUtils": > public static double sign(final double x) > public static float sign(final float x) > public static double sinh(double x) > public static double cosh(double x) > Also, "sign" and "indicator" functions seem redundant (and the "float" and > "double" versions are not dealing correctly with -0.0). -- 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] (EXEC-34) Race condition prevent watchdog working using ExecuteStreamHandler
[
https://issues.apache.org/jira/browse/EXEC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157264#comment-13157264
]
Sebb commented on EXEC-34:
--
Or just change the patch headers. Instead of
{quote}
diff --git a/src/main/java/org/apache/commons/exec/DefaultExecutor.java
b/src/main/java/org/apache/commons/exec/DefaultExecutor.java
index 2182d85..2110e02 100644
--- a/src/main/java/org/apache/commons/exec/DefaultExecutor.java
+++ b/src/main/java/org/apache/commons/exec/DefaultExecutor.java
{quote}
change it to be
{quote}
--- src/main/java/org/apache/commons/exec/DefaultExecutor.java
+++ src/main/java/org/apache/commons/exec/DefaultExecutor.java
{quote}
and it should work.
Yes, it's a bit tedious.
I find I often have to do a similar trick with Eclipse-generated patches which
default to being relative to the workspace. This is not portable, unless both
workspaces use exactly the same project names.
> Race condition prevent watchdog working using ExecuteStreamHandler
> --
>
> Key: EXEC-34
> URL: https://issues.apache.org/jira/browse/EXEC-34
> Project: Commons Exec
> Issue Type: Bug
> Environment: Windows Vista 64bit, dual core CPU
>Reporter: Marco Ferrante
>Assignee: Siegfried Goeschl
>Priority: Minor
> Attachments: EXEC34.patch
>
>
> Consider this test case (in _DefaultExecutorTest_ class):
> {noformat}
> /**
> * Start a async process using a stream handler and terminate it manually
> * before the watchdog timeout occurs
> */
> public void testExecuteAsyncWithStreamHandlerAndUserTermination() throws
> Exception {
> CommandLine cl = new CommandLine(foreverTestScript);
> ExecuteWatchdog watchdog = new ExecuteWatchdog(Integer.MAX_VALUE);
> PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out,
> System.err);
> exec.setStreamHandler(streamHanlder);
> MockExecuteResultHandler handler = new MockExecuteResultHandler();
> exec.execute(cl, handler);
> // DON'T wait for script to run
> //Thread.sleep(2000);
> // teminate it
> watchdog.destroyProcess();
> assertTrue("Watchdog should have killed the
> process",watchdog.killedProcess());
> }
> {noformat}
> It fails (at least in my environment) because when
> _watchdog.destroyProcess()_ is invoked the external process is not bound to
> the watchdog yet.
> Although there are possible several workarounds, but all of them seem to me
> very intrusive in the code. So, I prefer some discussion before preparing and
> submitting a patch.
> IMHO, the watchdog should handle a reference to the thread running the
> process, not to the process itself. In this way, interrupting signals can be
> transport using default _interrupt()_ method of class _Thread_.
--
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] (LANG-778) Add ByteArrayUtils
[ https://issues.apache.org/jira/browse/LANG-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157260#comment-13157260 ] Sebb commented on LANG-778: --- I suggested extracting the general methods to ensure that the underlying conversions were more generally useful. I would be fine with splitting the code into 2 classes (that's what I originally imagined anyway). [Yes, JIRA patches can be deleted by those with sufficient karma.] > Add ByteArrayUtils > -- > > Key: LANG-778 > URL: https://issues.apache.org/jira/browse/LANG-778 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Minor > Attachments: LANG-778.diff > > Original Estimate: 8h > Remaining Estimate: 8h > > ByteArrayUtils will currently contain only conversion methods between several > types and an array of bytes. The functionality is similar to DataInput and > DataOutput, but without the indirection of IO streams. As special type the > utility class supports also conversion between UUID and byte array (memory > layout as described in RFC 4122). -- 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] [Reopened] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
[
https://issues.apache.org/jira/browse/DAEMON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Apache Fan reopened DAEMON-229:
---
Hi,
thanks for the clarification.
I checked again, and it seems that the documentation and the naming of the
binary directory is not precise enough.
http://commons.apache.org/daemon/binaries.html states...:
{noformat}
amd64 - AMD 64-bit
ia64 - Intel 64-bit
{noformat}
However:
- amd64 directory contains a binary that works on Intel 64 bit (in contrast to
the documentation)
- ia64 contains a binary that does not work on Intel 64 bit Xeon (however would
be expected to do so according to the documentation)
Could you please make it clear at least in the provided documentation?
cheers,
AF
> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.7
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
> )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
> initialized
> [2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51] [info] ( :0 ) Starting service...
> [2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
> 'D:\apps\jre6\bin\server\jvm.dll'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin\server'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin'
> [2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
> D:\apps\jre6\bin\server\jvm.dll
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
> [2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun
> finished
> {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] (BEANUTILS-397) NumberConverter is limited to Long when converting Date/Calendar to Number
[ https://issues.apache.org/jira/browse/BEANUTILS-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Sauder updated BEANUTILS-397: Attachment: numberconverter-datecalendar-to-bigdecimalbiginteger-and-visaversa.patch I have just recognized: When NumberConverter supports conversion from Calendar to BigDecimal and BigInteger so should DateTimeConverter support the contrary. Therefore I have updated the patch and added such feature. Would love to see this patch applied. > NumberConverter is limited to Long when converting Date/Calendar to Number > -- > > Key: BEANUTILS-397 > URL: https://issues.apache.org/jira/browse/BEANUTILS-397 > Project: Commons BeanUtils > Issue Type: Improvement > Components: ConvertUtils & Converters >Affects Versions: 1.8.3 >Reporter: Oliver Sauder >Priority: Minor > Fix For: 1.8.4 > > Attachments: > numberconverter-datecalendar-to-bigdecimalbiginteger-and-visaversa.patch, > numberconverter-datecalendar-to-bigdecimalbiginteger.patch > > > NumberConverter is limited to Long when converting Date/Calendar to Number. > However it would be desirable when the conversion would work to BigDecimal > and BigInteger as well. -- 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] (MATH-713) Negative value with restrictNonNegative
Negative value with restrictNonNegative --- Key: MATH-713 URL: https://issues.apache.org/jira/browse/MATH-713 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Environment: commons-math-2.2 Reporter: Michał Skrzypczak Problem: commons-math-2.2 SimplexSolver. A variable with 0 coefficient may be assigned a negative value nevertheless restrictToNonnegative flag in call: SimplexSolver.optimize(function, constraints, GoalType.MINIMIZE, true); Function 1 * x + 1 * y + 0 Constraints: 1 * x + 0 * y = 1 Result: x = 1; y = -1; Probably variables with 0 coefficients are omitted at some point of computation and because of that the restrictions do not affect their values. -- 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] (CLI-120) equals and hashCode are incomplete
[ https://issues.apache.org/jira/browse/CLI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Holger S. updated CLI-120: -- Attachment: ArgumentEqualsPatch.diff > equals and hashCode are incomplete > -- > > Key: CLI-120 > URL: https://issues.apache.org/jira/browse/CLI-120 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-2.x >Reporter: Andrew Shirley >Priority: Minor > Fix For: 2.0 > > Attachments: ArgumentEqualsPatch.diff > > > there are many classes with equals and hashCode implemented however there are > also classes which don't. We need to be consistent and if we are using equals > then we need to define it for all classes in the affected hierarchy. For > example OptionImpl has an equals but ParentImpl which extends OptionImpl and > has several new members doesn't. -- 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] (CLI-120) equals and hashCode are incomplete
[ https://issues.apache.org/jira/browse/CLI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157214#comment-13157214 ] Holger S. commented on CLI-120: --- I implemented equals and hashCode for ArgumentImpl and SourceDestImpl and created test cases. Please review this patch. a few issues arose: - Validators usually don't implement equals and hashCode either, so ArgumentImpl.equals does not work correctly if only the validator is different - PropertyOption does not have any attributes that are not used in OptionImpl.equals, so all are compared but I think it would fail if two different subclasses of OptionImpl were compared. I couldn't create a test case, but this could be a problem in the future. > equals and hashCode are incomplete > -- > > Key: CLI-120 > URL: https://issues.apache.org/jira/browse/CLI-120 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-2.x >Reporter: Andrew Shirley >Priority: Minor > Fix For: 2.0 > > Attachments: ArgumentEqualsPatch.diff > > > there are many classes with equals and hashCode implemented however there are > also classes which don't. We need to be consistent and if we are using equals > then we need to define it for all classes in the affected hierarchy. For > example OptionImpl has an equals but ParentImpl which extends OptionImpl and > has several new members doesn't. -- 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] (COMPRESS-137) TarArchiveEntry.getFile() always returns null + no way to get an InputStream from TarArchiveInputStream similar to what you do with (java.util.zip.ZipFile())..getInpu
[ https://issues.apache.org/jira/browse/COMPRESS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157177#comment-13157177 ] Stefan Bodewig commented on COMPRESS-137: - You can wrap the stream in something like the BoundedInputStream found as nested class in ZipFile or more conveniently in commons-io. > TarArchiveEntry.getFile() always returns null + no way to get an InputStream > from TarArchiveInputStream similar to what you do with > (java.util.zip.ZipFile())..getInputStream(ZipEntry); > > > Key: COMPRESS-137 > URL: https://issues.apache.org/jira/browse/COMPRESS-137 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.1 > Environment: $ uname -a > Linux Microknoppix 2.6.31.6 #4 SMP PREEMPT Tue Nov 10 19:11:11 CET 2009 i686 > GNU/Linux > $ java -version > java version "1.6.0_16" > Java(TM) SE Runtime Environment (build 1.6.0_16-b01) > Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing) > $ echo $CLASSPATH > /media/sdb3/prjx/Java/JUtils:/media/sdb3/prjx/Java/JUtils/jars/commons-compress-1.1.jar:. >Reporter: Albretch Mueller >Assignee: Torsten Curdt >Priority: Critical > Labels: zip_through_XMLReader > Fix For: 1.1 > > > ~ > this is a test run using httpd-2.2.19.tar[.gz,bz2] to show what I mean > ~ > lbrtchx > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > ~ ~ ~ > $ wget http://apache.cyberuse.com//httpd/httpd-2.2.19.tar.gz > --2011-06-27 11:21:46-- http://apache.cyberuse.com//httpd/httpd-2.2.19.tar.gz > Resolving apache.cyberuse.com... 174.132.149.89 > Connecting to apache.cyberuse.com|174.132.149.89|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 7113418 (6.8M) [application/x-gzip] > Saving to: `httpd-2.2.19.tar.gz' > 100%[===...===>] 7,113,418296K/s in 24s > 2011-06-27 11:22:10 (285 KB/s) - `httpd-2.2.19.tar.gz' saved [7113418/7113418] > $ wget http://apache.cyberuse.com//httpd/httpd-2.2.19.tar.bz2 > --2011-06-27 11:22:19-- > http://apache.cyberuse.com//httpd/httpd-2.2.19.tar.bz2 > Resolving apache.cyberuse.com... 174.132.149.89 > Connecting to apache.cyberuse.com|174.132.149.89|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 5322082 (5.1M) [application/x-bzip2] > Saving to: `httpd-2.2.19.tar.bz2' > 100%[===...===>] 5,322,082256K/s in 25s > 2011-06-27 11:22:44 (207 KB/s) - `httpd-2.2.19.tar.bz2' saved > [5322082/5322082] > $ wget http://www.apache.org/dist/httpd/httpd-2.2.19.tar.gz.md5 > --2011-06-27 11:22:51-- > http://www.apache.org/dist/httpd/httpd-2.2.19.tar.gz.md5 > Resolving www.apache.org... 140.211.11.131 > Connecting to www.apache.org|140.211.11.131|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 54 [text/plain] > Saving to: `httpd-2.2.19.tar.gz.md5' > 100%[===...===>] 54 --.-K/s in 0s > 2011-06-27 11:22:51 (4.23 MB/s) - `httpd-2.2.19.tar.gz.md5' saved [54/54] > $ wget http://www.apache.org/dist/httpd/httpd-2.2.19.tar.bz2.md5 > --2011-06-27 11:23:02-- > http://www.apache.org/dist/httpd/httpd-2.2.19.tar.bz2.md5 > Resolving www.apache.org... 140.211.11.131 > Connecting to www.apache.org|140.211.11.131|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 55 [text/plain] > Saving to: `httpd-2.2.19.tar.bz2.md5' > 100%[===...===>] 55 --.-K/s in 0s > 2011-06-27 11:23:02 (4.91 MB/s) - `httpd-2.2.19.tar.bz2.md5' saved [55/55] > $ ls -l httpd-2.2.19.tar.* > -rw-r--r-- 1 knoppix knoppix 5322082 May 21 18:58 httpd-2.2.19.tar.bz2 > -rw-r--r-- 1 knoppix knoppix 55 May 21 18:58 httpd-2.2.19.tar.bz2.md5 > -rw-r--r-- 1 knoppix knoppix 7113418 May 21 18:58 httpd-2.2.19.tar.gz > -rw-r--r-- 1 knoppix knoppix 54 May 21 18:58 httpd-2.2.19.tar.gz.md5 > $ md5sum -b httpd-2.2.19.tar.bz2 > 832f96a6ec4b8fc7cf49b9efd4e89060 *httpd-2.2.19.tar.bz2 > $ md5sum -b httpd-2.2.19.tar.gz > e9f5453e1e4d7aeb0e7ec7184c6784b5 *httpd-2.2.19.tar.gz > $ cat *.md5 > 832f96a6ec4b8fc7cf49b9efd4e89060 *httpd-2.2.19.tar.bz2 > e9f5453e1e4d7aeb0e7ec7184c6784b5 *httpd-2.2.19.tar.gz > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > ~ ~ ~ > /* > TarArchiveEntry.getFile() always returns null + no way to get an InputStream > from TarArchiveInputStream similar to what you do with > (java.util.zip.ZipFile())..getInputStream(ZipEntry); > */ > import org.apache.commons.compress.compressors.bzip2.*; > import org.apache.commons.compress.compressors.gzip.*; > import org.apache.commons.compress.archivers.tar.*; > import org
[jira] [Commented] (MATH-689) Breaking up "MathUtils"
[
https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157178#comment-13157178
]
Gilles commented on MATH-689:
-
"pow" functions moved in r1206199.
> Breaking up "MathUtils"
> ---
>
> Key: MATH-689
> URL: https://issues.apache.org/jira/browse/MATH-689
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> Issue related to this
> [proposal|http://www.mail-archive.com/dev@commons.apache.org/msg25617.html].
> There seemed to be a global agreement on the following break-up:
> * Arithmetics (for "addAndCheck", "factorial", "gcd", ...)
> * Precision (for "equals", "compare", ...)
> * Binomial (for "binomialCoefficient")
> * MathArrays (for "linearCombination", "distance", "safeNorm",
> "sortInPlace", "copyOf", ...)
> I think that "ordinary" mathematical functions ("pow", "cosh", ...) should go
> into "FastMath" (if not already available there).
> Those who are willing to work on this issue, please coordinate here.
--
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] (EXEC-34) Race condition prevent watchdog working using ExecuteStreamHandler
[
https://issues.apache.org/jira/browse/EXEC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157172#comment-13157172
]
Olivier Lamy commented on EXEC-34:
--
@simone should work with:
{code}
patch -p1 < patchfile
{code}
> Race condition prevent watchdog working using ExecuteStreamHandler
> --
>
> Key: EXEC-34
> URL: https://issues.apache.org/jira/browse/EXEC-34
> Project: Commons Exec
> Issue Type: Bug
> Environment: Windows Vista 64bit, dual core CPU
>Reporter: Marco Ferrante
>Assignee: Siegfried Goeschl
>Priority: Minor
> Attachments: EXEC34.patch
>
>
> Consider this test case (in _DefaultExecutorTest_ class):
> {noformat}
> /**
> * Start a async process using a stream handler and terminate it manually
> * before the watchdog timeout occurs
> */
> public void testExecuteAsyncWithStreamHandlerAndUserTermination() throws
> Exception {
> CommandLine cl = new CommandLine(foreverTestScript);
> ExecuteWatchdog watchdog = new ExecuteWatchdog(Integer.MAX_VALUE);
> PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out,
> System.err);
> exec.setStreamHandler(streamHanlder);
> MockExecuteResultHandler handler = new MockExecuteResultHandler();
> exec.execute(cl, handler);
> // DON'T wait for script to run
> //Thread.sleep(2000);
> // teminate it
> watchdog.destroyProcess();
> assertTrue("Watchdog should have killed the
> process",watchdog.killedProcess());
> }
> {noformat}
> It fails (at least in my environment) because when
> _watchdog.destroyProcess()_ is invoked the external process is not bound to
> the watchdog yet.
> Although there are possible several workarounds, but all of them seem to me
> very intrusive in the code. So, I prefer some discussion before preparing and
> submitting a patch.
> IMHO, the watchdog should handle a reference to the thread running the
> process, not to the process itself. In this way, interrupting signals can be
> transport using default _interrupt()_ method of class _Thread_.
--
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] (LANG-778) Add ByteArrayUtils
[ https://issues.apache.org/jira/browse/LANG-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157140#comment-13157140 ] Konstantin Kolinko commented on LANG-778: - I like the new concept a lot less than the original one. (And where did the original patch disappeared? You can remove them as you like from JIRA?) It started with little small and understandable utility for the UUID class. Now if I want to work with UUID, how am I supposed to know that some ByteArray class has the methods? The class name does not give me any clue. If you really want to reuse byte[] <-> long conversion that exists elsewhere, you can just call that other class method. But please keep goal of each single class well defined. > Add ByteArrayUtils > -- > > Key: LANG-778 > URL: https://issues.apache.org/jira/browse/LANG-778 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Minor > Attachments: LANG-778.diff > > Original Estimate: 8h > Remaining Estimate: 8h > > ByteArrayUtils will currently contain only conversion methods between several > types and an array of bytes. The functionality is similar to DataInput and > DataOutput, but without the indirection of IO streams. As special type the > utility class supports also conversion between UUID and byte array (memory > layout as described in RFC 4122). -- 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] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157139#comment-13157139
]
Carlos Bustamante commented on NET-408:
---
Hi, recently i try to use the claymoresystems, with the Crytix library, *jdk
1.7, but it shows me an the class Socket is duplicated, and i have reviewed
this same bug with proftpd-1.3.3c-1.el5.rf with centos 5.7,
SOLUTION
use vsftpd with this configuration
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=/etc/vsftpd/vsftpd.pem
xferlog_enable=YES
log_ftp_protocol=YES
setproctitle_enable=YES
this works great, without modify the apache commons library.
The problem originated basically was the ciphed method used by proftdp not
supported
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
> Attachments: BCFTPSClient.java, PTFTPSClient.java, ftpes.jpg,
> proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
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] (LANG-778) Add ByteArrayUtils
[ https://issues.apache.org/jira/browse/LANG-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157119#comment-13157119 ] Joerg Schaible commented on LANG-778: - bq. The new patch looks good. OK. However, when I look now at the method names and all the references in Javadoc, I wonder if *lang* is still the right place. It might as well be added to *io* as DataIOUtils. Nevertheless we're still dealing with memory-based access and bit manipulation. But so does EndianUtils. > Add ByteArrayUtils > -- > > Key: LANG-778 > URL: https://issues.apache.org/jira/browse/LANG-778 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Minor > Attachments: LANG-778.diff > > Original Estimate: 8h > Remaining Estimate: 8h > > ByteArrayUtils will currently contain only conversion methods between several > types and an array of bytes. The functionality is similar to DataInput and > DataOutput, but without the indirection of IO streams. As special type the > utility class supports also conversion between UUID and byte array (memory > layout as described in RFC 4122). -- 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] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
[
https://issues.apache.org/jira/browse/DAEMON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated DAEMON-229:
Affects Version/s: (was: 1.0.8)
1.0.7
bq. Commons Daemon procrun (1.0.7.0 32-bit) started
Also note that you are not using the current version (1.0.8)
> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.7
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
> )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
> initialized
> [2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51] [info] ( :0 ) Starting service...
> [2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
> 'D:\apps\jre6\bin\server\jvm.dll'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin\server'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin'
> [2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
> D:\apps\jre6\bin\server\jvm.dll
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
> [2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun
> finished
> {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] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
[
https://issues.apache.org/jira/browse/DAEMON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk resolved DAEMON-229.
Resolution: Invalid
Please use 64-bit version of procrun if you wish to run 64-bit JVM. It is
inside amd64/ distribution directory.
> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.8
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
> )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
> initialized
> [2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51] [info] ( :0 ) Starting service...
> [2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
> 'D:\apps\jre6\bin\server\jvm.dll'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin\server'
> [2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
> 'D:\apps\jre6\bin'
> [2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
> D:\apps\jre6\bin\server\jvm.dll
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
> [2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
> application.
> [2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
> [2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun
> finished
> {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] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
[
https://issues.apache.org/jira/browse/DAEMON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Apache Fan updated DAEMON-229:
--
Description:
I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
1.6.0_29 64 bit.
During starting a service (Cassandra) I receive the error log below.
As a workaround I installed 32 bit JVM, and configured the
\jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
(Hint found at
http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
)
Compatibility with 64 bit JVM should be established.
{noformat}
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
initialized
[2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun (1.0.7.0
32-bit) started
[2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
[2011-11-25 02:50:51] [info] ( :0 ) Starting service...
[2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
'D:\apps\jre6\bin\server\jvm.dll'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin\server'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin'
[2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
D:\apps\jre6\bin\server\jvm.dll
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
[2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun finished
{noformat}
was:
I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
1.6.0_29 64 bit.
I receive the error log below.
As a workaround I installed 32 bit JVM, and configured the
\jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
(Hint found at
http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
)
Compatibility with 64 bit JVM should be established.
{noformat}
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
initialized
[2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun (1.0.7.0
32-bit) started
[2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
[2011-11-25 02:50:51] [info] ( :0 ) Starting service...
[2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
'D:\apps\jre6\bin\server\jvm.dll'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin\server'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin'
[2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
D:\apps\jre6\bin\server\jvm.dll
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
[2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun finished
{noformat}
> Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
> ---
>
> Key: DAEMON-229
> URL: https://issues.apache.org/jira/browse/DAEMON-229
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.8
> Environment: Windows 2003 server 64bit
> Sun JDK1.6.0_29 64bit
>Reporter: Apache Fan
>
> I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
> 1.6.0_29 64 bit.
> During starting a service (Cassandra) I receive the error log below.
> As a workaround I installed 32 bit JVM, and configured the
> \jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
> (Hint found at
> http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
> )
> Compatibility with 64 bit JVM should be established.
> {noformat}
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
> initialized
> [2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun
> (1.0.7.0 32-bit) started
> [2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
> [2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
> [2011-11-25 02:50:51]
[jira] [Created] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
---
Key: DAEMON-229
URL: https://issues.apache.org/jira/browse/DAEMON-229
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.8
Environment: Windows 2003 server 64bit
Sun JDK1.6.0_29 64bit
Reporter: Apache Fan
I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
1.6.0_29 64 bit.
I receive the error log below.
As a workaround I installed 32 bit JVM, and configured the
\jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
(Hint found at
http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
)
Compatibility with 64 bit JVM should be established.
{noformat}
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
initialized
[2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun (1.0.7.0
32-bit) started
[2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
[2011-11-25 02:50:51] [info] ( :0 ) Starting service...
[2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
'D:\apps\jre6\bin\server\jvm.dll'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin\server'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin'
[2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
D:\apps\jre6\bin\server\jvm.dll
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
[2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun finished
{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] [Created] (VFS-395) VFS2 should declare maven-scm-* dependencies as optional in pom
VFS2 should declare maven-scm-* dependencies as optional in pom --- Key: VFS-395 URL: https://issues.apache.org/jira/browse/VFS-395 Project: Commons VFS Issue Type: Wish Affects Versions: 2.0 Reporter: Xavier Dury VFS2 includes weird dependencies: maven-scm-api, maven-scm-provider-svnexe. See http://commons.apache.org/vfs/commons-vfs2/dependencies.html -- 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
