[jira] [Created] (FUNCTOR-4) Add easily accessible, user-friendly examples
Add easily accessible, user-friendly examples - Key: FUNCTOR-4 URL: https://issues.apache.org/jira/browse/FUNCTOR-4 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Priority: Minor Perhaps we could add some pages with examples to the project site? As pointed by Emmanuel Bourg, at moment the examples point directly to classes in the SVN. We could add some basic examples and also point to sample code in the SVN, something similar to what is done in DBUtils [1] and Commons-Pool [2]. I'm reading FP for Java Developers, there are some basic examples that could be implemented using Functor and put in the Examples page (I believe grand part is already implemented in the tests classes). [1] http://commons.apache.org/dbutils/examples.html [2] http://commons.apache.org/pool/examples.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] [Created] (MATH-695) Incomplete reinitialization with some events handling
Incomplete reinitialization with some events handling - Key: MATH-695 URL: https://issues.apache.org/jira/browse/MATH-695 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way. I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests. -- 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-426) FTPS: Hook to customize _openDataConnection_ SSLSocket before startHandshake() is called
[
https://issues.apache.org/jira/browse/NET-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135229#comment-13135229
]
Ketan commented on NET-426:
---
Here is code snippet I was playing with. I had this executed before data
connection handshake starting. Note this is for SunJSSE provider since I had
Sun's JVM installed:
SSLSocket sslControlSocket = (SSLSocket) controlConnectionSocket;
String host = host.used.to.connect.to.socket;
try {
SSLSession sess = sslControlSocket.getSession();
SSLSessionContext sessions = sess.getSessionContext();
// SunJSSE 1.6 specific code
Field cache = sessions.getClass().getDeclaredField(
sessionHostPortCache);
cache.setAccessible(true);
Object c = cache.get(sessions);
String key = (host + : + String.valueOf(socket.getPort()))
.toLowerCase();
// Class? cc = Class.forName(sun.security.util.Cache);
Class? cc = c.getClass();
cc.getDeclaredMethod(put, Object.class, Object.class).invoke(
c, key, sess);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
FTPS: Hook to customize _openDataConnection_ SSLSocket before
startHandshake() is called
Key: NET-426
URL: https://issues.apache.org/jira/browse/NET-426
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1
Reporter: Ketan
Priority: Critical
Attachments: FTPSClient.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently in FTPSClient class, there is protected _openDataConnection_
method, which create SSLSocket for data connection. But there is no hook to
customize the SSLSocket before startHandshake is called.
I need to know the remote host ip and port, which i can get for socket, and
do custom setup to try to reuse SSL sessions from control connection socket.
Since the socket factory uses createSocket() method, I can't just use custom
socket factory since I don't know the host and port. I can't just override
the _openDataConnection_() method in my class since that will call the
startHandshake().
So it would be nice if you can provide hook, much like _connectAction_(), but
for data connection before handshake is started. You can pass the new data
socket as argument to this hook method so one can get remote host and port
information.
--
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-695) Incomplete reinitialization with some events handling
[ https://issues.apache.org/jira/browse/MATH-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Parraud updated MATH-695: Attachment: events.patch this patch resolves my problem but breaks some unit tests. Incomplete reinitialization with some events handling - Key: MATH-695 URL: https://issues.apache.org/jira/browse/MATH-695 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Attachments: events.patch I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way. I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests. -- 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] (NET-426) FTPS: Hook to customize _openDataConnection_ SSLSocket before startHandshake() is called
[
https://issues.apache.org/jira/browse/NET-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135229#comment-13135229
]
Ketan edited comment on NET-426 at 10/25/11 4:58 PM:
-
Here is code snippet I was playing with. I had this executed before data
connection handshake starting. Note this is for SunJSSE provider since I had
Sun's JVM installed:
{code:java}
SSLSocket sslControlSocket = (SSLSocket) controlConnectionSocket;
String host = host.used.to.connect.to.socket;
try {
SSLSession sess = sslControlSocket.getSession();
SSLSessionContext sessions = sess.getSessionContext();
// SunJSSE 1.6 specific code
Field cache = sessions.getClass().getDeclaredField(
sessionHostPortCache);
cache.setAccessible(true);
Object c = cache.get(sessions);
String key = (host + : + String.valueOf(socket.getPort()))
.toLowerCase();
// Class? cc = Class.forName(sun.security.util.Cache);
Class? cc = c.getClass();
cc.getDeclaredMethod(put, Object.class, Object.class).invoke(
c, key, sess);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
{code}
was (Author: ktp420):
Here is code snippet I was playing with. I had this executed before data
connection handshake starting. Note this is for SunJSSE provider since I had
Sun's JVM installed:
SSLSocket sslControlSocket = (SSLSocket) controlConnectionSocket;
String host = host.used.to.connect.to.socket;
try {
SSLSession sess = sslControlSocket.getSession();
SSLSessionContext sessions = sess.getSessionContext();
// SunJSSE 1.6 specific code
Field cache = sessions.getClass().getDeclaredField(
sessionHostPortCache);
cache.setAccessible(true);
Object c = cache.get(sessions);
String key = (host + : + String.valueOf(socket.getPort()))
.toLowerCase();
// Class? cc = Class.forName(sun.security.util.Cache);
Class? cc = c.getClass();
cc.getDeclaredMethod(put, Object.class, Object.class).invoke(
c, key, sess);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
FTPS: Hook to customize _openDataConnection_ SSLSocket before
startHandshake() is called
Key: NET-426
URL: https://issues.apache.org/jira/browse/NET-426
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1
Reporter: Ketan
Priority: Critical
Attachments: FTPSClient.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently in FTPSClient class, there is protected _openDataConnection_
method, which create SSLSocket for data connection. But there is no hook to
customize the SSLSocket before startHandshake is called.
I need to know the remote host ip and port, which i can get for socket, and
do custom setup to try to reuse SSL sessions from control connection socket.
Since the socket factory uses createSocket() method, I can't just use custom
socket factory since I don't know the host and port. I can't just override
the _openDataConnection_() method in my class since that will call the
startHandshake().
So it would be nice if you can provide hook, much like _connectAction_(), but
for data connection before handshake is started. You can pass the new data
socket as argument to this hook method so one can get remote host and port
information.
--
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] (NET-426) FTPS: Hook to customize _openDataConnection_ SSLSocket before startHandshake() is called
[
https://issues.apache.org/jira/browse/NET-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135229#comment-13135229
]
Ketan edited comment on NET-426 at 10/25/11 4:58 PM:
-
Here is code snippet I was playing with. I had this executed before data
connection handshake starting. Note this is for SunJSSE provider since I had
Sun's JVM installed:
{code:java}
SSLSocket sslControlSocket = (SSLSocket) controlConnectionSocket;
String host = host.used.to.connect.to.data.socket;
try {
SSLSession sess = sslControlSocket.getSession();
SSLSessionContext sessions = sess.getSessionContext();
// SunJSSE 1.6 specific code
Field cache = sessions.getClass().getDeclaredField(
sessionHostPortCache);
cache.setAccessible(true);
Object c = cache.get(sessions);
String key = (host + : + String.valueOf(socket.getPort()))
.toLowerCase();
// Class? cc = Class.forName(sun.security.util.Cache);
Class? cc = c.getClass();
cc.getDeclaredMethod(put, Object.class, Object.class).invoke(
c, key, sess);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
{code}
was (Author: ktp420):
Here is code snippet I was playing with. I had this executed before data
connection handshake starting. Note this is for SunJSSE provider since I had
Sun's JVM installed:
{code:java}
SSLSocket sslControlSocket = (SSLSocket) controlConnectionSocket;
String host = host.used.to.connect.to.socket;
try {
SSLSession sess = sslControlSocket.getSession();
SSLSessionContext sessions = sess.getSessionContext();
// SunJSSE 1.6 specific code
Field cache = sessions.getClass().getDeclaredField(
sessionHostPortCache);
cache.setAccessible(true);
Object c = cache.get(sessions);
String key = (host + : + String.valueOf(socket.getPort()))
.toLowerCase();
// Class? cc = Class.forName(sun.security.util.Cache);
Class? cc = c.getClass();
cc.getDeclaredMethod(put, Object.class, Object.class).invoke(
c, key, sess);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
{code}
FTPS: Hook to customize _openDataConnection_ SSLSocket before
startHandshake() is called
Key: NET-426
URL: https://issues.apache.org/jira/browse/NET-426
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1
Reporter: Ketan
Priority: Critical
Attachments: FTPSClient.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently in FTPSClient class, there is protected _openDataConnection_
method, which create SSLSocket for data connection. But there is no hook to
customize the SSLSocket before startHandshake is called.
I need to know the remote host ip and port, which i can get for socket, and
do custom setup to try to reuse SSL sessions from control connection socket.
Since the socket factory uses createSocket() method, I can't just use custom
socket factory since I don't know the host and port. I can't just override
the _openDataConnection_() method in my class since that will call the
startHandshake().
So it would be nice if you can provide hook, much like _connectAction_(), but
for data connection before handshake is started. You can pass the new data
socket as argument to this hook method so one can get remote host and port
information.
--
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-695) Incomplete reinitialization with some events handling
[ https://issues.apache.org/jira/browse/MATH-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135234#comment-13135234 ] Sébastien Brisard commented on MATH-695: Hi Pascal, thanks for reporting this bug. In order to be able to help you, we need you to be a little bit more specific as to what algos/packages you're using. I guess you're talking about o.a.c.m.ode, is that correct? If yes, which solver is causing you troubles? In what circumstances? The best would be for you to provide us with a simplified application (since your real use-case is too complicated) reproducing the bug. Otherwise could you send along your patch (even if it breaks the Unit tests), since it would give us some indication on the location of the bug). Best regards, Sébastien Incomplete reinitialization with some events handling - Key: MATH-695 URL: https://issues.apache.org/jira/browse/MATH-695 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Attachments: events.patch I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way. I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests. -- 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-695) Incomplete reinitialization with some events handling
[ https://issues.apache.org/jira/browse/MATH-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-695: --- Comment: was deleted (was: Hi Pascal, thanks for reporting this bug. In order to be able to help you, we need you to be a little bit more specific as to what algos/packages you're using. I guess you're talking about o.a.c.m.ode, is that correct? If yes, which solver is causing you troubles? In what circumstances? The best would be for you to provide us with a simplified application (since your real use-case is too complicated) reproducing the bug. Otherwise could you send along your patch (even if it breaks the Unit tests), since it would give us some indication on the location of the bug). Best regards, Sébastien) Incomplete reinitialization with some events handling - Key: MATH-695 URL: https://issues.apache.org/jira/browse/MATH-695 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Attachments: events.patch I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way. I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests. -- 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] (NET-426) FTPS: Hook to customize _openDataConnection_ SSLSocket before startHandshake() is called
[
https://issues.apache.org/jira/browse/NET-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135229#comment-13135229
]
Ketan edited comment on NET-426 at 10/25/11 5:03 PM:
-
Here is code snippet I was playing with. I had this executed before data
connection handshake starting. Note this is for SunJSSE provider since I had
Sun's JVM installed:
{code:java}
SSLSocket sslControlSocket = (SSLSocket) controlConnectionSocket;
String host = host.used.to.connect.to.data.socket;
int port = dataPort; // dataSocket.getPort();
try {
SSLSession sess = sslControlSocket.getSession();
SSLSessionContext sessions = sess.getSessionContext();
// SunJSSE 1.6 specific code
Field cache = sessions.getClass().getDeclaredField(
sessionHostPortCache);
cache.setAccessible(true);
Object c = cache.get(sessions);
String key = (host + : + String.valueOf(port))
.toLowerCase();
// Class? cc = Class.forName(sun.security.util.Cache);
Class? cc = c.getClass();
cc.getDeclaredMethod(put, Object.class, Object.class).invoke(
c, key, sess);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
{code}
was (Author: ktp420):
Here is code snippet I was playing with. I had this executed before data
connection handshake starting. Note this is for SunJSSE provider since I had
Sun's JVM installed:
{code:java}
SSLSocket sslControlSocket = (SSLSocket) controlConnectionSocket;
String host = host.used.to.connect.to.data.socket;
try {
SSLSession sess = sslControlSocket.getSession();
SSLSessionContext sessions = sess.getSessionContext();
// SunJSSE 1.6 specific code
Field cache = sessions.getClass().getDeclaredField(
sessionHostPortCache);
cache.setAccessible(true);
Object c = cache.get(sessions);
String key = (host + : + String.valueOf(socket.getPort()))
.toLowerCase();
// Class? cc = Class.forName(sun.security.util.Cache);
Class? cc = c.getClass();
cc.getDeclaredMethod(put, Object.class, Object.class).invoke(
c, key, sess);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
{code}
FTPS: Hook to customize _openDataConnection_ SSLSocket before
startHandshake() is called
Key: NET-426
URL: https://issues.apache.org/jira/browse/NET-426
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1
Reporter: Ketan
Priority: Critical
Attachments: FTPSClient.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently in FTPSClient class, there is protected _openDataConnection_
method, which create SSLSocket for data connection. But there is no hook to
customize the SSLSocket before startHandshake is called.
I need to know the remote host ip and port, which i can get for socket, and
do custom setup to try to reuse SSL sessions from control connection socket.
Since the socket factory uses createSocket() method, I can't just use custom
socket factory since I don't know the host and port. I can't just override
the _openDataConnection_() method in my class since that will call the
startHandshake().
So it would be nice if you can provide hook, much like _connectAction_(), but
for data connection before handshake is started. You can pass the new data
socket as argument to this hook method so one can get remote host and port
information.
--
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] (IO-290) Add read/readFully methods to IOUtils
Add read/readFully methods to IOUtils
-
Key: IO-290
URL: https://issues.apache.org/jira/browse/IO-290
Project: Commons IO
Issue Type: New Feature
Reporter: Sebb
When reading from network etc, it's possible for a read to return before it has
read as many bytes as would fit in the buffer.
Sometimes multiple reads are needed to fulfil the request.
It would be useful to have read() versions of the skip() methods.
{code}
int actual = read(Reader, byte buffer [,offset, length]) // returns normally on
EOF
int actual = read(InputStream, char buffer [,offset, length])
int actual = readFully(Reader, byte buffer [,offset, length]) // throws
EOFException
int actual = readFully(InputStream, char buffer [,offset, length])
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FUNCTOR-4) Add easily accessible, user-friendly examples
[ https://issues.apache.org/jira/browse/FUNCTOR-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135244#comment-13135244 ] Matt Benson commented on FUNCTOR-4: --- This is probably possible, but based on the text in preface section 3 we should seek permission IMO, even if the code is not directly copied. Better safe than sorry. Add easily accessible, user-friendly examples - Key: FUNCTOR-4 URL: https://issues.apache.org/jira/browse/FUNCTOR-4 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Priority: Minor Perhaps we could add some pages with examples to the project site? As pointed by Emmanuel Bourg, at moment the examples point directly to classes in the SVN. We could add some basic examples and also point to sample code in the SVN, something similar to what is done in DBUtils [1] and Commons-Pool [2]. I'm reading FP for Java Developers, there are some basic examples that could be implemented using Functor and put in the Examples page (I believe grand part is already implemented in the tests classes). [1] http://commons.apache.org/dbutils/examples.html [2] http://commons.apache.org/pool/examples.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] [Commented] (FUNCTOR-4) Add easily accessible, user-friendly examples
[ https://issues.apache.org/jira/browse/FUNCTOR-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135262#comment-13135262 ] Bruno P. Kinoshita commented on FUNCTOR-4: -- You're right indeed Matt. Thanks for the heads up. Perhaps we could then create just basic examples covering the basics (Functor, Predicate, Procedure, operations on data structures) without using the examples of the book, what would be simpler. Add easily accessible, user-friendly examples - Key: FUNCTOR-4 URL: https://issues.apache.org/jira/browse/FUNCTOR-4 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Priority: Minor Perhaps we could add some pages with examples to the project site? As pointed by Emmanuel Bourg, at moment the examples point directly to classes in the SVN. We could add some basic examples and also point to sample code in the SVN, something similar to what is done in DBUtils [1] and Commons-Pool [2]. I'm reading FP for Java Developers, there are some basic examples that could be implemented using Functor and put in the Examples page (I believe grand part is already implemented in the tests classes). [1] http://commons.apache.org/dbutils/examples.html [2] http://commons.apache.org/pool/examples.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] [Created] (LANG-763) Reintroduce DateUtils.UTC_TIME_ZONE constant
Reintroduce DateUtils.UTC_TIME_ZONE constant
Key: LANG-763
URL: https://issues.apache.org/jira/browse/LANG-763
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.0.1
Reporter: Attila Király
Priority: Minor
In LANG-691 DateUtils.UTC_TIME_ZONE was removed because TimeZone-s are mutable.
However it was a handy constant. So it would be nice if it could be
reintroduced in an immutable way. For example:
- by creating a new static method DateUtils.utcTimeZone() {return
TimeZone.getTimeZone(GMT);}
- or by creating an immutable timezone type (subclassing maybe SimpleTimeZone)
--
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-369) Comppilation Issue
Comppilation Issue
--
Key: VFS-369
URL: https://issues.apache.org/jira/browse/VFS-369
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Cedric Nanni
When I try to compile VFS on my computer I've got compilation errors due maybe
because I use a more recent version of jackrabbit. I patched the code and now
it compiles.
diff -rupN
original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
--- original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
2011-08-18 06:57:10.0 +0200
+++ patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
2011-10-24 20:35:41.0 +0200
@@ -50,7 +50,7 @@ public final class ExceptionConverter
{
try
{
-Element error =
davExc.toXml(DomUtil.BUILDER_FACTORY.newDocumentBuilder().newDocument());
+Element error = davExc.toXml(DomUtil.createDocument());
if (DomUtil.matches(error, DavException.XML_ERROR,
DavConstants.NAMESPACE))
{
if (DomUtil.hasChildElement(error, exception, null))
diff -rupN
original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
--- original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
2011-08-18 06:57:10.0 +0200
+++ patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
2011-10-24 20:35:41.0 +0200
@@ -292,19 +292,17 @@ public class WebdavFileObject extends Ht
URLFileName fileName = (URLFileName) getName();
DavPropertySet properties = getProperties(fileName,
PropFindMethod.PROPFIND_ALL_PROP,
new DavPropertyNameSet(), false);
-@SuppressWarnings(unchecked) // iterator() is documented to
return DavProperty instances
-IteratorDavProperty iter = properties.iterator();
+Iterator iter = properties.iterator();
while (iter.hasNext())
{
-DavProperty property = iter.next();
+DavProperty property = (DavProperty)iter.next();
attributes.put(property.getName().toString(),
property.getValue());
}
properties = getPropertyNames(fileName);
-@SuppressWarnings(unchecked) // iterator() is documented to
return DavProperty instances
-IteratorDavProperty iter2 = properties.iterator();
+Iterator iter2 = properties.iterator();
while (iter2.hasNext())
{
-DavProperty property = iter2.next();
+DavProperty property = (DavProperty)iter2.next();
if (!attributes.containsKey(property.getName().getName()))
{
property = getProperty(fileName, property.getName());
--
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-695) Incomplete reinitialization with some events handling
[ https://issues.apache.org/jira/browse/MATH-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135351#comment-13135351 ] Luc Maisonobe commented on MATH-695: As I work with Pascal (we share the same office at work), I have seen how the bug occur and am trying to set up a simplified test case that reproduces it. It seems that there is a combination of conditions that is not handled properly. We have seen the bu occurring when both following conditions are true: * there are several events occurring in the same integration step * when one of the earliest events occurrence is triggered, it returns RESET_DERIVATIVES In this case, the acceptStep method in AbstractIntegrator returns early from inside the while loop and the remaining events that where expected to occur later on are left in an inconsistent state with respect to the integrator. The t0 and g0 fields in the corresponding EventState still contains values from the beginning of the step, they do not reflect the fact the event has been triggered. This implies that when next step is started with the updated derivatives, since the t0 for the second event is still lagging behind current time, evaluateStep tries to catch up from t0 to current t and calls the g function at times that do not belong to the current step. Up to now, I have not been able to set up a simplified test case that exhibits this, but I'm working on it. Incomplete reinitialization with some events handling - Key: MATH-695 URL: https://issues.apache.org/jira/browse/MATH-695 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Attachments: events.patch I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way. I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests. -- 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-695) Incomplete reinitialization with some events handling
[ https://issues.apache.org/jira/browse/MATH-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135351#comment-13135351 ] Luc Maisonobe edited comment on MATH-695 at 10/25/11 7:28 PM: -- As I work with Pascal (we share the same office at work), I have seen how the bug occurs and am trying to set up a simplified test case that reproduces it. It seems that there is a combination of conditions that is not handled properly. We have seen the bug occurring when both following conditions are true: * there are several events occurring in the same integration step * when one of the earliest events occurrence is triggered, it returns RESET_DERIVATIVES In this case, the acceptStep method in AbstractIntegrator returns early from inside the while loop and the remaining events that where expected to occur later on are left in an inconsistent state with respect to the integrator. The t0 and g0 fields in the corresponding EventState instance still contain values from the beginning of the step, they do not reflect the fact the event has been triggered. This implies that when next step is started with the updated derivatives, evaluateStep tries to catch up from t0 to current t and calls the g function at times that do not belong to the current step. Up to now, I have not been able to set up a simplified test case that exhibits this, but I'm working on it. was (Author: luc): As I work with Pascal (we share the same office at work), I have seen how the bug occur and am trying to set up a simplified test case that reproduces it. It seems that there is a combination of conditions that is not handled properly. We have seen the bu occurring when both following conditions are true: * there are several events occurring in the same integration step * when one of the earliest events occurrence is triggered, it returns RESET_DERIVATIVES In this case, the acceptStep method in AbstractIntegrator returns early from inside the while loop and the remaining events that where expected to occur later on are left in an inconsistent state with respect to the integrator. The t0 and g0 fields in the corresponding EventState still contains values from the beginning of the step, they do not reflect the fact the event has been triggered. This implies that when next step is started with the updated derivatives, since the t0 for the second event is still lagging behind current time, evaluateStep tries to catch up from t0 to current t and calls the g function at times that do not belong to the current step. Up to now, I have not been able to set up a simplified test case that exhibits this, but I'm working on it. Incomplete reinitialization with some events handling - Key: MATH-695 URL: https://issues.apache.org/jira/browse/MATH-695 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Attachments: events.patch I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way. I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests. -- 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-5) Complete the javadoc description of Limit
Complete the javadoc description of Limit - Key: FUNCTOR-5 URL: https://issues.apache.org/jira/browse/FUNCTOR-5 Project: Commons Functor Issue Type: Task Reporter: Bruno P. Kinoshita Priority: Trivial Attachments: FUNCTOR-5.patch As pointed by Emmanuel, the class Limit's javadoc says: A predicate that returns true the first n times it is invoked. While Offset's javadoc says: A predicate that returns false the first n times it is invoked, and true thereafter. The description of Limit could be updated to match with Offset. -- 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-5) Complete the javadoc description of Limit
[ https://issues.apache.org/jira/browse/FUNCTOR-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated FUNCTOR-5: - Attachment: FUNCTOR-5.patch The patch attached contains a change in Limit to complete its javadoc description. Complete the javadoc description of Limit - Key: FUNCTOR-5 URL: https://issues.apache.org/jira/browse/FUNCTOR-5 Project: Commons Functor Issue Type: Task Reporter: Bruno P. Kinoshita Priority: Trivial Attachments: FUNCTOR-5.patch As pointed by Emmanuel, the class Limit's javadoc says: A predicate that returns true the first n times it is invoked. While Offset's javadoc says: A predicate that returns false the first n times it is invoked, and true thereafter. The description of Limit could be updated to match with Offset. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[
https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135390#comment-13135390
]
Simone Tripodi commented on CHAIN-61:
-
Hi Elijah,
thanks for your contribution! Unfortunately I sadly got issues when applying
the patch :(
{code}
commons-chain simonetripodi$ patch -p0 ~/Downloads/chain-61.diff
patching file
src/test/java/org/apache/commons/chain/impl/NonDelegatingFilter.java
Hunk #1 succeeded at 29 with fuzz 1.
patching file src/test/java/org/apache/commons/chain/impl/DelegatingFilter.java
Hunk #1 succeeded at 29 with fuzz 1.
patching file src/main/java/org/apache/commons/chain/impl/ContextBase.java
Hunk #1 succeeded at 52 with fuzz 1.
patching file src/main/java/org/apache/commons/chain/impl/CatalogBase.java
patching file src/main/java/org/apache/commons/chain/config/ConfigParser.java
patching file
src/main/java/org/apache/commons/chain/config/ConfigRegisterRule.java
patching file
src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java
patching file
src/main/java/org/apache/commons/chain/web/servlet/ServletPathMapper.java
patching file
src/main/java/org/apache/commons/chain/web/servlet/PathInfoMapper.java
patching file
src/main/java/org/apache/commons/chain/web/servlet/ServletParamValuesMap.java
patching file
src/main/java/org/apache/commons/chain/web/servlet/RequestParameterMapper.java
patching file src/main/java/org/apache/commons/chain/web/ChainListener.java
patching file
src/main/java/org/apache/commons/chain/web/portlet/PortletApplicationScopeMap.java
patching file
src/main/java/org/apache/commons/chain/web/portlet/PortletParamMap.java
patching file src/main/java/org/apache/commons/chain/web/ChainResources.java
{code}
Can you help me please? Many thanks in advance!
Chain 2.0 trunk build is throwing many warnings as a result of generification
changes
-
Key: CHAIN-61
URL: https://issues.apache.org/jira/browse/CHAIN-61
Project: Commons Chain
Issue Type: Bug
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-61.diff
Original Estimate: 2h
Remaining Estimate: 2h
When warnings on turned on for build, there are many unchecked conversion
errors. These should be systematically investigated and fixed or given a
@SuppressWarnings(unchecked) where needed.
--
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] (FUNCTOR-5) Complete the javadoc description of Limit
[ https://issues.apache.org/jira/browse/FUNCTOR-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved FUNCTOR-5. -- Resolution: Fixed Assignee: Simone Tripodi patch applied, obrigado Bruno! Complete the javadoc description of Limit - Key: FUNCTOR-5 URL: https://issues.apache.org/jira/browse/FUNCTOR-5 Project: Commons Functor Issue Type: Task Reporter: Bruno P. Kinoshita Assignee: Simone Tripodi Priority: Trivial Attachments: FUNCTOR-5.patch As pointed by Emmanuel, the class Limit's javadoc says: A predicate that returns true the first n times it is invoked. While Offset's javadoc says: A predicate that returns false the first n times it is invoked, and true thereafter. The description of Limit could be updated to match with Offset. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[ https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135413#comment-13135413 ] Elijah Zupancic commented on CHAIN-61: -- Hi Simo, I'm not sure that I understand the errors below. Does a fuzz of one mean that there is a single character difference in whitespace? Outside of the patch warnings, did the patch succeed? I'm doing: svn diff chain-61.diff Does anyone have any advice on making patches? http://httpd.apache.org/dev/patches.html just advises me to use unified diffs and that's what svn uses by default. Since this is the second time that this type of thing has happened, it leaves me wandering if I have some sort of configuration issue with svn. Thanks, -Elijah On Tue, Oct 25, 2011 at 1:18 PM, Simone Tripodi (Commented) (JIRA) Chain 2.0 trunk build is throwing many warnings as a result of generification changes - Key: CHAIN-61 URL: https://issues.apache.org/jira/browse/CHAIN-61 Project: Commons Chain Issue Type: Bug Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 Attachments: chain-61.diff Original Estimate: 2h Remaining Estimate: 2h When warnings on turned on for build, there are many unchecked conversion errors. These should be systematically investigated and fixed or given a @SuppressWarnings(unchecked) where needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[
https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135416#comment-13135416
]
Simone Tripodi commented on CHAIN-61:
-
Hi Elijah,
that is exactly the same way we use at
[commons|http://commons.apache.org/patches.html] :(
Maybe is my svn configuration?
{code}
$ svn --version
svn, version 1.6.16 (r1073529)
compiled Jun 13 2011, 15:54:33
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
{code}
Chain 2.0 trunk build is throwing many warnings as a result of generification
changes
-
Key: CHAIN-61
URL: https://issues.apache.org/jira/browse/CHAIN-61
Project: Commons Chain
Issue Type: Bug
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-61.diff
Original Estimate: 2h
Remaining Estimate: 2h
When warnings on turned on for build, there are many unchecked conversion
errors. These should be systematically investigated and fixed or given a
@SuppressWarnings(unchecked) where needed.
--
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-696) addToEntry and multiplyEntry are abstract in AbstractRealMatrix
addToEntry and multiplyEntry are abstract in AbstractRealMatrix - Key: MATH-696 URL: https://issues.apache.org/jira/browse/MATH-696 Project: Commons Math Issue Type: Improvement Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 3.0 Methods addToEntry and multiplyEntry can have a default implementation instead of being declared abstract. -- 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-6) Make Limit and Offset implement Serializable
Make Limit and Offset implement Serializable Key: FUNCTOR-6 URL: https://issues.apache.org/jira/browse/FUNCTOR-6 Project: Commons Functor Issue Type: Bug Reporter: Bruno P. Kinoshita Priority: Minor This was another one of the items pointed by Emmanuel, regarding 1.0 release. In org.apache.commons.functor.core, there are Functors, and LeftIdentify and RightIdentify (Holder classes for Functors). Among the Functors in this package, all of them implement Serializable, with exception of Limit and Offset. Aren't these classes supposed to be Serializable too? Cheers -- 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-6) Make Limit and Offset implement Serializable
[ https://issues.apache.org/jira/browse/FUNCTOR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated FUNCTOR-6: - Attachment: FUNCTOR-6.patch Attached you will find a patch which makes Limit and Offset implement Serializable. Make Limit and Offset implement Serializable Key: FUNCTOR-6 URL: https://issues.apache.org/jira/browse/FUNCTOR-6 Project: Commons Functor Issue Type: Bug Reporter: Bruno P. Kinoshita Priority: Minor Attachments: FUNCTOR-6.patch This was another one of the items pointed by Emmanuel, regarding 1.0 release. In org.apache.commons.functor.core, there are Functors, and LeftIdentify and RightIdentify (Holder classes for Functors). Among the Functors in this package, all of them implement Serializable, with exception of Limit and Offset. Aren't these classes supposed to be Serializable too? Cheers -- 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-6) Make Limit and Offset implement Serializable
[ https://issues.apache.org/jira/browse/FUNCTOR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated FUNCTOR-6: - Attachment: (was: FUNCTOR-6.patch) Make Limit and Offset implement Serializable Key: FUNCTOR-6 URL: https://issues.apache.org/jira/browse/FUNCTOR-6 Project: Commons Functor Issue Type: Bug Reporter: Bruno P. Kinoshita Priority: Minor Attachments: FUNCTOR-6.patch This was another one of the items pointed by Emmanuel, regarding 1.0 release. In org.apache.commons.functor.core, there are Functors, and LeftIdentify and RightIdentify (Holder classes for Functors). Among the Functors in this package, all of them implement Serializable, with exception of Limit and Offset. Aren't these classes supposed to be Serializable too? Cheers -- 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-6) Make Limit and Offset implement Serializable
[ https://issues.apache.org/jira/browse/FUNCTOR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated FUNCTOR-6: - Attachment: FUNCTOR-6.patch Attach you will find a patch that makes Limit and Offset implement Serializable. The serialVersionUID field was added too with the generated value. Make Limit and Offset implement Serializable Key: FUNCTOR-6 URL: https://issues.apache.org/jira/browse/FUNCTOR-6 Project: Commons Functor Issue Type: Bug Reporter: Bruno P. Kinoshita Priority: Minor Attachments: FUNCTOR-6.patch This was another one of the items pointed by Emmanuel, regarding 1.0 release. In org.apache.commons.functor.core, there are Functors, and LeftIdentify and RightIdentify (Holder classes for Functors). Among the Functors in this package, all of them implement Serializable, with exception of Limit and Offset. Aren't these classes supposed to be Serializable too? Cheers -- 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] [Closed] (FUNCTOR-6) Make Limit and Offset implement Serializable
[ https://issues.apache.org/jira/browse/FUNCTOR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita closed FUNCTOR-6. Resolution: Later The patch broke the build, sorry. I will ask in the mailing list regarding statefulness of limit and offset. Make Limit and Offset implement Serializable Key: FUNCTOR-6 URL: https://issues.apache.org/jira/browse/FUNCTOR-6 Project: Commons Functor Issue Type: Bug Reporter: Bruno P. Kinoshita Priority: Minor Attachments: FUNCTOR-6.patch This was another one of the items pointed by Emmanuel, regarding 1.0 release. In org.apache.commons.functor.core, there are Functors, and LeftIdentify and RightIdentify (Holder classes for Functors). Among the Functors in this package, all of them implement Serializable, with exception of Limit and Offset. Aren't these classes supposed to be Serializable too? Cheers -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-696) addToEntry and multiplyEntry are abstract in AbstractRealMatrix
[ https://issues.apache.org/jira/browse/MATH-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-696. - Resolution: Fixed Revision 1188941. addToEntry and multiplyEntry are abstract in AbstractRealMatrix - Key: MATH-696 URL: https://issues.apache.org/jira/browse/MATH-696 Project: Commons Math Issue Type: Improvement Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 3.0 Methods addToEntry and multiplyEntry can have a default implementation instead of being declared abstract. -- 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-tabpanelfocusedCommentId=13135474#comment-13135474 ] Gilles commented on MATH-690: - The indicator functionality could be replaced by a call to copySign(one, x) (with one being 1 of the appropriate type) _if_ we drop the special case for a NaN argument: indicator returns NaN while copySign does not. 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] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135490#comment-13135490
]
Daniel Pitts commented on OGNL-20:
--
Maurizio: I have a suggestion for next time; Merge trunk to branch, then
integrate branch to trunk.
Also, you broke the OGNL-28 commit, removing throws OgnlException from all
visit methods in NodeVisitor.java
Performance - Replace synchronized blocks with ReentrantReadWriteLock
-
Key: OGNL-20
URL: https://issues.apache.org/jira/browse/OGNL-20
Project: OGNL
Issue Type: Improvement
Environment: ALL
Reporter: Greg Lively
Assignee: Maurizio Cucchiara
Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
these synchronized blocks are controlling access to HashMaps, etc. I believe
this could be done far better using ReentrantReadWriteLocks.
ReentrantReadWriteLock allows unlimited concurrent access, and single threads
only for writes. Perfect in an environment where the ratio of reads is far
higher than writes; which is typically the scenario for caching. Plus the
access control can be tuned for reads and writes; not just a big
synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-689) Breaking up MathUtils
[ https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135499#comment-13135499 ] Gilles commented on MATH-689: - log(double base, double x) moved to FastMath (revision 1188949). 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] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135508#comment-13135508
]
Maurizio Cucchiara commented on OGNL-20:
During the merge I had a lot of problem with Ubuntu update, and also with
Intellij Idea, which refused to merge the project (Idea merge use the approach
you said before), I had to use an alternative way which taught me a lot of
things (on top of those: don't use that approach :) ).
Sorry for your patch, I'm going to restore it.
Performance - Replace synchronized blocks with ReentrantReadWriteLock
-
Key: OGNL-20
URL: https://issues.apache.org/jira/browse/OGNL-20
Project: OGNL
Issue Type: Improvement
Environment: ALL
Reporter: Greg Lively
Assignee: Maurizio Cucchiara
Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
these synchronized blocks are controlling access to HashMaps, etc. I believe
this could be done far better using ReentrantReadWriteLocks.
ReentrantReadWriteLock allows unlimited concurrent access, and single threads
only for writes. Perfect in an environment where the ratio of reads is far
higher than writes; which is typically the scenario for caching. Plus the
access control can be tuned for reads and writes; not just a big
synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[ https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elijah Zupancic updated CHAIN-61: - Attachment: (was: chain-61.diff) Chain 2.0 trunk build is throwing many warnings as a result of generification changes - Key: CHAIN-61 URL: https://issues.apache.org/jira/browse/CHAIN-61 Project: Commons Chain Issue Type: Bug Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 Original Estimate: 2h Remaining Estimate: 2h When warnings on turned on for build, there are many unchecked conversion errors. These should be systematically investigated and fixed or given a @SuppressWarnings(unchecked) where needed. -- 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-689) Breaking up MathUtils
[ https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135510#comment-13135510 ] Gilles commented on MATH-689: - * OK to move reduce and normalizeAngle over to FastMath? * OK to move the constants EPSILON and SAFE_MIN over to Precision? 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] [Updated] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[ https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elijah Zupancic updated CHAIN-61: - Attachment: chain-61.diff Chain 2.0 trunk build is throwing many warnings as a result of generification changes - Key: CHAIN-61 URL: https://issues.apache.org/jira/browse/CHAIN-61 Project: Commons Chain Issue Type: Bug Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 Attachments: chain-61.diff Original Estimate: 2h Remaining Estimate: 2h When warnings on turned on for build, there are many unchecked conversion errors. These should be systematically investigated and fixed or given a @SuppressWarnings(unchecked) where needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[ https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135513#comment-13135513 ] Elijah Zupancic commented on CHAIN-61: -- I have attached another patch to the ticket. I just did a svn update and I noticed that the version number increased but there was no change in the files themselves. I just ran the patch, then created a new patch from those changes and I'm still getting the fuzz warning. I assume that it is informing us about some condition in that patching process - can we just ignore it? On Tue, Oct 25, 2011 at 1:54 PM, Simone Tripodi (Commented) (JIRA) Chain 2.0 trunk build is throwing many warnings as a result of generification changes - Key: CHAIN-61 URL: https://issues.apache.org/jira/browse/CHAIN-61 Project: Commons Chain Issue Type: Bug Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 Attachments: chain-61.diff Original Estimate: 2h Remaining Estimate: 2h When warnings on turned on for build, there are many unchecked conversion errors. These should be systematically investigated and fixed or given a @SuppressWarnings(unchecked) where needed. -- 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-28) Visitor pattern needs way to propagate exceptions.
[ https://issues.apache.org/jira/browse/OGNL-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135523#comment-13135523 ] Maurizio Cucchiara commented on OGNL-28: Hi Daniel, let me know if now everything came back. Visitor pattern needs way to propagate exceptions. -- Key: OGNL-28 URL: https://issues.apache.org/jira/browse/OGNL-28 Project: OGNL Issue Type: Improvement Reporter: Daniel Pitts Attachments: Visitor_with_exceptions.patch The previous patch I created for NodeVisitor neglects the fact that some visitors may wish to throw exceptions. I've created a patch in which all accept and visit methods throw OgnlException. Patch to come. -- 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-689) Breaking up MathUtils
[ https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135524#comment-13135524 ] Gilles commented on MATH-689: - Arithmetics is advantageously shorter than ArithmeticUtils. Adding a Utils suffix to the name of a class that belongs to a package util seems unnecessary. 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] (OGNL-28) Visitor pattern needs way to propagate exceptions.
[ https://issues.apache.org/jira/browse/OGNL-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135531#comment-13135531 ] Hudson commented on OGNL-28: Integrated in ognl #161 (See [https://builds.apache.org/job/ognl/161/]) OGNL-28 - Visitor pattern needs way to propagate exceptions (recovered after the merge) mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1188958 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/ASTAdd.java * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/NodeVisitor.java Visitor pattern needs way to propagate exceptions. -- Key: OGNL-28 URL: https://issues.apache.org/jira/browse/OGNL-28 Project: OGNL Issue Type: Improvement Reporter: Daniel Pitts Attachments: Visitor_with_exceptions.patch The previous patch I created for NodeVisitor neglects the fact that some visitors may wish to throw exceptions. I've created a patch in which all accept and visit methods throw OgnlException. Patch to come. -- 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
