[jira] [Created] (OGNL-48) Converting string values to boolean
Converting string values to boolean --- Key: OGNL-48 URL: https://issues.apache.org/jira/browse/OGNL-48 Project: Commons OGNL Issue Type: Bug Reporter: Pål Oliver Kristiansen Maybe I misunderstand how to use OGNL, but this seems a bit wierd to me (test case below) DefaultTypeConverter converter = new DefaultTypeConverter(); Object o = converter.convertValue(null, false, Boolean.class); assertEquals(false, o); // fails. Object is Boolean == true -- 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] (VFS-411) [SFTP] Update Jsch to version 0.1.47 from 0.1.46.
[ https://issues.apache.org/jira/browse/VFS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-411. - Resolution: Fixed In SVN. [SFTP] Update Jsch to version 0.1.47 from 0.1.46. - Key: VFS-411 URL: https://issues.apache.org/jira/browse/VFS-411 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Fix For: 2.1 [SFTP] Update Jsch to version 0.1.47 from 0.1.46. -- 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] (VFS-410) [SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
[
https://issues.apache.org/jira/browse/VFS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-410:
Summary: [SFTP] SftpFileObject getInputStream(long) reads the whole file
into memory (was: If using getInputStream(long position) on SftpFileObject the
file is read into memory)
[SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
---
Key: VFS-410
URL: https://issues.apache.org/jira/browse/VFS-410
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Martin Stockhammer
Fix For: 2.1
Attachments: SftpFileObject.java.patch
The method {{getInputStream(long filePointer)}} in {{SftpFileObject.java}}
reads the complete file into memory to create the input stream.
Newer versions of JSch provide a method
{{channel.get(file, monitor, filePointer);}}
that is much faster.
--
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] (VFS-410) [SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
[
https://issues.apache.org/jira/browse/VFS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved VFS-410.
-
Resolution: Fixed
Martin,
Thank you for providing the patch.
It has been applied with only slight changes.
Committed revision 1328346.
Gary
[SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
---
Key: VFS-410
URL: https://issues.apache.org/jira/browse/VFS-410
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Martin Stockhammer
Fix For: 2.1
Attachments: SftpFileObject.java.patch
The method {{getInputStream(long filePointer)}} in {{SftpFileObject.java}}
reads the complete file into memory to create the input stream.
Newer versions of JSch provide a method
{{channel.get(file, monitor, filePointer);}}
that is much faster.
--
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] (VFS-395) [POM] Declare maven-scm-* dependencies as optional.
[ https://issues.apache.org/jira/browse/VFS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-395: Fix Version/s: 2.1 Summary: [POM] Declare maven-scm-* dependencies as optional. (was: VFS2 should declare maven-scm-* dependencies as optional in pom) [POM] Declare maven-scm-* dependencies as optional. --- Key: VFS-395 URL: https://issues.apache.org/jira/browse/VFS-395 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Xavier Dury Fix For: 2.1 VFS2 includes weird dependencies: maven-scm-api, maven-scm-provider-svnexe. See http://commons.apache.org/vfs/commons-vfs2/dependencies.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-393) The ls command allways returns the cached data
[ https://issues.apache.org/jira/browse/VFS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-393: Fix Version/s: (was: 2.0) 2.1 The ls command allways returns the cached data -- Key: VFS-393 URL: https://issues.apache.org/jira/browse/VFS-393 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Environment: Red hat Linux Reporter: Prasad Kulkarni Priority: Blocker Labels: patch Fix For: 2.1 We have follwed the below steps to reproduce the issue 1. Created a folder under /home/xyz with name abc 2. Tried to get the Childrens of /home/xyz 3. I have got the folder listed as 'abc' although there are few other childrens which are not considered and listed 4. Deleted the folder 'abc' 5. Tried to get the Childrens of /home/xyz 6. It is still listing the folder 'abc' We have also tried all three possible cache strategy but no luck. -- 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] (VFS-313) CLONE -FTP configuration does not include option for setting socket timeout
[ https://issues.apache.org/jira/browse/VFS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-313: Fix Version/s: (was: 2.0) 2.1 CLONE -FTP configuration does not include option for setting socket timeout --- Key: VFS-313 URL: https://issues.apache.org/jira/browse/VFS-313 Project: Commons VFS Issue Type: Bug Affects Versions: 1.1 Reporter: Brad Davis Fix For: 2.1 Attachments: patch.txt The FTP Configuration includes an option to set a timeout for the data connection, but not for the socket timeout. This is a problem, as idle sockets can cause your download to hang forever and never timeout. -- 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] (VFS-395) [POM] Declare maven-scm-* dependencies as optional.
[ https://issues.apache.org/jira/browse/VFS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-395. - Resolution: Fixed Removed the offeding plugins. Committed revision 1328366. [POM] Declare maven-scm-* dependencies as optional. --- Key: VFS-395 URL: https://issues.apache.org/jira/browse/VFS-395 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Xavier Dury Fix For: 2.1 VFS2 includes weird dependencies: maven-scm-api, maven-scm-provider-svnexe. See http://commons.apache.org/vfs/commons-vfs2/dependencies.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-258) Unsafe casting to AbstractFileObject subclasses in doRename()
[ https://issues.apache.org/jira/browse/VFS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-258: Fix Version/s: (was: 2.0) 2.1 Unsafe casting to AbstractFileObject subclasses in doRename() - Key: VFS-258 URL: https://issues.apache.org/jira/browse/VFS-258 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Marek Zawirski Fix For: 2.1 Attachments: doRename_use_AbstractFileObject.patch AbstractFileObject#doRename() method is called from AbstractFileObject#moveTo() when file can be moved within the same file system. As it concerns file that is subclass AbstractFileObject, target file is also assumed to be AbstractFileObject type. However, this target file can be decorated. Undressing with FileObjectUtils.getAbstractFileObject() was not performed in every places that it should be. Some subclasses do correct stripping of decorator in doRename() implementations (e.g. FtpFileObject), some of them not (e.g. RamFileObject) - which may cause ClassCastExceptions. Patch proposal: pass undressed AbstractFileObject to doRename() instead of possibly decorated FileObject. -- 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] (VFS-252) SmbFileObject does not support setLastModifiedTime while jcifs supports it, it is critical for a backup application that checks the last modified time stamp to check which f
[
https://issues.apache.org/jira/browse/VFS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-252:
Fix Version/s: (was: 2.0)
2.1
SmbFileObject does not support setLastModifiedTime while jcifs supports it,
it is critical for a backup application that checks the last modified time
stamp to check which files needs to be updated
-
Key: VFS-252
URL: https://issues.apache.org/jira/browse/VFS-252
Project: Commons VFS
Issue Type: Improvement
Affects Versions: later
Reporter: Gerrit Cap
Priority: Critical
Fix For: 2.1
Original Estimate: 5m
Remaining Estimate: 5m
/**
* @throws Exception
* @see
org.apache.commons.vfs.provider.AbstractFileObject#doSetLastModifiedTime(long)
*/
protected boolean doSetLastModTime(long modtime) throws Exception {
file.setLastModified(modtime);
return true;
}
--
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] (VFS-255) Allow file operations to return a result
[
https://issues.apache.org/jira/browse/VFS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-255:
Fix Version/s: (was: 2.0)
2.1
Allow file operations to return a result
Key: VFS-255
URL: https://issues.apache.org/jira/browse/VFS-255
Project: Commons VFS
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Frank van der Kleij
Fix For: 2.1
Currently the file operations can not return any result after being executed.
A simple interface should allow marking the operations that return something
without being too strict about what they return.
I'm working on a command line shell based on VFS that also allows executing
operations (http://vfs-utils.sourceforge.net/shell). For the moment I found
nothing better than to check for a method getResult() but it I would prefer
to just check for the interface.
The interface could be something like this:
package org.apache.commons.vfs.operations;
public interface FileOperationResult {
public abstract Object getResult();
}
For me returning a String would be good enough, but I think returning an
Object the most appropriate. In the vfs shell I just do a toString() on it.
--
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] (VFS-275) add RandomAccessContent.setLength() method
[ https://issues.apache.org/jira/browse/VFS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-275: Fix Version/s: (was: 2.0) 2.1 add RandomAccessContent.setLength() method -- Key: VFS-275 URL: https://issues.apache.org/jira/browse/VFS-275 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Environment: Google App Engine Reporter: Vince Bonfanti Fix For: 2.1 Attachments: VFS-randomaccesscontent-setlength.patch I'm developing a Commons VFS plug-in for Google App Engine (http://code.google.com/p/gaevfs/), and also using this as a basis for a pluggable file system for the H2 relational database (http://www.h2database.com/html/main.html) that will allow H2 to run on Google App Engine. In order to support H2, I need to support a setLength() method for my RandomAccessContent implementation. Note that setLength() is supported by java.io.RandomAccessFile (http://java.sun.com/javase/6/docs/api/index.html), so adding this method will bring RandomAccessContent a little closer to RandomAccessFile. -- 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] (VFS-254) Let FileObject and FileContent extend Closeable
[ https://issues.apache.org/jira/browse/VFS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-254: Fix Version/s: (was: 2.0) 2.1 Let FileObject and FileContent extend Closeable --- Key: VFS-254 URL: https://issues.apache.org/jira/browse/VFS-254 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.0, 1.1, later, Nightly Builds, 2.0 Reporter: Marek Zawirski Priority: Trivial Fix For: 2.1 Attachments: extend_cloneable.patch What about letting FileObject and FileContent extend java.io.Closeable interface? Some applications have a generic code for closing such resources (and for example ignoring and logging exceptions during close), so it may be useful at application-level. -- 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] (VFS-250) URLFileName should always honor trailing slash for collections
[ https://issues.apache.org/jira/browse/VFS-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-250: Fix Version/s: (was: 2.0) 2.1 URLFileName should always honor trailing slash for collections -- Key: VFS-250 URL: https://issues.apache.org/jira/browse/VFS-250 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: James William Dumay Fix For: 2.1 Attachments: VFS-urlfilename-should-be-always-uri-style.patch URLFileName should always honor trailing slash for collections. When using webdav VFS.getUriStyle() should always equal to true as operations on a collection resource without a trailing slash will result in a 301. This should be default for the URLFileName. -- 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] (VFS-236) SmbFileObject throws NPE when used without authentication
[
https://issues.apache.org/jira/browse/VFS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-236:
Fix Version/s: (was: 2.0)
2.1
SmbFileObject throws NPE when used without authentication
-
Key: VFS-236
URL: https://issues.apache.org/jira/browse/VFS-236
Project: Commons VFS
Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Matt Casters
Fix For: 2.1
If you have a shared folder without authentication, SmbFileObject throws an
NPE in method createSmbFile().
Here is what I changed to get it to run:
private SmbFile createSmbFile(FileName fileName) throws
MalformedURLException, SmbException, FileSystemException
{
SmbFileName smbFileName = (SmbFileName) fileName;
String path = smbFileName.getUriWithoutAuth();
UserAuthenticationData authData = null;
SmbFile file;
NtlmPasswordAuthentication auth;
try
{
authData =
UserAuthenticatorUtils.authenticate(getFileSystem().getFileSystemOptions(),
SmbFileProvider.AUTHENTICATOR_TYPES);
if (authData!=null) {
auth = new NtlmPasswordAuthentication(
UserAuthenticatorUtils.toString(
UserAuthenticatorUtils.getData(
authData,
UserAuthenticationData.DOMAIN,
UserAuthenticatorUtils.toChar(smbFileName.getDomain(,
UserAuthenticatorUtils.toString(
UserAuthenticatorUtils.getData(
authData,
UserAuthenticationData.USERNAME,
UserAuthenticatorUtils.toChar(smbFileName.getUserName(,
UserAuthenticatorUtils.toString(
UserAuthenticatorUtils.getData(
authData,
UserAuthenticationData.PASSWORD,
UserAuthenticatorUtils.toChar(smbFileName.getPassword();
file = new SmbFile(path, auth);
} else {
auth=null;
file = new SmbFile(path);
}
}
finally
{
UserAuthenticatorUtils.cleanup(authData);
}
if (file.isDirectory() !file.toString().endsWith(/))
{
if (auth!=null) {
file = new SmbFile(path + /, auth);
} else {
file = new SmbFile(path + /);
}
}
return file;
}
--
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] (VFS-228) Ant regression with ClassNotFoundException for DefaultLocalFileProvider
[ https://issues.apache.org/jira/browse/VFS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-228: Fix Version/s: (was: 2.0) 2.1 Ant regression with ClassNotFoundException for DefaultLocalFileProvider --- Key: VFS-228 URL: https://issues.apache.org/jira/browse/VFS-228 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Environment: java version 1.6.0_0 IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) Apache Ant version 1.7.1 compiled on October 3 2008 Reporter: Per Hermansson Priority: Critical Fix For: 2.1 Attachments: patch, test.xml, vfs-task.diff The latest version from trunk fails to work with Apache Ant resulting in this error: Could not load VFS configuration from jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0-SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml. which was caused by java.lang.ClassNotFoundException: org.apache.commons.vfs.provider.local.DefaultLocalFileProvider The cause seems to be a class loader issued introduced in rev 537717. Reverting that change: cd core svn diff -c r537717 src/main/java/org/apache/commons/vfs/impl/StandardFileSystemManager.java | patch -R mvn clean install [copy commons-vfs-2.0-SNAPSHOT to my test's lib dir] ant -f test.xml test Makes my example ant file work again (worked with the 1.0 release). The 537717 revision was intended to fix VFS-136: Don't force-set the classloader - Thanks to Adam Heath for the patch So it might be a bit controversial to reverse that change. Attaching patch fixing the issue and my example ant file. -- 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] (VFS-210) Wrapper-Mode VFS
[ https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-210: Fix Version/s: (was: 2.0) 2.1 Wrapper-Mode VFS Key: VFS-210 URL: https://issues.apache.org/jira/browse/VFS-210 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 2.1 VFS should behave more like a wrapper to the underlaying library than a full blown filesystem. This should solve the following problems: * access of hidden files/directories * access to special folders * speed up FTP access -- 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] (CODEC-139) DigestUtils: additional utility methods
[ https://issues.apache.org/jira/browse/CODEC-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258270#comment-13258270 ] Gary D. Gregory commented on CODEC-139: --- Hello Sebastian: Thank you for the patch. A couple of issues before this can go further: - No unit tests - The Javadoc for the updateDigest methods do not match the code. The docs talk about updating the digest but the code calls the digest method which does an update AND then completes the digest computation. Which way do you really mean? Plain update? Update AND complete (aka digest)? Unit tests would help define the user cases. Thank you, Gary DigestUtils: additional utility methods --- Key: CODEC-139 URL: https://issues.apache.org/jira/browse/CODEC-139 Project: Commons Codec Issue Type: Improvement Reporter: Sebastien Dubois Priority: Trivial Labels: patch Attachments: DigestUtils-patch.txt Original Estimate: 10m Remaining Estimate: 10m I've slightly modified the DigestUtils class: - changed the visibility (protected -- public) of a few methods: these methods are generally useful if one just wants to get a MessageDigest instance for a given algorithm - added two 'updateDigest' methods which can be used to add more data to digest to the provided MessageDigest. The advantage for the one that accepts a String argument is that it keeps the same logic as the rest of DigestUtils (uses getBytesUtf8). The second one which accepts a byte array is there for consistency -- 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] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[
https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258271#comment-13258271
]
Gary D. Gregory commented on CODEC-133:
---
Hello again and thank you for your patience.
I one file I see:
{quote}
* p
* Based on the C implementation from Poul-Henning Kamp which was released
under the following licence:
*
* pre
*
* THE BEER-WARE LICENSE (Revision 42): lt;p...@login.dknet.dkgt; wrote
this file.
* As long as you retain this notice you can do whatever you want with this
* stuff. If we meet some day, and you think this stuff is worth it, you can buy
* me a beer in return. Poul-Henning Kamp
*
* Source: $FreeBSD: src/lib/libcrypt/crypt-md5.c,v 1.1 1999/01/21 13:50:09
brandon Exp $
*
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c?rev=1.1;content-type=text%2Fplain
* /pre
{quote}
I am not sure this is acceptable. IMO this can be removed because we are not
shipping the C code, but rather a port of a port.
And:
{quote}
* p
* Conversion to Kotlin and from there to Java in 2012 by Christian Hammers
lt;c...@lathspell.degt; and put into the
* Public Domain.
* p
* The C style comments are from the original C code, the ones with // from
me.
{quote}
The granting part is also assumed because the license was granted to Apache
when the patch was attached with the proper check-box selected.
Unless someone disagrees, I'll remove the above quoted text from the code and
apply soon.
Thank you,
Gary
Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash
variants
Key: CODEC-133
URL: https://issues.apache.org/jira/browse/CODEC-133
Project: Commons Codec
Issue Type: New Feature
Affects Versions: 1.6
Reporter: Christian Hammers
Labels: MD5, SHA-512, crypt(3), crypto, hash
Attachments: commons-codec-crypt3.diff,
crypt3-with-utexas-licence.diff
The Linux libc6 crypt(3) function, which is used to generate e.g. the
password hashes in /etc/shadow, is available in nearly all other programming
languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and
offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt
and several iterations to make rainbow table attacks harder. Thus they are
widely used to store user passwords.
Java, though, has due it's platform independence, no direct access to the
libc functions and still lacks an proper port of the crypt(3) function.
I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES
based crypt(3) method but would also like to see the much stronger algorithms.
There are other bug reports like DIRSTUDIO-738 that demand those crypt
variants for some specific applications so there it would benefit other
Apache projects as well.
Java ports of most of the specific crypt variants are already existing, but
they would have to be cleaned up, properly tested and license checked:
ftp://ftp.arlut.utexas.edu/pub/java_hashes/
I would be willing to help here by cleaning the source code and writing unit
tests etc. but I'd like to generally know if you are interested and if
there's someone who can do a code review (it's security relevant after all
and I'm no crypto guy)
bye,
-christian-
--
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] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258299#comment-13258299 ] Christian Hammers commented on CODEC-133: - Ok, remove my license. What about replacing Pouls license with the sentence: Based on the public domain (beer-ware) C implementation from Poul-Henning Kamp which was found at: pre Source: $FreeBSD: src/lib/libcrypt/crypt-md5.c,v 1.1 1999/01/21 13:50:09 brandon Exp $ http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c?rev=1.1;content-type=text%2Fplain /pre I just like to keep a reference to the original source code in case someone want to verify the code and also mentioning which licesence Poul used so that nobody worries that my conversion has any licesene issues. Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- 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-780) BSPTree class and recovery of a Euclidean 3D BRep
[
https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Willis updated MATH-780:
---
Description:
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a tetrahedron as
represented by a float array containing 4 3D points (x,y,z) order and an array
of indices (4 triplets for the 4 faces of the tet). I construct a BSPMesh() as
shown in the code below. I can construct the PolyhedronsSet() however, when I
interrogate the shape (with getSize() or getBoundarySize() I get infinity back
as a result). When I try to get back the BRep (by traversing the BSPTree
resulting from PolyhedronsSet.getTree(true) and getting the PolygonsSet()
associated with each 3D SubPlane, I get a null vertex back and strange values.
Any ideas?
public class BSPMesh {
public BSPMesh(float[] coords, int[] indices) {
double size;
setBoundingBox(coords);
ArrayListSubHyperplaneEuclidean3D subHyperplaneList = new
ArrayList();
for (int idx = 0; idx indices.length; idx += 3) {
int idxA = indices[idx] * 3;
int idxB = indices[idx + 1] * 3;
int idxC = indices[idx + 2] * 3;
Vector3D v_1 = new Vector3D(coords[idxA], coords[idxA + 1],
coords[idxA + 2]);
Vector3D v_2 = new Vector3D(coords[idxB], coords[idxB + 1],
coords[idxB + 2]);
Vector3D v_3 = new Vector3D(coords[idxC], coords[idxC + 1],
coords[idxC + 2]);
Vector3D[] vertices = {v_1, v_2, v_3};
Plane polyPlane = new Plane(v_1, v_2, v_3);
ArrayListSubHyperplaneEuclidean2D lines = new ArrayList();
Vector2D[] projPts = new Vector2D[vertices.length];
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
projPts[ptIdx] = polyPlane.toSubSpace(vertices[ptIdx]);
}
SubLine lineInPlane = null;
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
lineInPlane = new SubLine(projPts[ptIdx],
projPts[(ptIdx+1)%projPts.length]);
lines.add(lineInPlane);
}
RegionEuclidean2D polyRegion = new PolygonsSet(lines);
SubPlane polygon = new SubPlane(polyPlane, polyRegion);
size = polyRegion.getSize(); // correct size here
Vector3D[][] verticesTest = getVertices(polygon); // correctly
retrieves the BRep for each face
subHyperplaneList.add(polygon);
}
PolyhedronsSet polyhedronsSet = new PolyhedronsSet(subHyperplaneList);
BSPTreeEuclidean3D myTree = polyhedronsSet.getTree(true);
size = polyhedronsSet.getSize();// strange Inf returned
size = polyhedronsSet2.getBoundarySize(); // strange Inf
returned
// Member variable and other code for extracting the BRep not included
here... can include if desired
//tree = myTree;
//Vector3D[][] vertices = getVertices((SubPlane) ((BoundaryAttribute)
tree.getAttribute()).getPlusOutside()); // strange values returned here
System.out.println(END);
}
public static void main(String[] args) {
float[] tetCoords = {1, 0, 0,
2, 0, 0,
1, 1, 0,
1, 0, 1};
int[] tetIndices = {0, 1, 2,
0, 1, 3,
0, 2, 3,
2, 1, 3};
BSPMesh blah = new BSPMesh(tetCoords, tetIndices);
}
}
was:
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a tetrahedron as
represented by a float array containing 4 3D points (x,y,z) order and an array
of indices (4 triplets for the 4 faces of the tet). I construct a BSPMesh() as
shown in the code below. I can construct the PolyhedronsSet() however, when I
interrogate the shape (with getSize() or getBoundarySize() I get infinity back
as a result). When I try to get back the BRep (by traversing the BSPTree
resulting from PolyhedronsSet.getTree(true) and getting the PolygonsSet()
associated with each 3D SubPlane, I get a null vertex back and strange values.
Any ideas?
public class BSPMesh {
public BSPMesh(float[] coords, int[] indices) {
double size;
setBoundingBox(coords);
ArrayListSubHyperplaneEuclidean3D subHyperplaneList = new
ArrayList();
for (int idx = 0; idx indices.length; idx += 3) {
int idxA = indices[idx] * 3;
int idxB = indices[idx + 1] * 3;
int idxC = indices[idx + 2] * 3;
Vector3D v_1 = new Vector3D(coords[idxA], coords[idxA + 1],
coords[idxA + 2]);
Vector3D v_2 = new Vector3D(coords[idxB], coords[idxB + 1],
coords[idxB + 2]);
Vector3D v_3 = new Vector3D(coords[idxC], coords[idxC + 1],
coords[idxC + 2]);
Vector3D[] vertices = {v_1,
[jira] [Commented] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258300#comment-13258300 ] Gary D. Gregory commented on CODEC-133: --- OK, that sounds good. Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- 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] (CODEC-133) Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants.
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-133: -- Summary: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. (was: Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants) Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. --- Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- 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] (CODEC-104) Add a function for the classical Unix crypt(3) hash
[ https://issues.apache.org/jira/browse/CODEC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-104: -- Summary: Add a function for the classical Unix crypt(3) hash (was: Please add a function for the classical Unix crypt(3) hash) Add a function for the classical Unix crypt(3) hash --- Key: CODEC-104 URL: https://issues.apache.org/jira/browse/CODEC-104 Project: Commons Codec Issue Type: New Feature Reporter: Christian Hammers Fix For: 1.x The Sun Java APIs lack a function for the classical Unix crypt(3) hash that was used in e.g. /etc/passwd or Apache htpasswd and is still widely used dispite the availablitity of better algorithms like MD5 or SHA. Apart from me cursing Sun for producing monster crypto APIs but missing the little things that one really needs, there are already several Apache projects that implemented UnixCrypt for their own: org.apache.directory.studio.ldapbrowser.core.utils.UnixCrypt org.apache.fulcrum.crypto.impl.UnixCrypt and maybe others bye, -christian- -- 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] (CODEC-104) Add a function for the classical Unix crypt(3) hash
[ https://issues.apache.org/jira/browse/CODEC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-104. --- Resolution: Duplicate Marking as duplicate of the more complete [CODEC-133] Add a function for the classical Unix crypt(3) hash --- Key: CODEC-104 URL: https://issues.apache.org/jira/browse/CODEC-104 Project: Commons Codec Issue Type: New Feature Reporter: Christian Hammers Fix For: 1.x The Sun Java APIs lack a function for the classical Unix crypt(3) hash that was used in e.g. /etc/passwd or Apache htpasswd and is still widely used dispite the availablitity of better algorithms like MD5 or SHA. Apart from me cursing Sun for producing monster crypto APIs but missing the little things that one really needs, there are already several Apache projects that implemented UnixCrypt for their own: org.apache.directory.studio.ldapbrowser.core.utils.UnixCrypt org.apache.fulcrum.crypto.impl.UnixCrypt and maybe others bye, -christian- -- 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-459) FTPClient.storeFile never returns in active mode if data channel cannot be established
[ https://issues.apache.org/jira/browse/NET-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258318#comment-13258318 ] Sebb commented on NET-459: -- Where exactly does the method block? Can you take a thread dump to see? FTPClient.storeFile never returns in active mode if data channel cannot be established -- Key: NET-459 URL: https://issues.apache.org/jira/browse/NET-459 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1, 3.1 Reporter: Jaroslav Chmurny FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout). -- 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] (CODEC-133) Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants.
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-133. --- Resolution: Fixed Fix Version/s: 1.7 In SVN. Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. --- Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Fix For: 1.7 Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- 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-780) BSPTree class and recovery of a Euclidean 3D BRep
[
https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258342#comment-13258342
]
Andrew Willis commented on MATH-780:
Looks like I had an index flipped resulting in an improperly oriented face for
the tetrahedron. I did get the tetrahedron to work. However, I am now
struggling with getting a cube to work and I have verified the
normals/orientations of the planes to be correct.
BSPTree class and recovery of a Euclidean 3D BRep
-
Key: MATH-780
URL: https://issues.apache.org/jira/browse/MATH-780
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Linux
Reporter: Andrew Willis
Labels: BSPTree, euclidean.threed
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a tetrahedron as
represented by a float array containing 4 3D points (x,y,z) order and an
array of indices (4 triplets for the 4 faces of the tet). I construct a
BSPMesh() as shown in the code below. I can construct the PolyhedronsSet()
however, when I interrogate the shape (with getSize() or getBoundarySize() I
get infinity back as a result). When I try to get back the BRep (by
traversing the BSPTree resulting from PolyhedronsSet.getTree(true) and
getting the PolygonsSet() associated with each 3D SubPlane, I get a null
vertex back and strange values.
Any ideas?
public class BSPMesh {
public BSPMesh(float[] coords, int[] indices) {
double size;
setBoundingBox(coords);
ArrayListSubHyperplaneEuclidean3D subHyperplaneList = new
ArrayList();
for (int idx = 0; idx indices.length; idx += 3) {
int idxA = indices[idx] * 3;
int idxB = indices[idx + 1] * 3;
int idxC = indices[idx + 2] * 3;
Vector3D v_1 = new Vector3D(coords[idxA], coords[idxA + 1],
coords[idxA + 2]);
Vector3D v_2 = new Vector3D(coords[idxB], coords[idxB + 1],
coords[idxB + 2]);
Vector3D v_3 = new Vector3D(coords[idxC], coords[idxC + 1],
coords[idxC + 2]);
Vector3D[] vertices = {v_1, v_2, v_3};
Plane polyPlane = new Plane(v_1, v_2, v_3);
ArrayListSubHyperplaneEuclidean2D lines = new ArrayList();
Vector2D[] projPts = new Vector2D[vertices.length];
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
projPts[ptIdx] = polyPlane.toSubSpace(vertices[ptIdx]);
}
SubLine lineInPlane = null;
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
lineInPlane = new SubLine(projPts[ptIdx],
projPts[(ptIdx+1)%projPts.length]);
lines.add(lineInPlane);
}
RegionEuclidean2D polyRegion = new PolygonsSet(lines);
SubPlane polygon = new SubPlane(polyPlane, polyRegion);
size = polyRegion.getSize(); // correct size here
Vector3D[][] verticesTest = getVertices(polygon); // correctly
retrieves the BRep for each face
subHyperplaneList.add(polygon);
}
PolyhedronsSet polyhedronsSet = new PolyhedronsSet(subHyperplaneList);
BSPTreeEuclidean3D myTree = polyhedronsSet.getTree(true);
size = polyhedronsSet.getSize();// strange Inf returned
size = polyhedronsSet2.getBoundarySize(); // strange Inf
returned
// Member variable and other code for extracting the BRep not
included here... can include if desired
//tree = myTree;
//Vector3D[][] vertices = getVertices((SubPlane) ((BoundaryAttribute)
tree.getAttribute()).getPlusOutside()); // strange values returned here
System.out.println(END);
}
public static void main(String[] args) {
float[] tetCoords = {1, 0, 0,
2, 0, 0,
1, 1, 0,
1, 0, 1};
int[] tetIndices = {0, 1, 2,
0, 1, 3,
0, 2, 3,
2, 1, 3};
BSPMesh blah = new BSPMesh(tetCoords, tetIndices);
}
}
--
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-780) BSPTree class and recovery of a Euclidean 3D BRep
[
https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Willis updated MATH-780:
---
Attachment: BSPMesh2.java
This code produces the following error:
Exception in thread main java.lang.ClassCastException:
org.apache.commons.math3.geometry.partitioning.BoundaryAttribute cannot be cast
to java.lang.Boolean
at
org.apache.commons.math3.geometry.euclidean.twod_exact.PolygonsSet.computeGeometricalProperties(PolygonsSet.java:135)
at
org.apache.commons.math3.geometry.partitioning.AbstractRegion.getSize(AbstractRegion.java:380)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet$FacetsContributionVisitor.addContribution(PolyhedronsSet.java:171)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet$FacetsContributionVisitor.visitInternalNode(PolyhedronsSet.java:153)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:262)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:263)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet.computeGeometricalProperties(PolyhedronsSet.java:118)
at
org.apache.commons.math3.geometry.partitioning.AbstractRegion.getSize(AbstractRegion.java:380)
at datastructures.j3d.bsptree.BSPMesh.init(BSPMesh.java:130)
at datastructures.j3d.bsptree.BSPMesh2.main(BSPMesh2.java:206)
BSPTree class and recovery of a Euclidean 3D BRep
-
Key: MATH-780
URL: https://issues.apache.org/jira/browse/MATH-780
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Linux
Reporter: Andrew Willis
Labels: BSPTree, euclidean.threed
Attachments: BSPMesh2.java
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a tetrahedron as
represented by a float array containing 4 3D points (x,y,z) order and an
array of indices (4 triplets for the 4 faces of the tet). I construct a
BSPMesh() as shown in the code below. I can construct the PolyhedronsSet()
however, when I interrogate the shape (with getSize() or getBoundarySize() I
get infinity back as a result). When I try to get back the BRep (by
traversing the BSPTree resulting from PolyhedronsSet.getTree(true) and
getting the PolygonsSet() associated with each 3D SubPlane, I get a null
vertex back and strange values.
Any ideas?
public class BSPMesh {
public BSPMesh(float[] coords, int[] indices) {
double size;
setBoundingBox(coords);
ArrayListSubHyperplaneEuclidean3D subHyperplaneList = new
ArrayList();
for (int idx = 0; idx indices.length; idx += 3) {
int idxA = indices[idx] * 3;
int idxB = indices[idx + 1] * 3;
int idxC = indices[idx + 2] * 3;
Vector3D v_1 = new Vector3D(coords[idxA], coords[idxA + 1],
coords[idxA + 2]);
Vector3D v_2 = new Vector3D(coords[idxB], coords[idxB + 1],
coords[idxB + 2]);
Vector3D v_3 = new Vector3D(coords[idxC], coords[idxC + 1],
coords[idxC + 2]);
Vector3D[] vertices = {v_1, v_2, v_3};
Plane polyPlane = new Plane(v_1, v_2, v_3);
ArrayListSubHyperplaneEuclidean2D lines = new ArrayList();
Vector2D[] projPts = new Vector2D[vertices.length];
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
projPts[ptIdx] = polyPlane.toSubSpace(vertices[ptIdx]);
}
SubLine lineInPlane = null;
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
lineInPlane = new SubLine(projPts[ptIdx],
projPts[(ptIdx+1)%projPts.length]);
lines.add(lineInPlane);
}
RegionEuclidean2D polyRegion = new PolygonsSet(lines);
SubPlane polygon = new SubPlane(polyPlane, polyRegion);
size = polyRegion.getSize(); // correct size here
Vector3D[][] verticesTest = getVertices(polygon); // correctly
retrieves the BRep for each face
subHyperplaneList.add(polygon);
}
PolyhedronsSet polyhedronsSet = new PolyhedronsSet(subHyperplaneList);
BSPTreeEuclidean3D myTree = polyhedronsSet.getTree(true);
size = polyhedronsSet.getSize();// strange Inf returned
size = polyhedronsSet2.getBoundarySize(); // strange Inf
returned
[jira] [Issue Comment Edited] (MATH-780) BSPTree class and recovery of a Euclidean 3D BRep
[
https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258362#comment-13258362
]
Andrew Willis edited comment on MATH-780 at 4/20/12 4:42 PM:
-
The code in BSPMesh2.java produces the following error when I run it. If you
comment in the line that re-assigns the coordinate data to be cubeCoords1, then
the code works fine. The only difference in the two data sets is that one
coordinate has changed by a small amount.
Exception in thread main java.lang.ClassCastException:
org.apache.commons.math3.geometry.partitioning.BoundaryAttribute cannot be cast
to java.lang.Boolean
at
org.apache.commons.math3.geometry.euclidean.twod_exact.PolygonsSet.computeGeometricalProperties(PolygonsSet.java:135)
at
org.apache.commons.math3.geometry.partitioning.AbstractRegion.getSize(AbstractRegion.java:380)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet$FacetsContributionVisitor.addContribution(PolyhedronsSet.java:171)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet$FacetsContributionVisitor.visitInternalNode(PolyhedronsSet.java:153)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:262)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:263)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet.computeGeometricalProperties(PolyhedronsSet.java:118)
at
org.apache.commons.math3.geometry.partitioning.AbstractRegion.getSize(AbstractRegion.java:380)
at datastructures.j3d.bsptree.BSPMesh.init(BSPMesh.java:130)
at datastructures.j3d.bsptree.BSPMesh2.main(BSPMesh2.java:206)
was (Author: arwillis):
This code produces the following error:
Exception in thread main java.lang.ClassCastException:
org.apache.commons.math3.geometry.partitioning.BoundaryAttribute cannot be cast
to java.lang.Boolean
at
org.apache.commons.math3.geometry.euclidean.twod_exact.PolygonsSet.computeGeometricalProperties(PolygonsSet.java:135)
at
org.apache.commons.math3.geometry.partitioning.AbstractRegion.getSize(AbstractRegion.java:380)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet$FacetsContributionVisitor.addContribution(PolyhedronsSet.java:171)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet$FacetsContributionVisitor.visitInternalNode(PolyhedronsSet.java:153)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:262)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:263)
at
org.apache.commons.math3.geometry.partitioning.BSPTree.visit(BSPTree.java:261)
at
org.apache.commons.math3.geometry.euclidean.threed_exact.PolyhedronsSet.computeGeometricalProperties(PolyhedronsSet.java:118)
at
org.apache.commons.math3.geometry.partitioning.AbstractRegion.getSize(AbstractRegion.java:380)
at datastructures.j3d.bsptree.BSPMesh.init(BSPMesh.java:130)
at datastructures.j3d.bsptree.BSPMesh2.main(BSPMesh2.java:206)
BSPTree class and recovery of a Euclidean 3D BRep
-
Key: MATH-780
URL: https://issues.apache.org/jira/browse/MATH-780
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Linux
Reporter: Andrew Willis
Labels: BSPTree, euclidean.threed
Attachments: BSPMesh2.java
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a tetrahedron as
represented by a float array containing 4 3D points (x,y,z) order and an
array of indices (4 triplets for the 4 faces of the tet). I construct a
BSPMesh() as shown in the code below. I can construct the PolyhedronsSet()
however, when I interrogate the shape (with getSize() or getBoundarySize() I
get infinity back as a result). When I try to get back the BRep (by
traversing the BSPTree resulting from PolyhedronsSet.getTree(true) and
getting the PolygonsSet() associated with each 3D SubPlane, I get a null
vertex back and strange values.
Any ideas?
public class BSPMesh {
public BSPMesh(float[] coords, int[] indices) {
[jira] [Updated] (MATH-780) BSPTree class and recovery of a Euclidean 3D BRep
[
https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Willis updated MATH-780:
---
Description:
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a cube as
represented by a float array containing 8 3D points in(x,y,z) order and an
array of indices (12 triplets for the 12 faces of the cube). I construct a
BSPMesh() as shown in the code below. I can construct the PolyhedronsSet() but
have problems extracting the faces from the BSPTree to reconstruct the BRep.
The attached code (BSPMesh2.java) shows that a small change to 1 of the vertex
positions causes/corrects the problem.
Any ideas?
was:
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a tetrahedron as
represented by a float array containing 4 3D points (x,y,z) order and an array
of indices (4 triplets for the 4 faces of the tet). I construct a BSPMesh() as
shown in the code below. I can construct the PolyhedronsSet() however, when I
interrogate the shape (with getSize() or getBoundarySize() I get infinity back
as a result). When I try to get back the BRep (by traversing the BSPTree
resulting from PolyhedronsSet.getTree(true) and getting the PolygonsSet()
associated with each 3D SubPlane, I get a null vertex back and strange values.
Any ideas?
public class BSPMesh {
public BSPMesh(float[] coords, int[] indices) {
double size;
setBoundingBox(coords);
ArrayListSubHyperplaneEuclidean3D subHyperplaneList = new
ArrayList();
for (int idx = 0; idx indices.length; idx += 3) {
int idxA = indices[idx] * 3;
int idxB = indices[idx + 1] * 3;
int idxC = indices[idx + 2] * 3;
Vector3D v_1 = new Vector3D(coords[idxA], coords[idxA + 1],
coords[idxA + 2]);
Vector3D v_2 = new Vector3D(coords[idxB], coords[idxB + 1],
coords[idxB + 2]);
Vector3D v_3 = new Vector3D(coords[idxC], coords[idxC + 1],
coords[idxC + 2]);
Vector3D[] vertices = {v_1, v_2, v_3};
Plane polyPlane = new Plane(v_1, v_2, v_3);
ArrayListSubHyperplaneEuclidean2D lines = new ArrayList();
Vector2D[] projPts = new Vector2D[vertices.length];
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
projPts[ptIdx] = polyPlane.toSubSpace(vertices[ptIdx]);
}
SubLine lineInPlane = null;
for (int ptIdx=0; ptIdx projPts.length; ptIdx++) {
lineInPlane = new SubLine(projPts[ptIdx],
projPts[(ptIdx+1)%projPts.length]);
lines.add(lineInPlane);
}
RegionEuclidean2D polyRegion = new PolygonsSet(lines);
SubPlane polygon = new SubPlane(polyPlane, polyRegion);
size = polyRegion.getSize(); // correct size here
Vector3D[][] verticesTest = getVertices(polygon); // correctly
retrieves the BRep for each face
subHyperplaneList.add(polygon);
}
PolyhedronsSet polyhedronsSet = new PolyhedronsSet(subHyperplaneList);
BSPTreeEuclidean3D myTree = polyhedronsSet.getTree(true);
size = polyhedronsSet.getSize();// strange Inf returned
size = polyhedronsSet2.getBoundarySize(); // strange Inf
returned
// Member variable and other code for extracting the BRep not included
here... can include if desired
//tree = myTree;
//Vector3D[][] vertices = getVertices((SubPlane) ((BoundaryAttribute)
tree.getAttribute()).getPlusOutside()); // strange values returned here
System.out.println(END);
}
public static void main(String[] args) {
float[] tetCoords = {1, 0, 0,
2, 0, 0,
1, 1, 0,
1, 0, 1};
int[] tetIndices = {0, 1, 2,
0, 1, 3,
0, 2, 3,
2, 1, 3};
BSPMesh blah = new BSPMesh(tetCoords, tetIndices);
}
}
BSPTree class and recovery of a Euclidean 3D BRep
-
Key: MATH-780
URL: https://issues.apache.org/jira/browse/MATH-780
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Linux
Reporter: Andrew Willis
Labels: BSPTree, euclidean.threed
Attachments: BSPMesh2.java
New to the work here. Thanks for your efforts on this code.
I create a BSPTree from a BoundaryRep (Brep) my test Brep is a cube as
represented by a float array containing 8 3D points in(x,y,z) order and an
array of indices (12 triplets for the 12 faces of the cube). I construct a
BSPMesh() as shown in the code below. I can construct the PolyhedronsSet()
but have problems extracting
[jira] [Commented] (MATH-780) BSPTree class and recovery of a Euclidean 3D BRep
[ https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258440#comment-13258440 ] Luc Maisonobe commented on MATH-780: Hi Andrew, The file BSPMesh2.java you attached to the issue is not sufficient to reproduce the error. It refers to a BSPMesh class and to a PolygonOfPoints class. It seems changing BSPMesh to BSPMesh2 is sufficient to solver the references in the main method (but I am not sure this class is a drop-in replacement for your issue), but I have no clue about the other class. Could you attach it to the issue too ? BSPTree class and recovery of a Euclidean 3D BRep - Key: MATH-780 URL: https://issues.apache.org/jira/browse/MATH-780 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: Linux Reporter: Andrew Willis Labels: BSPTree, euclidean.threed Attachments: BSPMesh2.java New to the work here. Thanks for your efforts on this code. I create a BSPTree from a BoundaryRep (Brep) my test Brep is a cube as represented by a float array containing 8 3D points in(x,y,z) order and an array of indices (12 triplets for the 12 faces of the cube). I construct a BSPMesh() as shown in the code below. I can construct the PolyhedronsSet() but have problems extracting the faces from the BSPTree to reconstruct the BRep. The attached code (BSPMesh2.java) shows that a small change to 1 of the vertex positions causes/corrects the problem. Any ideas? -- 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-668) Polygon difference function produces erroneous results with certain polygons
[ https://issues.apache.org/jira/browse/MATH-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-668. Resolution: Not A Problem Fix Version/s: (was: 3.1) 3.0 I agree with Thomas analyses. Concerning the difference2 case, the two points are explained by the vertical line at x = 5.0 which comes from the outer shape. The internal representation is a BSP tree and one of this part of the outer boundary creates an hyperplane that splits the inner triangle. When the boundary representation is rebuilt, the two segments are glued together and the points appear there. There is no post-processing that simplifies the representation afterwards. Concerning the circle test, I guess you mixed the arrays. What is really in the code is that the vertices2 array is build first from outer circle and the vertices1 array is built afterwards from inner circle. So you are really subtracting a big disk from a smaller one. As Thomas explained, computing set2 minus set1 give the expected two boundaries. Another possible change is to build the circles clockwise instead of counter-clockwise, and in this case the two regions are infinite wich a whole at the center, then subtracting set2 from set1 returns a disk with a hole. Polygon difference function produces erroneous results with certain polygons Key: MATH-668 URL: https://issues.apache.org/jira/browse/MATH-668 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Curtis Jensen Assignee: Luc Maisonobe Labels: difference, math,, polygon, Fix For: 3.0 Attachments: PolygonsSetCircleTest.java, PolygonsSetTest.java Original Estimate: 168h Remaining Estimate: 168h For some polygons, the difference function produces erroneous results. This appears to happen when one polygon is completely encompassed in another, and the outer has multiple concave sections. -- 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] (CODEC-139) DigestUtils: additional utility methods
[ https://issues.apache.org/jira/browse/CODEC-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastien Dubois updated CODEC-139: --- Attachment: DigestUtils-patch-updated-2012-04-20.txt Updated version of the patch with unit tests correct code DigestUtils: additional utility methods --- Key: CODEC-139 URL: https://issues.apache.org/jira/browse/CODEC-139 Project: Commons Codec Issue Type: Improvement Reporter: Sebastien Dubois Priority: Trivial Labels: patch Attachments: DigestUtils-patch-updated-2012-04-20.txt, DigestUtils-patch.txt Original Estimate: 10m Remaining Estimate: 10m I've slightly modified the DigestUtils class: - changed the visibility (protected -- public) of a few methods: these methods are generally useful if one just wants to get a MessageDigest instance for a given algorithm - added two 'updateDigest' methods which can be used to add more data to digest to the provided MessageDigest. The advantage for the one that accepts a String argument is that it keeps the same logic as the rest of DigestUtils (uses getBytesUtf8). The second one which accepts a byte array is there for consistency -- 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-780) BSPTree class and recovery of a Euclidean 3D BRep
[ https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Willis updated MATH-780: --- Attachment: BSPMesh2.java New version. Hopefully no missing references. BSPTree class and recovery of a Euclidean 3D BRep - Key: MATH-780 URL: https://issues.apache.org/jira/browse/MATH-780 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: Linux Reporter: Andrew Willis Labels: BSPTree, euclidean.threed Attachments: BSPMesh2.java, BSPMesh2.java New to the work here. Thanks for your efforts on this code. I create a BSPTree from a BoundaryRep (Brep) my test Brep is a cube as represented by a float array containing 8 3D points in(x,y,z) order and an array of indices (12 triplets for the 12 faces of the cube). I construct a BSPMesh() as shown in the code below. I can construct the PolyhedronsSet() but have problems extracting the faces from the BSPTree to reconstruct the BRep. The attached code (BSPMesh2.java) shows that a small change to 1 of the vertex positions causes/corrects the problem. Any ideas? -- 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-780) BSPTree class and recovery of a Euclidean 3D BRep
[ https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Willis updated MATH-780: --- Attachment: BSPMesh2.java BSPTree class and recovery of a Euclidean 3D BRep - Key: MATH-780 URL: https://issues.apache.org/jira/browse/MATH-780 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: Linux Reporter: Andrew Willis Labels: BSPTree, euclidean.threed Attachments: BSPMesh2.java, BSPMesh2.java, BSPMesh2.java New to the work here. Thanks for your efforts on this code. I create a BSPTree from a BoundaryRep (Brep) my test Brep is a cube as represented by a float array containing 8 3D points in(x,y,z) order and an array of indices (12 triplets for the 12 faces of the cube). I construct a BSPMesh() as shown in the code below. I can construct the PolyhedronsSet() but have problems extracting the faces from the BSPTree to reconstruct the BRep. The attached code (BSPMesh2.java) shows that a small change to 1 of the vertex positions causes/corrects the problem. Any ideas? -- 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-780) BSPTree class and recovery of a Euclidean 3D BRep
[ https://issues.apache.org/jira/browse/MATH-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258584#comment-13258584 ] Andrew Willis edited comment on MATH-780 at 4/20/12 9:01 PM: - New version. Hopefully no missing references. I have removed references to the PolygonOfPoints class and fixed the constructor error. I have created a class specifically for the bug report and apologies for not making it cleaner/more clear. I'm working on an exact arithmetic version of BSPTrees for CSG operations. I hope to contribute the code if it's of value to the project. Initially i'll use Java's BigDecimal classes for arbitrary arithmetic but I plan on performance enhancements per JR Shewchuk's work (orient3d() etc., http://www.cs.cmu.edu/~quake/robust.html). hope this code (latest version of BSPMesh2.java) helps. was (Author: arwillis): New version. Hopefully no missing references. BSPTree class and recovery of a Euclidean 3D BRep - Key: MATH-780 URL: https://issues.apache.org/jira/browse/MATH-780 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: Linux Reporter: Andrew Willis Labels: BSPTree, euclidean.threed Attachments: BSPMesh2.java, BSPMesh2.java, BSPMesh2.java New to the work here. Thanks for your efforts on this code. I create a BSPTree from a BoundaryRep (Brep) my test Brep is a cube as represented by a float array containing 8 3D points in(x,y,z) order and an array of indices (12 triplets for the 12 faces of the cube). I construct a BSPMesh() as shown in the code below. I can construct the PolyhedronsSet() but have problems extracting the faces from the BSPTree to reconstruct the BRep. The attached code (BSPMesh2.java) shows that a small change to 1 of the vertex positions causes/corrects the problem. Any ideas? -- 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] (CODEC-139) DigestUtils: add updateDigest methods and make methods public.
[ https://issues.apache.org/jira/browse/CODEC-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-139: -- Summary: DigestUtils: add updateDigest methods and make methods public. (was: DigestUtils: additional utility methods) DigestUtils: add updateDigest methods and make methods public. -- Key: CODEC-139 URL: https://issues.apache.org/jira/browse/CODEC-139 Project: Commons Codec Issue Type: Improvement Reporter: Sebastien Dubois Priority: Trivial Labels: patch Attachments: DigestUtils-patch-updated-2012-04-20.txt, DigestUtils-patch.txt Original Estimate: 10m Remaining Estimate: 10m I've slightly modified the DigestUtils class: - changed the visibility (protected -- public) of a few methods: these methods are generally useful if one just wants to get a MessageDigest instance for a given algorithm - added two 'updateDigest' methods which can be used to add more data to digest to the provided MessageDigest. The advantage for the one that accepts a String argument is that it keeps the same logic as the rest of DigestUtils (uses getBytesUtf8). The second one which accepts a byte array is there for consistency -- 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] (CODEC-139) DigestUtils: add updateDigest methods and make methods public.
[ https://issues.apache.org/jira/browse/CODEC-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-139. --- Resolution: Fixed Fix Version/s: 1.7 Committed revision 1328553. DigestUtils: add updateDigest methods and make methods public. -- Key: CODEC-139 URL: https://issues.apache.org/jira/browse/CODEC-139 Project: Commons Codec Issue Type: Improvement Reporter: Sebastien Dubois Priority: Trivial Labels: patch Fix For: 1.7 Attachments: DigestUtils-patch-updated-2012-04-20.txt, DigestUtils-patch.txt Original Estimate: 10m Remaining Estimate: 10m I've slightly modified the DigestUtils class: - changed the visibility (protected -- public) of a few methods: these methods are generally useful if one just wants to get a MessageDigest instance for a given algorithm - added two 'updateDigest' methods which can be used to add more data to digest to the provided MessageDigest. The advantage for the one that accepts a String argument is that it keeps the same logic as the rest of DigestUtils (uses getBytesUtf8). The second one which accepts a byte array is there for consistency -- 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
