[jira] [Resolved] (DAEMON-226) support files have incorrect svn:eol-style
[ https://issues.apache.org/jira/browse/DAEMON-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-226. Resolution: Won't Fix EOL style is used when on the same platform certain files need to have different line endings. This is not case here. In your case you can use either dos2unix or svn export --native-eol LF. > support files have incorrect svn:eol-style > -- > > Key: DAEMON-226 > URL: https://issues.apache.org/jira/browse/DAEMON-226 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: Nightly Builds >Reporter: Michael Osipov > Attachments: DAEMON-226.patch > > > I have checked out under Windows and copied an exported tar to a unix system. > All files contained ^M. This is not a issue if you checkout under Unix but in > my case I do not have an svn client and have to do this way. > Anyway, the eol-style should always be LF because these files are for Unix > only. > I have attached a patch for. -- 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-225) Remove leftovers of Kaffe VM and Sable VM
[
https://issues.apache.org/jira/browse/DAEMON-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk resolved DAEMON-225.
Resolution: Fixed
Removed
> Remove leftovers of Kaffe VM and Sable VM
> -
>
> Key: DAEMON-225
> URL: https://issues.apache.org/jira/browse/DAEMON-225
> Project: Commons Daemon
> Issue Type: Sub-task
> Components: Jsvc
>Affects Versions: Nightly Builds
>Reporter: Michael Osipov
>
> Though compile support has been removed some stuff is still in the source
> code:
> {noformat}
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn
> --exclude=*\.svn* "SABLEVM" *
> native/java.c:331:#if defined(HAVE_SABLEVM)
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn
> --exclude=*\.svn* "KAFFEVM" *
> native/jsvc-unix.c:735:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/arguments.c:330:#ifdef HAVE_KAFFEVM
> native/java.c:169:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:214:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:243:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:245:#if defined(HAVE_KAFFEVM)
> native/java.c:311:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> {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-225) Remove leftovers of Kaffe VM and Sable VM
[
https://issues.apache.org/jira/browse/DAEMON-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk updated DAEMON-225:
---
Issue Type: Sub-task (was: Improvement)
Parent: DAEMON-220
> Remove leftovers of Kaffe VM and Sable VM
> -
>
> Key: DAEMON-225
> URL: https://issues.apache.org/jira/browse/DAEMON-225
> Project: Commons Daemon
> Issue Type: Sub-task
> Components: Jsvc
>Affects Versions: Nightly Builds
>Reporter: Michael Osipov
>
> Though compile support has been removed some stuff is still in the source
> code:
> {noformat}
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn
> --exclude=*\.svn* "SABLEVM" *
> native/java.c:331:#if defined(HAVE_SABLEVM)
> mosipov@hardy-heron:~/Projekte/daemon/src/native/unix$ fgrep -Rn
> --exclude=*\.svn* "KAFFEVM" *
> native/jsvc-unix.c:735:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/arguments.c:330:#ifdef HAVE_KAFFEVM
> native/java.c:169:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:214:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:243:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> native/java.c:245:#if defined(HAVE_KAFFEVM)
> native/java.c:311:#if defined(OSD_POSIX) || defined(HAVE_KAFFEVM)
> {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] (DAEMON-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[ https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141946#comment-13141946 ] Mladen Turk commented on DAEMON-222: I reverted the change. Its not opted out any more. Also changed the help screen to remove the 'Linux only' since if given on other platforms it'll be used for openlog identity. > Remove 'procname' option with preprocessor condition if OS is not Linux > --- > > Key: DAEMON-222 > URL: https://issues.apache.org/jira/browse/DAEMON-222 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > > The procname option can only be used on Linux. It would be removed by the > preprocessor if the target OS is not Linux. -- 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-215) Cannot set local username and password for a Win32 service
[ https://issues.apache.org/jira/browse/DAEMON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-215: Fix Version/s: (was: 1.0.7) > Cannot set local username and password for a Win32 service > -- > > Key: DAEMON-215 > URL: https://issues.apache.org/jira/browse/DAEMON-215 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: win32 / server 2003 >Reporter: wessels >Assignee: Mladen Turk >Priority: Minor > Original Estimate: 24h > Remaining Estimate: 24h > > installing a new service without supplying the --ServiceUser > --ServicePassword installs the service correctly but using the LocalSystem > account. If you want to use a local user, which of course has at least the > "log on as a service" right, and supply the credentials via the parameters > you get an error. To be more specific, in service.c line 211, the > CHANGE_SERVICE macro fails with error 87L ERROR_INVALID_PARAMETER. This > happens at least when creating and updating a service. Setting other options > via this macro work fine, just the username password fail (standalone and in > combination with other parameters). > The solution is specifying SERVICE_WIN32_OWN_PROCESS as ServiceType parameter > instead of SERVICE_NO_CHANGE in ChangeServiceConfigW line 27 second parameter. -- 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-213) procun log rotation support
[ https://issues.apache.org/jira/browse/DAEMON-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-213: Fix Version/s: (was: Nightly Builds) > procun log rotation support > --- > > Key: DAEMON-213 > URL: https://issues.apache.org/jira/browse/DAEMON-213 > Project: Commons Daemon > Issue Type: Improvement > Components: Procrun >Affects Versions: 1.0.4, 1.0.5, 1.0.6 > Environment: os: winxp >Reporter: viola.lu >Priority: Minor > > currently, procun doesn't support log rotation. Should add an option -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-220: Fix Version/s: 1.0.8 > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Fix For: 1.0.8 > > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[ https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-222: Fix Version/s: (was: 1.0.8) > Remove 'procname' option with preprocessor condition if OS is not Linux > --- > > Key: DAEMON-222 > URL: https://issues.apache.org/jira/browse/DAEMON-222 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > > The procname option can only be used on Linux. It would be removed by the > preprocessor if the target OS is not Linux. -- 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-221) Provide umask rather than compile time flag for umask
[ https://issues.apache.org/jira/browse/DAEMON-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-221: Fix Version/s: 1.0.8 > Provide umask rather than compile time flag for umask > - > > Key: DAEMON-221 > URL: https://issues.apache.org/jira/browse/DAEMON-221 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Fix For: 1.0.8 > > > umask can only be modified at compile time with -DUMASK... this is somewhat > annoying. Please include a -umask option which takes in a octal number. A > sane umask (0777) should remain of course. -- 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-224) Add /etc/alternatives/jre to the list of JAVA_HOME suggestions on Linux
[
https://issues.apache.org/jira/browse/DAEMON-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated DAEMON-224:
Fix Version/s: (was: 1.0.7)
1.0.8
> Add /etc/alternatives/jre to the list of JAVA_HOME suggestions on Linux
> ---
>
> Key: DAEMON-224
> URL: https://issues.apache.org/jira/browse/DAEMON-224
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Jsvc
>Affects Versions: 1.0.7
> Environment: Linux
>Reporter: Archie Cobbs
>Assignee: Mladen Turk
>Priority: Minor
> Fix For: 1.0.8
>
>
> On some flavors of Linux (e.g., openSUSE), the {{update-alternatives}} system
> is used to configure which JVM to use.
> On these systems, {{$JAVA_HOME}} can always be set to
> {{/etc/alternatives/jre}}.
> The following simple patch would add this to the list of places to look:
> {noformat}
> Index: src/native/unix/native/location.c
> ===
> --- src/native/unix/native/location.c (revision 1189876)
> +++ src/native/unix/native/location.c (working copy)
> @@ -35,6 +35,7 @@
> #elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD)
> "/usr/java",
> "/usr/local/java",
> +"/etc/alternatives/jre",
> #elif defined(OS_CYGWIN)
> "/cygdrive/c/WINNT/system32/java",
> #elif defined(OS_SYSV)
> {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-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[ https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-222: Fix Version/s: (was: 1.0.7) 1.0.8 > Remove 'procname' option with preprocessor condition if OS is not Linux > --- > > Key: DAEMON-222 > URL: https://issues.apache.org/jira/browse/DAEMON-222 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Fix For: 1.0.8 > > > The procname option can only be used on Linux. It would be removed by the > preprocessor if the target OS is not Linux. -- 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-223) configure script has incorrect supported OS for HP-UX on IA64
[ https://issues.apache.org/jira/browse/DAEMON-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-223: Fix Version/s: 1.0.8 > configure script has incorrect supported OS for HP-UX on IA64 > - > > Key: DAEMON-223 > URL: https://issues.apache.org/jira/browse/DAEMON-223 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk >Priority: Critical > Fix For: 1.0.8 > > Attachments: DAEMON-223.patch > > > The apsupport.m4 file has an incorrect supported_os value for HP-UX on > Itanium. java_md.h cannot be found. > I have unified the property for all HP-UX systems. It should cover all cases > now. jsvc compiles out of the box now on HP-UX 11.x. The supplied patch is > attached. -- 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-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[ https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141609#comment-13141609 ] Michael Osipov commented on DAEMON-222: --- Since you opted out procname, it fails on FreeBSD now. You have to exclude the help output and the parameter but leaving arg_data->procname as-is. > Remove 'procname' option with preprocessor condition if OS is not Linux > --- > > Key: DAEMON-222 > URL: https://issues.apache.org/jira/browse/DAEMON-222 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Fix For: 1.0.7 > > > The procname option can only be used on Linux. It would be removed by the > preprocessor if the target OS is not Linux. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141605#comment-13141605 ] Michael Osipov commented on DAEMON-220: --- Well, I don't think that this is necessary but this is your decision. I'd leave it. Although you simplified it, it still contains a bug in line 42 to 52. That's why I have provided a patch. "which java"... does not yield a positive result. It is unreliable too. which java on FreeBSD gives your /usr/local/bin/java. You traverse up and assume that /usr/local is the JDK home. This is incorrect. The following iterations at least did it. > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-220. Resolution: Fixed It might cover 80% now, but next year this won't be the case any more. What's worse the JDK it finds might not be the one that you wish to build upon. To simplify the things I dropped the entire guessing mechanism. JAVA_HOME or --with-java is more then enough. INSTALL.txt already has that explained and I'll update it to contain the new --with-os-type directive > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[ https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-222. Resolution: Won't Fix procname is used on all systems as name for the system log. Thus it cannot be removed > Remove 'procname' option with preprocessor condition if OS is not Linux > --- > > Key: DAEMON-222 > URL: https://issues.apache.org/jira/browse/DAEMON-222 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Fix For: 1.0.7 > > > The procname option can only be used on Linux. It would be removed by the > preprocessor if the target OS is not Linux. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141561#comment-13141561 ] Michael Osipov edited comment on DAEMON-220 at 11/1/11 8:42 PM: I was not refering to a JRE. I know that a JDK is necessary. That was my point: FIND_JAVA => FIND_JDK. There is no need to drop it at all. Right now with the patch it does a good job and should cover 80 % of all cases. So we are good. Those who still need to customize can do anyway. Reasonable defaults are always a good starting point. java in the path does not mean you will find the JDK. In my case your check failed and led to false results (FreeBSD 8.2). was (Author: michael-o): I was not refering to a JRE. I know that a JDK is necessary. That was my point: FIND_JAVA => FIND_JDK. There is no need to drop it at all. Right now with the patch it does a good job and should cover 80 % of all cases. So we are good. Those who still need to customize can do anyway. Reasonable defaults are always a good starting point. java in the path does not mean you will find the JDK. In my case your check failed and led to false results. > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141561#comment-13141561 ] Michael Osipov commented on DAEMON-220: --- I was not refering to a JRE. I know that a JDK is necessary. That was my point: FIND_JAVA => FIND_JDK. There is no need to drop it at all. Right now with the patch it does a good job and should cover 80 % of all cases. So we are good. Those who still need to customize can do anyway. Reasonable defaults are always a good starting point. java in the path does not mean you will find the JDK. In my case your check failed and led to false results. > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141539#comment-13141539 ] Mladen Turk commented on DAEMON-220: Well first of all it has to be JDK. JRE doesn't have include files, so you cannot build daemon without JDK installed. Think I'll drop FIND_JDK completely. It's simply useless and its never gonna be complete. There will always be a distribution that will have its own directory layout and trying to catch and guess all just makes no sense. If there is no JAVA_HOME set, and java in the PATH doesn't point to the JDK, then the user will have to use --with-java and --with-os-type. > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141229#comment-13141229 ] Michael Osipov edited comment on DAEMON-220 at 11/1/11 8:14 PM: Mladen, AP_FIND_JAVA is still broken. It assumes with "which java" that the top dir is the JDK. Which might not be the case. I have adapted the function from libtcnative just like you did with the include dir. I'd rather call it AP_FIND_JDK because you are looking for a JDK and its include dirs rather than just some Java package (JRE or JDK). was (Author: michael-o): Mladen, AP_FIND_JAVA is still broken. It assumes with "which java" that the top dir is the JDK. Which might not be the case. I have adapted the function from libtcnative just like you did with the include dir. > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DAEMON-220: -- Comment: was deleted (was: AP_FIND_JAVA is still incomplete) > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[
https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141293#comment-13141293
]
Maurizio Cucchiara commented on OGNL-36:
{quote}
I'd suggest to rename to benchmarks the commons-ognl tests and
benchmarks-legacy the old one.
{quote}
Good idea, I'm going to apply your suggestion.
{quote}
I don't know if the JUnit benchmarks tool allows us mixing the two graphes with
different colours, that would be IMHO the more canonical way to see the
differences between the two...
{quote}
Me too, I have an idea that's worth at least a try.
{quote}
both links point to the same location
{quote}
Corrected :)
> Link "Benchmarks" on left hand navigation is broken
> ---
>
> Key: OGNL-36
> URL: https://issues.apache.org/jira/browse/OGNL-36
> Project: OGNL
> Issue Type: Bug
>Reporter: Adrian Cumiskey
>Assignee: Maurizio Cucchiara
>Priority: Minor
> Attachments: patch-OGNL36.txt
>
>
> The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken
> link to "Benchmarks" on the left hand navigation of the OGNL homepage.
--
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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[ https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141250#comment-13141250 ] Maurizio Cucchiara edited comment on OGNL-36 at 11/1/11 4:22 PM: - I (ab)used the commons prefix to distinguish the [old ognl benchmark|http://commons.apache.org/ognl/benchmark-old-ognl.html] from the [commons one|http://commons.apache.org/ognl/benchmark-commons-ognl.html]. Furthermore, to make more complex what is already enough, there are even: # http://commons.apache.org/ognl/org.apache.commons.ognl.performance.PerformanceCommonsOgnlTest.html # http://commons.apache.org/ognl/org.apache.commons.ognl.performance.PerformanceOldOgnlTest.html But I'm not happy with the way they represent the difference between the old and the common approach. What is the best way to show the performance increment? was (Author: maurizio.cucchiara): I (ab)used the commons prefix to distinguish the [old ognl benchmark|http://commons.apache.org/ognl/benchmark-commons-ognl.html] from the [commons one|http://commons.apache.org/ognl/benchmark-commons-ognl.html]. Furthermore, to make more complex what is already enough, there are even: # http://commons.apache.org/ognl/org.apache.commons.ognl.performance.PerformanceCommonsOgnlTest.html # http://commons.apache.org/ognl/org.apache.commons.ognl.performance.PerformanceOldOgnlTest.html But I'm not happy with the way they represent the difference between the old and the common approach. What is the best way to show the performance increment? > Link "Benchmarks" on left hand navigation is broken > --- > > Key: OGNL-36 > URL: https://issues.apache.org/jira/browse/OGNL-36 > Project: OGNL > Issue Type: Bug >Reporter: Adrian Cumiskey >Assignee: Maurizio Cucchiara >Priority: Minor > Attachments: patch-OGNL36.txt > > > The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken > link to "Benchmarks" on the left hand navigation of the OGNL homepage. -- 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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[
https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141280#comment-13141280
]
Simone Tripodi commented on OGNL-36:
I'd suggest to rename to {{benchmarks}} the _commons-ognl_ tests and
{{benchmarks-legacy}} the old one.
I don't know if the JUnit benchmarks tool allows us mixing the two graphes with
different colours, that would be IMHO the more canonical way to see the
differences between the two...
{quote}
[...] the old ognl benchmark from the commons one.
{quote}
both links point to the same location :P
> Link "Benchmarks" on left hand navigation is broken
> ---
>
> Key: OGNL-36
> URL: https://issues.apache.org/jira/browse/OGNL-36
> Project: OGNL
> Issue Type: Bug
>Reporter: Adrian Cumiskey
>Assignee: Maurizio Cucchiara
>Priority: Minor
> Attachments: patch-OGNL36.txt
>
>
> The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken
> link to "Benchmarks" on the left hand navigation of the OGNL homepage.
--
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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[ https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141250#comment-13141250 ] Maurizio Cucchiara commented on OGNL-36: I (ab)used the commons prefix to distinguish the [old ognl benchmark|http://commons.apache.org/ognl/benchmark-commons-ognl.html] from the [commons one|http://commons.apache.org/ognl/benchmark-commons-ognl.html]. Furthermore, to make more complex what is already enough, there are even: # http://commons.apache.org/ognl/org.apache.commons.ognl.performance.PerformanceCommonsOgnlTest.html # http://commons.apache.org/ognl/org.apache.commons.ognl.performance.PerformanceOldOgnlTest.html But I'm not happy with the way they represent the difference between the old and the common approach. What is the best way to show the performance increment? > Link "Benchmarks" on left hand navigation is broken > --- > > Key: OGNL-36 > URL: https://issues.apache.org/jira/browse/OGNL-36 > Project: OGNL > Issue Type: Bug >Reporter: Adrian Cumiskey >Assignee: Maurizio Cucchiara >Priority: Minor > Attachments: patch-OGNL36.txt > > > The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken > link to "Benchmarks" on the left hand navigation of the OGNL homepage. -- 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] (NET-231) ParserInitializationException for a couple of server types (AS/400 and UNKNOWN Type: L8)
[
https://issues.apache.org/jira/browse/NET-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-231:
-
Fix Version/s: 1.5
> ParserInitializationException for a couple of server types (AS/400 and
> UNKNOWN Type: L8)
>
>
> Key: NET-231
> URL: https://issues.apache.org/jira/browse/NET-231
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Rob Weaver
>Priority: Minor
> Fix For: 1.5
>
> Attachments: type_l8_1.5.patch
>
>
> Was getting an error when connecting to one of our vendor file servers that
> was returning "215 UNKNOWN Type: L8" for a SYST command.
> The DefaultFTPFileEntryParserFactory does a toUpperCase on the key, which was
> then being compared to the constant SYST_L8.
> That constant was "Type: L8", so it could never match.
> Also some systems respond as "AS/400" instead of "OS/400", so added the check
> for that string.
> Patch below and attached for 1.5, see issue NET-320 for patch for 2.0
> # This patch file was generated by NetBeans IDE
> # Following Index: paths are relative to: C:\Documents and Settings\robw\My
> Documents\NetBeansProjects\trunk
> # This patch can be applied using context Tools: Patch action on respective
> folder.
> # It uses platform neutral UTF-8 encoding and \n newlines.
> # Above lines and this line are ignored by the patching process.
> Index: src/java/org/apache/commons/net/ftp/FTPClientConfig.java
> --- src/java/org/apache/commons/net/ftp/FTPClientConfig.java Base (BASE)
> +++ src/java/org/apache/commons/net/ftp/FTPClientConfig.java Locally Modified
> (Based On LOCAL)
> @@ -171,7 +171,13 @@
> */
> public static final String SYST_OS400 = "OS/400";
>
> +
> /**
> + * Alternate SYST value for an AS/400 system.
> + */
> +public static final String SYST_AS400 = "AS/400";
> +
> +/**
> * Identifier by which an MVS-based ftp server is known throughout
> * the commons-net ftp system.
> */
> @@ -185,7 +191,7 @@
> *
> * @since 1.5
> */
> -public static final String SYST_L8 = "Type: L8";
> +public static final String SYST_L8 = "TYPE: L8";
>
> /**
> * Identifier by which an Netware-based ftp server is known throughout
> Index:
> src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
> ---
> src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
> Base (BASE)
> +++
> src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
> Locally Modified (Based On LOCAL)
> @@ -109,7 +109,8 @@
> {
> parser = createOS2FTPEntryParser();
> }
> -else if (ukey.indexOf(FTPClientConfig.SYST_OS400) >= 0)
> +else if ((ukey.indexOf(FTPClientConfig.SYST_OS400) >= 0)
> +|| (ukey.indexOf(FTPClientConfig.SYST_AS400) >= 0))
> {
> parser = createOS400FTPEntryParser();
> }
> Index:
> src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
> ---
> src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
> Base (BASE)
> +++
> src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
> Locally Modified (Based On LOCAL)
> @@ -62,6 +62,15 @@
> parser = factory.createFileEntryParser("OS/400");
> assertTrue(parser instanceof CompositeFileEntryParser);
>
> +parser = factory.createFileEntryParser("AS/400");
> +assertTrue(parser instanceof CompositeFileEntryParser);
> +
> +// Added test to make sure it handles the Unix systems that were
> +// compiled with OS as "UNKNOWN". This test validates that the
> +// check is case-insensitive.
> +parser = factory.createFileEntryParser("UNKNOWN Type: L8");
> +
> +
> try {
> parser = factory.createFileEntryParser("OS2FTPFileEntryParser");
> fail("Exception should have been thrown.
> \"OS2FTPFileEntryParser\" is not a recognized key");
--
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] (NET-416) Increasing sub-negotiation message holder array size
[ https://issues.apache.org/jira/browse/NET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-416: - Fix Version/s: 3.1 > Increasing sub-negotiation message holder array size > > > Key: NET-416 > URL: https://issues.apache.org/jira/browse/NET-416 > Project: Commons Net > Issue Type: Improvement > Components: Telnet >Affects Versions: 3.0, 3.0.1 > Environment: Linux >Reporter: Abhijeet Gaikwad > Labels: authentication, linux, ntlm, telnet > Fix For: 3.1 > > Attachments: NTLM_Auth_Support.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I am trying to achieve NTLM Authentication by extending the Telnet option > handler. The challenge sent by the telnet server is greater than 256 bytes, > but currently the __suboption[] array in TelnetInputStream supports only a > 256 bytes message. If I increase the size of the array to 512, I am able to > achieve NTLM Authentication. -- 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] (NET-415) typo in migration how-to
[ https://issues.apache.org/jira/browse/NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-415: - Affects Version/s: 3.0.1 Fix Version/s: 3.1 > typo in migration how-to > > > Key: NET-415 > URL: https://issues.apache.org/jira/browse/NET-415 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.0.1 > Environment: All >Reporter: george thomas >Priority: Trivial > Labels: documentation > Fix For: 3.1 > > > Please correct "occurances" to "occurrences" under the section "NetComponents > 1.3.8 to Commons Net 1.x" on the migration HOWTO page > (http://commons.apache.org/net/migration.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
[jira] [Updated] (NET-428) SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( "1.2.3.4/32" ).getInfo().getAllAddresses()
[ https://issues.apache.org/jira/browse/NET-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-428: - Fix Version/s: 3.1 > SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( > "1.2.3.4/32" ).getInfo().getAllAddresses() > - > > Key: NET-428 > URL: https://issues.apache.org/jira/browse/NET-428 > Project: Commons Net > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Sebb > Fix For: 3.1 > > > new SubnetUtils( "1.2.3.4/32" ).getInfo().getAllAddresses() throws > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > $SubnetInfo.getAllAddresses(SubnetUtils.java:166) > Similarly for /31 > It would make more sense to return an empty array. -- 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] (NET-425) _openDataConnection_, __storeFile, and __storeFileStream should be protected and take String for FTP command.
[ https://issues.apache.org/jira/browse/NET-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-425: - Affects Version/s: 3.0.1 Fix Version/s: 3.1 > _openDataConnection_, __storeFile, and __storeFileStream should be protected > and take String for FTP command. > - > > Key: NET-425 > URL: https://issues.apache.org/jira/browse/NET-425 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.0.1 > Environment: All >Reporter: Steven Jardine > Fix For: 3.1 > > Attachments: patch.txt > > > Currently __storeFile, __storeStream, and _openConnection_ are declared as > private and only receive int commands. I am trying to extend the FTPClient > class to implement specialized commands that utilize these methods. In order > for this to work I need to have these methods declared as protected as well > as adjust the parameters to allow for String commands. -- 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] (NET-425) _openDataConnection_, __storeFile, and __storeFileStream should be protected and take String for FTP command.
[ https://issues.apache.org/jira/browse/NET-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-425. -- Resolution: Fixed > _openDataConnection_, __storeFile, and __storeFileStream should be protected > and take String for FTP command. > - > > Key: NET-425 > URL: https://issues.apache.org/jira/browse/NET-425 > Project: Commons Net > Issue Type: Improvement > Components: FTP > Environment: All >Reporter: Steven Jardine > Attachments: patch.txt > > > Currently __storeFile, __storeStream, and _openConnection_ are declared as > private and only receive int commands. I am trying to extend the FTPClient > class to implement specialized commands that utilize these methods. In order > for this to work I need to have these methods declared as protected as well > as adjust the parameters to allow for String commands. -- 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-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[
https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened DAEMON-222:
---
Breaks other builds now:
{noformat}
gcc -g -O2 -DOS_FREEBSD -DDSO_DLFCN -D_THREAD_SAFE -pthread -DCPU=\"i386\"
-Wall -Wstrict-prototypes -I/usr/local/diablo-jdk1.6.0/include
-I/usr/local/diablo-jdk1.6.0/include/freebsd -c jsvc-unix.c -o jsvc-unix.o
jsvc-unix.c: In function 'child':
jsvc-unix.c:744: error: 'arg_data' has no member named 'procname'
jsvc-unix.c: In function 'main':
jsvc-unix.c:1097: error: 'arg_data' has no member named 'procname'
*** Error code 1
Stop in /.amd_mnt/blnn728x/home/osipovmi/Projekte/daemon-unix/native.
*** Error code 1
Stop in /.amd_mnt/blnn728x/home/osipovmi/Projekte/daemon-unix.
{noformat}
> Remove 'procname' option with preprocessor condition if OS is not Linux
> ---
>
> Key: DAEMON-222
> URL: https://issues.apache.org/jira/browse/DAEMON-222
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Jsvc
>Affects Versions: 1.0.7
>Reporter: Michael Osipov
>Assignee: Mladen Turk
> Fix For: 1.0.7
>
>
> The procname option can only be used on Linux. It would be removed by the
> preprocessor if the target OS is not Linux.
--
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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141229#comment-13141229 ] Michael Osipov commented on DAEMON-220: --- Mladen, AP_FIND_JAVA is still broken. It assumes with "which java" that the top dir is the JDK. Which might not be the case. I have adapted the function from libtcnative just like you did with the include dir. > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DAEMON-220: -- Attachment: DAEMON-220.patch > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened DAEMON-220: --- AP_FIND_JAVA is still incomplete > Clean up configure/configure.in scripts > --- > > Key: DAEMON-220 > URL: https://issues.apache.org/jira/browse/DAEMON-220 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.7 >Reporter: Michael Osipov >Assignee: Mladen Turk > Attachments: DAEMON-220.patch > > > The current configure script has several deficiencies at the moment.No > CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. > Issue has been raised on the mailing list: > http://www.mail-archive.com/user@commons.apache.org/msg07101.html > It needs a complete overhaul. -- 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] (NET-416) Increasing sub-negotiation message holder array size
[ https://issues.apache.org/jira/browse/NET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-416. -- Resolution: Fixed > Increasing sub-negotiation message holder array size > > > Key: NET-416 > URL: https://issues.apache.org/jira/browse/NET-416 > Project: Commons Net > Issue Type: Improvement > Components: Telnet >Affects Versions: 3.0, 3.0.1 > Environment: Linux >Reporter: Abhijeet Gaikwad > Labels: authentication, linux, ntlm, telnet > Attachments: NTLM_Auth_Support.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I am trying to achieve NTLM Authentication by extending the Telnet option > handler. The challenge sent by the telnet server is greater than 256 bytes, > but currently the __suboption[] array in TelnetInputStream supports only a > 256 bytes message. If I increase the size of the array to 512, I am able to > achieve NTLM Authentication. -- 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] (NET-231) ParserInitializationException for a couple of server types (AS/400 and UNKNOWN Type: L8)
[
https://issues.apache.org/jira/browse/NET-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-231.
--
Resolution: Fixed
> ParserInitializationException for a couple of server types (AS/400 and
> UNKNOWN Type: L8)
>
>
> Key: NET-231
> URL: https://issues.apache.org/jira/browse/NET-231
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Rob Weaver
>Priority: Minor
> Attachments: type_l8_1.5.patch
>
>
> Was getting an error when connecting to one of our vendor file servers that
> was returning "215 UNKNOWN Type: L8" for a SYST command.
> The DefaultFTPFileEntryParserFactory does a toUpperCase on the key, which was
> then being compared to the constant SYST_L8.
> That constant was "Type: L8", so it could never match.
> Also some systems respond as "AS/400" instead of "OS/400", so added the check
> for that string.
> Patch below and attached for 1.5, see issue NET-320 for patch for 2.0
> # This patch file was generated by NetBeans IDE
> # Following Index: paths are relative to: C:\Documents and Settings\robw\My
> Documents\NetBeansProjects\trunk
> # This patch can be applied using context Tools: Patch action on respective
> folder.
> # It uses platform neutral UTF-8 encoding and \n newlines.
> # Above lines and this line are ignored by the patching process.
> Index: src/java/org/apache/commons/net/ftp/FTPClientConfig.java
> --- src/java/org/apache/commons/net/ftp/FTPClientConfig.java Base (BASE)
> +++ src/java/org/apache/commons/net/ftp/FTPClientConfig.java Locally Modified
> (Based On LOCAL)
> @@ -171,7 +171,13 @@
> */
> public static final String SYST_OS400 = "OS/400";
>
> +
> /**
> + * Alternate SYST value for an AS/400 system.
> + */
> +public static final String SYST_AS400 = "AS/400";
> +
> +/**
> * Identifier by which an MVS-based ftp server is known throughout
> * the commons-net ftp system.
> */
> @@ -185,7 +191,7 @@
> *
> * @since 1.5
> */
> -public static final String SYST_L8 = "Type: L8";
> +public static final String SYST_L8 = "TYPE: L8";
>
> /**
> * Identifier by which an Netware-based ftp server is known throughout
> Index:
> src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
> ---
> src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
> Base (BASE)
> +++
> src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
> Locally Modified (Based On LOCAL)
> @@ -109,7 +109,8 @@
> {
> parser = createOS2FTPEntryParser();
> }
> -else if (ukey.indexOf(FTPClientConfig.SYST_OS400) >= 0)
> +else if ((ukey.indexOf(FTPClientConfig.SYST_OS400) >= 0)
> +|| (ukey.indexOf(FTPClientConfig.SYST_AS400) >= 0))
> {
> parser = createOS400FTPEntryParser();
> }
> Index:
> src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
> ---
> src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
> Base (BASE)
> +++
> src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
> Locally Modified (Based On LOCAL)
> @@ -62,6 +62,15 @@
> parser = factory.createFileEntryParser("OS/400");
> assertTrue(parser instanceof CompositeFileEntryParser);
>
> +parser = factory.createFileEntryParser("AS/400");
> +assertTrue(parser instanceof CompositeFileEntryParser);
> +
> +// Added test to make sure it handles the Unix systems that were
> +// compiled with OS as "UNKNOWN". This test validates that the
> +// check is case-insensitive.
> +parser = factory.createFileEntryParser("UNKNOWN Type: L8");
> +
> +
> try {
> parser = factory.createFileEntryParser("OS2FTPFileEntryParser");
> fail("Exception should have been thrown.
> \"OS2FTPFileEntryParser\" is not a recognized key");
--
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] (NET-428) SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( "1.2.3.4/32" ).getInfo().getAllAddresses()
[ https://issues.apache.org/jira/browse/NET-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-428. -- Resolution: Fixed > SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( > "1.2.3.4/32" ).getInfo().getAllAddresses() > - > > Key: NET-428 > URL: https://issues.apache.org/jira/browse/NET-428 > Project: Commons Net > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Sebb > > new SubnetUtils( "1.2.3.4/32" ).getInfo().getAllAddresses() throws > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > $SubnetInfo.getAllAddresses(SubnetUtils.java:166) > Similarly for /31 > It would make more sense to return an empty array. -- 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] (NET-428) SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( "1.2.3.4/32" ).getInfo().getAllAddresses()
SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( "1.2.3.4/32" ).getInfo().getAllAddresses() - Key: NET-428 URL: https://issues.apache.org/jira/browse/NET-428 Project: Commons Net Issue Type: Bug Affects Versions: 3.0.1 Reporter: Sebb new SubnetUtils( "1.2.3.4/32" ).getInfo().getAllAddresses() throws Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 $SubnetInfo.getAllAddresses(SubnetUtils.java:166) Similarly for /31 It would make more sense to return an empty array. -- 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] (FUNCTOR-9) [PATCH] Make Limit and Offset Serializable
[ https://issues.apache.org/jira/browse/FUNCTOR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated FUNCTOR-9: - Attachment: FUNCTOR-9.patch > [PATCH] Make Limit and Offset Serializable > -- > > Key: FUNCTOR-9 > URL: https://issues.apache.org/jira/browse/FUNCTOR-9 > Project: Commons Functor > Issue Type: Improvement > Environment: Win7 Enterprise, jdk-1.6.0_27, Eclipse Galileo >Reporter: Bruno P. Kinoshita >Priority: Minor > Attachments: FUNCTOR-9.patch > > > In org.apache.commons.functor.core all classes that are in someway a Functor > implement Serializable, with exception of Limit and Offset (as pointed by E. > Bourg in the mailing list). This patch marks both classes as Serializable and > includes equals() and hashcode() methods. > Notice that these changes are already covered by the test > org.apache.commons.functor.BaseFunctorTest#testSerializeDeserializeThenCompare. > > Bruno P. Kinoshita -- 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] (FUNCTOR-9) [PATCH] Make Limit and Offset Serializable
[PATCH] Make Limit and Offset Serializable -- Key: FUNCTOR-9 URL: https://issues.apache.org/jira/browse/FUNCTOR-9 Project: Commons Functor Issue Type: Improvement Environment: Win7 Enterprise, jdk-1.6.0_27, Eclipse Galileo Reporter: Bruno P. Kinoshita Priority: Minor In org.apache.commons.functor.core all classes that are in someway a Functor implement Serializable, with exception of Limit and Offset (as pointed by E. Bourg in the mailing list). This patch marks both classes as Serializable and includes equals() and hashcode() methods. Notice that these changes are already covered by the test org.apache.commons.functor.BaseFunctorTest#testSerializeDeserializeThenCompare. Bruno P. Kinoshita -- 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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[ https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141151#comment-13141151 ] Adrian Cumiskey commented on OGNL-36: - Nice graph! :-) > Link "Benchmarks" on left hand navigation is broken > --- > > Key: OGNL-36 > URL: https://issues.apache.org/jira/browse/OGNL-36 > Project: OGNL > Issue Type: Bug >Reporter: Adrian Cumiskey >Assignee: Maurizio Cucchiara >Priority: Minor > Attachments: patch-OGNL36.txt > > > The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken > link to "Benchmarks" on the left hand navigation of the OGNL homepage. -- 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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[ https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141113#comment-13141113 ] Simone Tripodi commented on OGNL-36: Page link is redundant, http://commons.apache.org/ognl/benchmark-commons-ognl.html could be just http://commons.apache.org/ognl/benchmark.html, we already know it is related to commons-ognl. > Link "Benchmarks" on left hand navigation is broken > --- > > Key: OGNL-36 > URL: https://issues.apache.org/jira/browse/OGNL-36 > Project: OGNL > Issue Type: Bug >Reporter: Adrian Cumiskey >Assignee: Maurizio Cucchiara >Priority: Minor > Attachments: patch-OGNL36.txt > > > The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken > link to "Benchmarks" on the left hand navigation of the OGNL homepage. -- 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-700) Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise constant functions
[
https://issues.apache.org/jira/browse/MATH-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141103#comment-13141103
]
Gilles commented on MATH-700:
-
We could create a new "bracket" method with an additional boolean parameter to
indicate whether "strict" bracketing is required.
> Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise
> constant functions
>
>
> Key: MATH-700
> URL: https://issues.apache.org/jira/browse/MATH-700
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
>
> The current contract of
> {{o.a.c.m.analysis.solvers.UnivariateRealSolverUtils.bracket(UnivariateRealFunction
> function, double initial, double lowerBound, double upperBound, int
> maximumIterations)}} states that
> {quote}
> This method attempts to find two values a and b satisfying
> * {{lowerBound <= a < initial < b <= upperBound}}
> * {{f(a) * f(b) <= 0}}
> If f is continuous on [a,b], this means that a and b bracket a root of f.
> {quote}
> I don't think there is any problem with the current implementation. However,
> if f is constant, equal to zero on a whole interval, this implementation does
> not guarantee that the whole interval is bracketed. I therefore propose that
> the contract is changed to
> * {{f(a) * f(b) < 0}}
> This entails only a minor correction to the {{bracket()}} method: line 267 of
> UnivariateRealSolverUtils currently reads
> ...{{while ((fa * fb > 0.0) && (numIterations < maximumIterations)}}...
> I think it would be safe to replace this line with
> ...{{while ((fa * fb >= 0.0) && (numIterations < maximumIterations)}}...
> Do you agree in principle? I'll run the current tests to check that this
> change is indeed safe.
--
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] (FUNCTOR-8) [PATCH] Possible NPE in TransformedGenerator if getWrappedGenerator() is overridden to return null
[
https://issues.apache.org/jira/browse/FUNCTOR-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated FUNCTOR-8:
-
Attachment: FUNCTOR-8-tests.patch
FUNCTOR-8-tests.patch includes a unit test for FUNCTOR-8.patch.
I attached a separated file for part of this class is also contained in
FUNCTOR-7.patch, so it may help while committing it if FUNCTOR-7 has already
been applied.
> [PATCH] Possible NPE in TransformedGenerator if getWrappedGenerator() is
> overridden to return null
> --
>
> Key: FUNCTOR-8
> URL: https://issues.apache.org/jira/browse/FUNCTOR-8
> Project: Commons Functor
> Issue Type: Bug
> Environment: ubuntu 11.10, sun-jdk-6, eclipse galileo
>Reporter: Bruno P. Kinoshita
> Attachments: FUNCTOR-8-tests.patch, FUNCTOR-8.patch
>
>
> If we override getWrappedGenerator method in TransformedGenerator to return
> null, it may result in a NullPointerException if hashCode is called.
> Attached the patch for it, and below a snippet of code to reproduce this
> issue.
> TransformedGenerator t = new
> TransformedGenerator(
> new IntegerRange(1, 10), new UnaryFunction() {
> public Integer evaluate(Integer obj) {
> return obj += 1;
> }
> }) {
> @Override
> protected Generator getWrappedGenerator() {
> return null;
> }
> };
> TransformedGenerator t2 = new
> TransformedGenerator(
> new IntegerRange(1, 10), new UnaryFunction() {
> public Integer evaluate(Integer obj) {
> return obj -= 1;
> }
> });
> System.out.println(t.equals(t2));
> System.out.println(t.hashCode() == t2.hashCode()); // NPE
> Cheers,
> Bruno P. Kinoshita
--
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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[ https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maurizio Cucchiara resolved OGNL-36. Resolution: Fixed Assignee: Maurizio Cucchiara Wrong link, now it works. > Link "Benchmarks" on left hand navigation is broken > --- > > Key: OGNL-36 > URL: https://issues.apache.org/jira/browse/OGNL-36 > Project: OGNL > Issue Type: Bug >Reporter: Adrian Cumiskey >Assignee: Maurizio Cucchiara >Priority: Minor > Attachments: patch-OGNL36.txt > > > The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken > link to "Benchmarks" on the left hand navigation of the OGNL homepage. -- 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-700) Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise constant functions
[
https://issues.apache.org/jira/browse/MATH-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141069#comment-13141069
]
Sébastien Brisard commented on MATH-700:
Thanks for this counter-example. This proposal actually comes from MATH-699. To
solve this bug, I think I need to alter the default bracketing method. I was
just wondering if this alteration would be useful to other parts of CM. It it's
not, then I can define a custom protected bracketing method within
{{AbstractDistribution}}.
> Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise
> constant functions
>
>
> Key: MATH-700
> URL: https://issues.apache.org/jira/browse/MATH-700
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
>
> The current contract of
> {{o.a.c.m.analysis.solvers.UnivariateRealSolverUtils.bracket(UnivariateRealFunction
> function, double initial, double lowerBound, double upperBound, int
> maximumIterations)}} states that
> {quote}
> This method attempts to find two values a and b satisfying
> * {{lowerBound <= a < initial < b <= upperBound}}
> * {{f(a) * f(b) <= 0}}
> If f is continuous on [a,b], this means that a and b bracket a root of f.
> {quote}
> I don't think there is any problem with the current implementation. However,
> if f is constant, equal to zero on a whole interval, this implementation does
> not guarantee that the whole interval is bracketed. I therefore propose that
> the contract is changed to
> * {{f(a) * f(b) < 0}}
> This entails only a minor correction to the {{bracket()}} method: line 267 of
> UnivariateRealSolverUtils currently reads
> ...{{while ((fa * fb > 0.0) && (numIterations < maximumIterations)}}...
> I think it would be safe to replace this line with
> ...{{while ((fa * fb >= 0.0) && (numIterations < maximumIterations)}}...
> Do you agree in principle? I'll run the current tests to check that this
> change is indeed safe.
--
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-700) Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise constant functions
[
https://issues.apache.org/jira/browse/MATH-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141066#comment-13141066
]
Luc Maisonobe commented on MATH-700:
I don't agree with this change.
It implies that user cannot provide an interval that ends exactly at a root,
they must enlarge their interval and then wait for the algorithm to reduce it
back. When a root is at the boundary of a function definition interval (think
about finding the root for sqrt(x)), enlarging the interval is not only
cumbersome, it triggers an error.
> Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise
> constant functions
>
>
> Key: MATH-700
> URL: https://issues.apache.org/jira/browse/MATH-700
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
>
> The current contract of
> {{o.a.c.m.analysis.solvers.UnivariateRealSolverUtils.bracket(UnivariateRealFunction
> function, double initial, double lowerBound, double upperBound, int
> maximumIterations)}} states that
> {quote}
> This method attempts to find two values a and b satisfying
> * {{lowerBound <= a < initial < b <= upperBound}}
> * {{f(a) * f(b) <= 0}}
> If f is continuous on [a,b], this means that a and b bracket a root of f.
> {quote}
> I don't think there is any problem with the current implementation. However,
> if f is constant, equal to zero on a whole interval, this implementation does
> not guarantee that the whole interval is bracketed. I therefore propose that
> the contract is changed to
> * {{f(a) * f(b) < 0}}
> This entails only a minor correction to the {{bracket()}} method: line 267 of
> UnivariateRealSolverUtils currently reads
> ...{{while ((fa * fb > 0.0) && (numIterations < maximumIterations)}}...
> I think it would be safe to replace this line with
> ...{{while ((fa * fb >= 0.0) && (numIterations < maximumIterations)}}...
> Do you agree in principle? I'll run the current tests to check that this
> change is indeed safe.
--
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-700) Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise constant functions
[
https://issues.apache.org/jira/browse/MATH-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141041#comment-13141041
]
Sébastien Brisard commented on MATH-700:
With the proposed modification, the following unit test actually fails.
{{org.apache.commons.math.analysis.solvers.UnivariateRealSolverUtilsTest:111}}
I'll look into it.
> Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise
> constant functions
>
>
> Key: MATH-700
> URL: https://issues.apache.org/jira/browse/MATH-700
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
>
> The current contract of
> {{o.a.c.m.analysis.solvers.UnivariateRealSolverUtils.bracket(UnivariateRealFunction
> function, double initial, double lowerBound, double upperBound, int
> maximumIterations)}} states that
> {quote}
> This method attempts to find two values a and b satisfying
> * {{lowerBound <= a < initial < b <= upperBound}}
> * {{f(a) * f(b) <= 0}}
> If f is continuous on [a,b], this means that a and b bracket a root of f.
> {quote}
> I don't think there is any problem with the current implementation. However,
> if f is constant, equal to zero on a whole interval, this implementation does
> not guarantee that the whole interval is bracketed. I therefore propose that
> the contract is changed to
> * {{f(a) * f(b) < 0}}
> This entails only a minor correction to the {{bracket()}} method: line 267 of
> UnivariateRealSolverUtils currently reads
> ...{{while ((fa * fb > 0.0) && (numIterations < maximumIterations)}}...
> I think it would be safe to replace this line with
> ...{{while ((fa * fb >= 0.0) && (numIterations < maximumIterations)}}...
> Do you agree in principle? I'll run the current tests to check that this
> change is indeed safe.
--
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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[ https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141036#comment-13141036 ] Hudson commented on OGNL-36: Integrated in ognl #178 (See [https://builds.apache.org/job/ognl/178/]) OGNL-36 - Link "Benchmarks" on left hand navigation is broken (contributed by Adrian Cumiskey). mcucchiara : http://svn.apache.org/viewvc/?view=rev&rev=1195879 Files : * /commons/proper/ognl/trunk/src/changes/changes.xml * /commons/proper/ognl/trunk/src/site/site.xml > Link "Benchmarks" on left hand navigation is broken > --- > > Key: OGNL-36 > URL: https://issues.apache.org/jira/browse/OGNL-36 > Project: OGNL > Issue Type: Bug >Reporter: Adrian Cumiskey >Priority: Minor > Attachments: patch-OGNL36.txt > > > The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken > link to "Benchmarks" on the left hand navigation of the OGNL homepage. -- 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-226) support files have incorrect svn:eol-style
[ https://issues.apache.org/jira/browse/DAEMON-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DAEMON-226: -- Attachment: DAEMON-226.patch > support files have incorrect svn:eol-style > -- > > Key: DAEMON-226 > URL: https://issues.apache.org/jira/browse/DAEMON-226 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: Nightly Builds >Reporter: Michael Osipov > Attachments: DAEMON-226.patch > > > I have checked out under Windows and copied an exported tar to a unix system. > All files contained ^M. This is not a issue if you checkout under Unix but in > my case I do not have an svn client and have to do this way. > Anyway, the eol-style should always be LF because these files are for Unix > only. > I have attached a patch for. -- 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] (DAEMON-226) support files have incorrect svn:eol-style
support files have incorrect svn:eol-style -- Key: DAEMON-226 URL: https://issues.apache.org/jira/browse/DAEMON-226 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: Nightly Builds Reporter: Michael Osipov I have checked out under Windows and copied an exported tar to a unix system. All files contained ^M. This is not a issue if you checkout under Unix but in my case I do not have an svn client and have to do this way. Anyway, the eol-style should always be LF because these files are for Unix only. I have attached a patch for. -- 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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-699: --- Description: 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. (was: This bug report follows MATH-692. The attached unit test fails.) > 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 > > > 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] [Created] (MATH-700) Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise constant functions
Alter the contract of UnivariateRealSolverUtils.bracket() to handle piecewise
constant functions
Key: MATH-700
URL: https://issues.apache.org/jira/browse/MATH-700
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
The current contract of
{{o.a.c.m.analysis.solvers.UnivariateRealSolverUtils.bracket(UnivariateRealFunction
function, double initial, double lowerBound, double upperBound, int
maximumIterations)}} states that
{quote}
This method attempts to find two values a and b satisfying
* {{lowerBound <= a < initial < b <= upperBound}}
* {{f(a) * f(b) <= 0}}
If f is continuous on [a,b], this means that a and b bracket a root of f.
{quote}
I don't think there is any problem with the current implementation. However, if
f is constant, equal to zero on a whole interval, this implementation does not
guarantee that the whole interval is bracketed. I therefore propose that the
contract is changed to
* {{f(a) * f(b) < 0}}
This entails only a minor correction to the {{bracket()}} method: line 267 of
UnivariateRealSolverUtils currently reads
...{{while ((fa * fb > 0.0) && (numIterations < maximumIterations)}}...
I think it would be safe to replace this line with
...{{while ((fa * fb >= 0.0) && (numIterations < maximumIterations)}}...
Do you agree in principle? I'll run the current tests to check that this change
is indeed safe.
--
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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-699: --- Attachment: AbstractContinuousDistributionTest.java > 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 > > > This bug report follows MATH-692. The attached unit test fails. -- 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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
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 This bug report follows MATH-692. The attached unit test fails. -- 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] (OGNL-36) Link "Benchmarks" on left hand navigation is broken
[ https://issues.apache.org/jira/browse/OGNL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140996#comment-13140996 ] Simone Tripodi commented on OGNL-36: I bet it is just a matter of deploying the site without disabling the benchmark profile. > Link "Benchmarks" on left hand navigation is broken > --- > > Key: OGNL-36 > URL: https://issues.apache.org/jira/browse/OGNL-36 > Project: OGNL > Issue Type: Bug >Reporter: Adrian Cumiskey >Priority: Minor > Attachments: patch-OGNL36.txt > > > The forrest file src/site/xdoc/benchmark-ognl.xml is missing causing a broken > link to "Benchmarks" on the left hand navigation of the OGNL homepage. -- 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
