[jira] Commented: (IO-167) Fix case-insensitive string handling
[ https://issues.apache.org/jira/browse/IO-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601085#action_12601085 ] Niall Pemberton commented on IO-167: Benjamin, thanks for the explanation, I have applied the FileSystemUtils part of the patch: http://svn.apache.org/viewvc?view=rev&revision=661646 > Is wildcardMatch() meant to be platform-dependent? I wasn't around when the IOCase functionality was developed, so I don't know the original intent and I guess that the issue wasn't even considered. AFAIK, in all the other places its used, its used in conjunction with String's equalsIgnoreCase() so IMO I think we should make it consistent with that. > Fix case-insensitive string handling > > > Key: IO-167 > URL: https://issues.apache.org/jira/browse/IO-167 > Project: Commons IO > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Benjamin Bentmann > Fix For: 2.0 > > Attachments: IO-167-a.patch, IO-167.patch, IO-167.patch > > > Case-insensitive operations are currently platform-dependent, please see > [Common Bug #3|http://www.nabble.com/Re%3A-Common-Bugs-p14931921s177.html] > for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CHAIN-44) CatalogFactory instance variable prevents ChainProcessor from being serializable
[ https://issues.apache.org/jira/browse/CHAIN-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved CHAIN-44. -- Resolution: Fixed Fixed http://svn.apache.org/viewvc?view=rev&revision=661360 > CatalogFactory instance variable prevents ChainProcessor from being > serializable > > > Key: CHAIN-44 > URL: https://issues.apache.org/jira/browse/CHAIN-44 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CHAIN-44) CatalogFactory instance varibale prevents ChainProcessor from being serializable
CatalogFactory instance varibale prevents ChainProcessor from being serializable Key: CHAIN-44 URL: https://issues.apache.org/jira/browse/CHAIN-44 Project: Commons Chain Issue Type: Bug Affects Versions: 1.1 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-167) Fix case-insensitive string handling
[ https://issues.apache.org/jira/browse/IO-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599608#action_12599608 ] Niall Pemberton commented on IO-167: I think we should close this as WONTFIX * I don't believe the FileSystemUtils changes will make any difference to their operation * the package-private IOCase convertCase() method is only used by the FilenameUtils's wildcardMatch() method - it seems wrong to me to hard-code English in principle > Fix case-insensitive string handling > > > Key: IO-167 > URL: https://issues.apache.org/jira/browse/IO-167 > Project: Commons IO > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Benjamin Bentmann > Attachments: IO-167.patch > > > Case-insensitive operations are currently platform-dependent, please see > [Common Bug #3|http://www.nabble.com/Re%3A-Common-Bugs-p14931921s177.html] > for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-140: --- Issue Type: Improvement (was: Wish) > IO 2.0 - Move to JDK 1.5 > > > Key: IO-140 > URL: https://issues.apache.org/jira/browse/IO-140 > Project: Commons IO > Issue Type: Improvement >Reporter: Niall Pemberton > Fix For: 2.0 > > Attachments: IO-2.0-deprecate-and-jdk5.patch > > > I just created IO-139 for a StringBuilder Writer implementation that requies > JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all > deprecations and 2) Making appropriate JDK 1.5 changes (generics, using > StringBuilder and new Appendable for Writers). Below is a summary, thought it > could be a starting point for discussion about IO 2.0 > 1) DEPRECATIONS > - CopyUtils > - FileCleaner > - WildcardFilter > - FileSystemUtils freeSpace(String) > - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) > 2) JDK 1.5 > - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter > implementations > - getFileFilters() and setFileFilters() use generic List > - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, > WildcardFileFilter use generic List > - replace StringBuffer with StringBuilder where appropriate > (FilenameUtils, FileSystemUtils, HexDump,IOUtils > - FileUtils > - convertFileCollectionToFileArray() --> Collection > - listFiles() --> Collection > - listFiles() --> Collection > - writeStringToFile String-->CharSequence (JDK 1.4+) > - ProxyReader - add read(CharBuffer) > - IOUtils > - readLines(Reader) return List > - toInputStream(String) --> toInputStream(CharSequence) (JDK 1.4+) > - write(String data, OutputStream) and write(StringBuffer data, > OutputStream) --> write(CharSequence data, OutputStream) > - write(String, Writer) and write(StringBuffer, Writer) --> > write(CharSequence data, Writer) > - LineIterator Iterator --> Iterator - NullWriter - add "Appendable" methods > - ProxyWriter - add "Appendable" methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-30: --- Attachment: (was: COMMONSSITE-30-module-profiles-v3.patch) > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v4.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-30: --- Attachment: COMMONSSITE-30-module-profiles-v4.patch Updating patch to include a trunks-sandbox profile in the commons-sandbox-parent pom > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v4.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-30: --- Attachment: (was: COMMONSSITE-30-module-profiles-v2.patch) > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v3.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-30: --- Attachment: COMMONSSITE-30-module-profiles-v3.patch Attaching v2 of the patch: COMMONSSITE-30-module-profiles-v3.patch All seems to work OK now except for the following: * The source and test xref's don't get generated for individual components * The individual sites don't have their own custom menus at the top - uses the standard commons one So atm its no good for re-generating/deploying all the component sites - but its useful for cleaning, testing and testing commons-parent pom changes (e.g. upgrading a plugin version and seeing if it affects any components). So I think this change should be applied - its non-invasive since its in a separate profile - if you don't activate that profile, then it doesn't affect anyone. If no-one objects I'll commit this. > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v2.patch, > COMMONSSITE-30-module-profiles-v3.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599283#action_12599283 ] Niall Pemberton commented on COMMONSSITE-30: The checkstyle configuration in component poms was the next problem to cause this to fail - I've fixed all the components that use checkstyle: http://svn.apache.org/viewvc?view=rev&revision=659438 > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v2.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-30: --- Attachment: (was: COMMONSSITE-30-module-profiles.patch) > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v2.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-30: --- Attachment: COMMONSSITE-30-module-profiles-v2.patch The JavaDoc problems can be fixed by upgrading to the latest maven-javadoc-plugin and setting aggregate to false. Attaching a revised patch for commons-parent: * COMMONSSITE-30-module-profiles-v2.patch We have a couple of multi-moduie projects (JCI and VFS from memory) - so would probably need to configure the maven-javadoc-plugin with aggregate set to true in their component poms. > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v2.patch, > COMMONSSITE-30-module-profiles.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COMMONSSITE-30) Add Module profiles to parent poms
Add Module profiles to parent poms -- Key: COMMONSSITE-30 URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 Project: Commons All Issue Type: Improvement Components: Commons Parent Pom Reporter: Niall Pemberton Attachments: COMMONSSITE-30-module-profiles.patch Seeing the felix project's pom with different modules in profiles made me think this might be useful for commons - with "trunks-proper" or "trunks-sandbox". I tried it out, but running mvn -Ptrunks-proper site failed bizarely: * on commons-io it objected to JDK 1.5 features saying the source option was 1.3 - so it seemed to be using the commons-parent default, rather than the individual property setting for projects * on lang though it objected to enum - so seemed to ignore those settings. Perhaps someone else knows how to get it working properly - at the least its useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-30: --- Attachment: COMMONSSITE-30-module-profiles.patch Attaching a patch in case anyone else wants to play with it > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHAIN-33) Upgrade to Digester 1.8 to fix bug loading webapp resources
[ https://issues.apache.org/jira/browse/CHAIN-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598578#action_12598578 ] Niall Pemberton commented on CHAIN-33: -- See https://issues.apache.org/struts/browse/STR-3143 > Upgrade to Digester 1.8 to fix bug loading webapp resources > --- > > Key: CHAIN-33 > URL: https://issues.apache.org/jira/browse/CHAIN-33 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 1.2 > > > Upgrade to the new Digester 1.8 version: >http://jakarta.apache.org/commons/digester/ > Digester 1.8 has fixed DIGESTER-29 where loading of resources can cause a > webapp to fail on redeploy and DIGESTER-110 provides a new parse(URL) method > which means similar logic can be removed from Chain -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHAIN-41) Can't build latest source code due to usage of old Digester
[ https://issues.apache.org/jira/browse/CHAIN-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated CHAIN-41: - Fix Version/s: 1.2 Assignee: Simon Kitching > Can't build latest source code due to usage of old Digester > --- > > Key: CHAIN-41 > URL: https://issues.apache.org/jira/browse/CHAIN-41 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 1.1, 1.2, Nightly Builds >Reporter: Isaac Shabtay >Assignee: Simon Kitching > Fix For: 1.2 > > Attachments: patch-build.txt > > > Currently, build.xml retrieves Digester 1.6 for using as a build path entry. > However, Digester 1.6 doesn't appear to have the Digester.parse(URL) method. > This causes org.apache.commons.chain.config.ConfigParser to fail building. > Switched to use Digester 1.8 and builds fine. Testers work as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHAIN-40) ContextBase should use LinkedHashMap
[ https://issues.apache.org/jira/browse/CHAIN-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598487#action_12598487 ] Niall Pemberton commented on CHAIN-40: -- Requires moving Commons Chain to a mimimum of JDK 1.4 > ContextBase should use LinkedHashMap > > > Key: CHAIN-40 > URL: https://issues.apache.org/jira/browse/CHAIN-40 > Project: Commons Chain > Issue Type: Improvement >Reporter: Cédric BODIN >Priority: Minor > > org.apache.commons.chain.impl.ContextBase should use java.util.LinkedHashMap > (instead of java.util.HashMap) : as its superclass, and as the java.util.Map > implementation for its "descriptors" attribute. > Indeed LinkedHashMap allow "insertion-order" iteration over the context, > which is an additional information about the chain execution (to know the > order of the commands into the chain). > Moreover LinkedHashMap is a HashMap : so this enhancement is "transparent" > for users who didn't/don't/won't want to presume about context's iteration > order. > Thanks in advance. > Cédric BODIN -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CHAIN-43) ChainListener URL translation does not work as expected
[
https://issues.apache.org/jira/browse/CHAIN-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved CHAIN-43.
--
Resolution: Fixed
Fix Version/s: 1.2
Assignee: Niall Pemberton
Fixed thanks - http://svn.apache.org/viewvc?view=rev&revision=658426
P.S. The reason for not using replaceAll is that wasn't introduced until JDK
1.4 and Chain is still targetting JDK 1.3 as a minimum
> ChainListener URL translation does not work as expected
> ---
>
> Key: CHAIN-43
> URL: https://issues.apache.org/jira/browse/CHAIN-43
> Project: Commons Chain
> Issue Type: Bug
>Affects Versions: 1.1, Nightly Builds
>Reporter: Ales Dolecek
>Assignee: Niall Pemberton
>Priority: Trivial
> Fix For: 1.2
>
>
> Method org.apache.commons.chain.web.ChainListener#translate(String) simply
> discards any spaces in URL instead of replacing them with %20 as stated in
> it's documentation.
> As result the configuration form chain-config.xml files stored in JAR files
> on path with spaces is not processed.
> BTW: Why not use
> jarURL.toExternalForm().replaceAll(" ", "%20")
> instead of
> translate(jarURL.toExternalForm())
> AlesD
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-315) Converter for XML Schema 'dateTime' type
[ https://issues.apache.org/jira/browse/BEANUTILS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598441#action_12598441 ] Niall Pemberton commented on BEANUTILS-315: --- The next planned release for BeanUtils is 1.8.0, but that is targetted at JDK 1.3 and since this converter uses java.util.regex.Pattern and therefore requires JDK 1.4 then it will have to wait until after that. Also given that the 1.8.0 release hasn't yet happened in over a year then I'm not even sure that there will ever be another release after that - so the following comment may be academic anyway. I would prefer if your implementation extended from AbstractConverter[1] - which means implementing the following methods: * protected String convertToString(value) * protected Object convertToType(Class, value) * protected Class getDefaultType() [1] http://svn.apache.org/repos/asf/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractConverter.java > Converter for XML Schema 'dateTime' type > > > Key: BEANUTILS-315 > URL: https://issues.apache.org/jira/browse/BEANUTILS-315 > Project: Commons BeanUtils > Issue Type: New Feature > Components: ConvertUtils & Converters >Reporter: Christopher Schultz >Priority: Minor > Attachments: XMLDateTimeConverter.java, XMLDateTimeConverterTests.java > > > I have developed a converter implementation that can convert XML Schema > 'dateTime' (xs:dateTime) types into java.util.Date and would like to donate > it to the project. > This Converter is being used with commons-digester successfully in one of my > projects, and a series of posts on the commons-user list led me to believe > that commons-beanutils was an appropriate place to file an enhancement > request. > A proposed implementation is forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CHAIN-42) Various scope mappers use incorrect equalization
[ https://issues.apache.org/jira/browse/CHAIN-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved CHAIN-42. -- Resolution: Fixed Fix Version/s: 1.2 Assignee: Niall Pemberton Fixed, thanks for the patch http://svn.apache.org/viewvc?view=rev&revision=658355 > Various scope mappers use incorrect equalization > > > Key: CHAIN-42 > URL: https://issues.apache.org/jira/browse/CHAIN-42 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 1.1 > Environment: All >Reporter: Isaac Shabtay >Assignee: Niall Pemberton > Fix For: 1.2 > > Attachments: patch-equals.txt > > > The following classes: > org.apache.commons.chain.web.portlet.PortletApplicationScopeMap > org.apache.commons.chain.web.portlet.PortletRequestScopeMap > org.apache.commons.chain.web.portlet.PortletSessionScopeMap > org.apache.commons.chain.web.servlet.ServletApplicationScopeMap > org.apache.commons.chain.web.servlet.ServletRequestScopeMap > org.apache.commons.chain.web.servlet.ServletSessionScopeMap > use the "==" for comparison in their containsValue(Object) methods. This is > in contrary to java.util.Map's specification which mandates that the > containsValue(v1) method returns true if and only if there exists a value 'v' > in the map such that v1.equals(v). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHAIN-42) Various scope mappers use incorrect equalization
[ https://issues.apache.org/jira/browse/CHAIN-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated CHAIN-42: - Affects Version/s: (was: 1.2) > Various scope mappers use incorrect equalization > > > Key: CHAIN-42 > URL: https://issues.apache.org/jira/browse/CHAIN-42 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 1.1 > Environment: All >Reporter: Isaac Shabtay > Fix For: 1.2 > > Attachments: patch-equals.txt > > > The following classes: > org.apache.commons.chain.web.portlet.PortletApplicationScopeMap > org.apache.commons.chain.web.portlet.PortletRequestScopeMap > org.apache.commons.chain.web.portlet.PortletSessionScopeMap > org.apache.commons.chain.web.servlet.ServletApplicationScopeMap > org.apache.commons.chain.web.servlet.ServletRequestScopeMap > org.apache.commons.chain.web.servlet.ServletSessionScopeMap > use the "==" for comparison in their containsValue(Object) methods. This is > in contrary to java.util.Map's specification which mandates that the > containsValue(v1) method returns true if and only if there exists a value 'v' > in the map such that v1.equals(v). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-221) Javaoc for new classes in 2.0 should have @since 2.0
[ https://issues.apache.org/jira/browse/NET-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated NET-221: Affects Version/s: 1.5 Added for both the trunk / Net 1.5 and branch / Net 2.0: http://svn.apache.org/viewvc?view=rev&revision=657989 http://svn.apache.org/viewvc?view=rev&revision=657990 > Javaoc for new classes in 2.0 should have @since 2.0 > > > Key: NET-221 > URL: https://issues.apache.org/jira/browse/NET-221 > Project: Commons Net > Issue Type: Bug >Affects Versions: 1.5, 2.0 >Reporter: Sebb >Priority: Minor > > It would be helpful to identify the classes that are new to 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SANDBOX-240) Caching of URLStreamHandler by the URL class
Caching of URLStreamHandler by the URL class Key: SANDBOX-240 URL: https://issues.apache.org/jira/browse/SANDBOX-240 Project: Commons Sandbox Issue Type: Bug Components: JNet Reporter: Niall Pemberton Priority: Minor I've been having a look at JNet to try and get an understanding of what it does - from looking at the source code and Carsten's initial post: http://markmail.org/message/tm3wzgxk3fq3o7s3 Seems that the idea is to be able to provide different URLStreamHandler implementations for different applications running in the same JVM. So for example, if I had two webapps the required different handlers for the "file" protocol - then I should be able to do that using JNet? In some thread somewhere, someone mentioned that felix was already doing something similar - so I took a look at their URLStreamHandlerFactory implementation: http://svn.apache.org/repos/asf/felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlers.java ...which serves up "proxy" URLStreamHandler implementations for all protocols because, as it says in the comments, the URL class caches URLStreamHandler implementations for each protocol - and looking at the Harmony implementation of URL, this is the case: http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URL.java So this seems like it would defeat the main point of JNet - since once URL has cached the URLStreamHandler for a protocol, then it won't even go to the registered URLStreamHandlerFactory after that and DynamicURLStreamHandlerFactory won't be asked to serve up whatever factory is set in its "current execution context". Is this right or have I got the wrong end of the stick? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-436) Remove caching from MethodUtils
[ https://issues.apache.org/jira/browse/LANG-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-436. -- Resolution: Fixed Fix Version/s: 3.0 OK removed http://svn.apache.org/viewvc?view=rev&revision=654159 > Remove caching from MethodUtils > --- > > Key: LANG-436 > URL: https://issues.apache.org/jira/browse/LANG-436 > Project: Commons Lang > Issue Type: Bug >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 3.0 > > Attachments: LANG-436-remove-MethodUtils-caching.patch > > > I think we should remove the caching from MethodUtils. This has caused memory > leak problems in BeanUtils (where it was copied from) and better IMO to just > provide the pure reflection API in lang and let downstream users provide > solutions for improving performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-436) Remove caching from MethodUtils
[ https://issues.apache.org/jira/browse/LANG-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-436: - Attachment: LANG-436-remove-MethodUtils-caching.patch Attaching a patch to remove caching from MethodUtils, which I plan to apply > Remove caching from MethodUtils > --- > > Key: LANG-436 > URL: https://issues.apache.org/jira/browse/LANG-436 > Project: Commons Lang > Issue Type: Bug >Reporter: Niall Pemberton > Attachments: LANG-436-remove-MethodUtils-caching.patch > > > I think we should remove the caching from MethodUtils. This has caused memory > leak problems in BeanUtils (where it was copied from) and better IMO to just > provide the pure reflection API in lang and let downstream users provide > solutions for improving performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-436) Remove caching from MethodUtils
Remove caching from MethodUtils --- Key: LANG-436 URL: https://issues.apache.org/jira/browse/LANG-436 Project: Commons Lang Issue Type: Bug Reporter: Niall Pemberton I think we should remove the caching from MethodUtils. This has caused memory leak problems in BeanUtils (where it was copied from) and better IMO to just provide the pure reflection API in lang and let downstream users provide solutions for improving performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-312) Expose the caches in PropertyBeanUtils so they can be controlled if needed
[ https://issues.apache.org/jira/browse/BEANUTILS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594866#action_12594866 ] Niall Pemberton commented on BEANUTILS-312: --- I will review this properly but from a quick peek, the API changes will prevent this from being included in BeanUtils 1.8.0 since were aiming for binary compatibility with BeanUtils 1.7.0 for that release. > Expose the caches in PropertyBeanUtils so they can be controlled if needed > -- > > Key: BEANUTILS-312 > URL: https://issues.apache.org/jira/browse/BEANUTILS-312 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Aaron Zeckoski > Fix For: 1.8.0 > > Attachments: > beanutils-add-cache-setters-getters-remove-fasthashmap.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > We have an extension to commons beanutils which allows us to make it > work with public fields as well (and a few other improvements we > needed like deep cloning). In 1.8.0-BETA it is easier to handle this > extension (thanks!) but it could be even easier if there was a way to > get and set the caches which are used for storing the > PropertyDescriptors. Just switching the type from FastHashMap to Map > and making a setter and getter which are publicly visible would be > enough to reduce our the work in extending this significantly. > The attached patch exposes the caches in PropertyBeanUtils and sets them to > be Map instead of FastHashMap. This also involves a change to PropertyUtils > (also changing FastHashMap to Map). The patch is fairly small and was built > again the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-312) Expose the caches in PropertyBeanUtils so they can be controlled if needed
[ https://issues.apache.org/jira/browse/BEANUTILS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-312: -- Comment: was deleted > Expose the caches in PropertyBeanUtils so they can be controlled if needed > -- > > Key: BEANUTILS-312 > URL: https://issues.apache.org/jira/browse/BEANUTILS-312 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Aaron Zeckoski > Fix For: 1.8.0 > > Attachments: > beanutils-add-cache-setters-getters-remove-fasthashmap.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > We have an extension to commons beanutils which allows us to make it > work with public fields as well (and a few other improvements we > needed like deep cloning). In 1.8.0-BETA it is easier to handle this > extension (thanks!) but it could be even easier if there was a way to > get and set the caches which are used for storing the > PropertyDescriptors. Just switching the type from FastHashMap to Map > and making a setter and getter which are publicly visible would be > enough to reduce our the work in extending this significantly. > The attached patch exposes the caches in PropertyBeanUtils and sets them to > be Map instead of FastHashMap. This also involves a change to PropertyUtils > (also changing FastHashMap to Map). The patch is fairly small and was built > again the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-312) Expose the caches in PropertyBeanUtils so they can be controlled if needed
[ https://issues.apache.org/jira/browse/BEANUTILS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594865#action_12594865 ] Niall Pemberton commented on BEANUTILS-312: --- I will review this properly when I get time - but from a quick peek the problem for 1.8.0 is going to be the API changes - since we're aiming for binary compatibility with BeanUtils 1.7.0 for the next release > Expose the caches in PropertyBeanUtils so they can be controlled if needed > -- > > Key: BEANUTILS-312 > URL: https://issues.apache.org/jira/browse/BEANUTILS-312 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Aaron Zeckoski > Fix For: 1.8.0 > > Attachments: > beanutils-add-cache-setters-getters-remove-fasthashmap.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > We have an extension to commons beanutils which allows us to make it > work with public fields as well (and a few other improvements we > needed like deep cloning). In 1.8.0-BETA it is easier to handle this > extension (thanks!) but it could be even easier if there was a way to > get and set the caches which are used for storing the > PropertyDescriptors. Just switching the type from FastHashMap to Map > and making a setter and getter which are publicly visible would be > enough to reduce our the work in extending this significantly. > The attached patch exposes the caches in PropertyBeanUtils and sets them to > be Map instead of FastHashMap. This also involves a change to PropertyUtils > (also changing FastHashMap to Map). The patch is fairly small and was built > again the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-263) Binary download contains Javadoc
[ https://issues.apache.org/jira/browse/VALIDATOR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-263. --- Resolution: Invalid Looks fine to me > Binary download contains Javadoc > > > Key: VALIDATOR-263 > URL: https://issues.apache.org/jira/browse/VALIDATOR-263 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.3.1 Release >Reporter: Ken Hammond > > I'm trying to get the most up to date JAR, but the binary downloads contain > Javadoc files instead of binaries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CODEC-64) Add svn:eol-style=native
[ https://issues.apache.org/jira/browse/CODEC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved CODEC-64. -- Resolution: Fixed Fix Version/s: 1.4 Assignee: Niall Pemberton > Add svn:eol-style=native > > > Key: CODEC-64 > URL: https://issues.apache.org/jira/browse/CODEC-64 > Project: Commons Codec > Issue Type: Task >Reporter: Benjamin Bentmann >Assignee: Niall Pemberton >Priority: Trivial > Fix For: 1.4 > > Attachments: svn-eol-style-native.patch > > > [Configuring the Subversion > client|http://www.apache.org/dev/version-control.html#https-svn-config]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CLI-153) Add svn:eol-style=native
[ https://issues.apache.org/jira/browse/CLI-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved CLI-153. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Niall Pemberton > Add svn:eol-style=native > > > Key: CLI-153 > URL: https://issues.apache.org/jira/browse/CLI-153 > Project: Commons CLI > Issue Type: Task >Reporter: Benjamin Bentmann >Assignee: Niall Pemberton >Priority: Trivial > Fix For: 2.0 > > Attachments: svn-eol-style-native.patch > > > [Configuring the Subversion > client|http://www.apache.org/dev/version-control.html#https-svn-config]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-165) Add svn:eol-style=native
[ https://issues.apache.org/jira/browse/IO-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-165. Resolution: Fixed Fix Version/s: 2.0 Assignee: Niall Pemberton > Add svn:eol-style=native > > > Key: IO-165 > URL: https://issues.apache.org/jira/browse/IO-165 > Project: Commons IO > Issue Type: Task >Affects Versions: 1.4 >Reporter: Benjamin Bentmann >Assignee: Niall Pemberton >Priority: Trivial > Fix For: 2.0 > > Attachments: svn-eol-style-native.patch > > > [Configuring the Subversion > client|http://www.apache.org/dev/version-control.html#https-svn-config]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-291) Circular Reference on WeakHashMap
[ https://issues.apache.org/jira/browse/BEANUTILS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591884#action_12591884 ] Niall Pemberton commented on BEANUTILS-291: --- Thanks for the patch - I have applied the changes to MemoryLeakTestCase and configured maven to limit the memory as you suggest: http://svn.apache.org/viewvc?view=rev&revision=651114 For the other changes (i.e. to PropertyUtilsBean, LocaleConvertUtilsBean, FastHashMap and the new WeakFastHashMap) I need to think about them. Your patch has highligted that I screwed up in removing the use of FastHashMap in PropertyUtilsBean - I had a false memory that in "fast" mode it was operating like a normal Map (rather than syncronizing/cloning). However I don't want to change the FastHashMap implementation since this is a copy from Commons Collections and if Collections and BeanUtils are both on the classpath, its arbitary which version will be loaded. > Circular Reference on WeakHashMap > - > > Key: BEANUTILS-291 > URL: https://issues.apache.org/jira/browse/BEANUTILS-291 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Niall Pemberton > Fix For: 1.8.0 > > Attachments: BEANUTILS-291-FixMemoryLeaks-v2.patch, > memoryLeakTests-new.zip, PropertyUtilsBean.java, > ThreadIsolationAndTestImprovement2.patch > > > Clebert Suconic wrote on the [EMAIL PROTECTED] list > (see http://tinyurl.com/2a9gan) > I have been investigating WeakHashMaps on BeanUtils 1.8 as part of a > investigation on this: > http://jira.jboss.com/jira/browse/JBAS-2299 > (Which is not actually an issue with JBAS, but an issue when using BeanUtils > as part of the classPath). > There is a circular reference on the WeakHashMap, The WeakHashMap will have > the ClassLoader as the key, and it will have a reference back to the Key from > one of the Reflection objects. This doesn't work! (Please.. no discussions > about this point.. if you don't believe me, do some testing with simple stuff > before discussing this and come back to me only after that) > [EMAIL PROTECTED] > !--- [EMAIL PROTECTED] > !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- [Ljava.lang.Object;@10800875 > !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- !--- !--- !--- !--- class java.lang.Class > !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [Ljava.util.HashMap$Entry;@28236766 > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !-- -!--- !--- !--- !--- !--- !--- > !---FieldReference private java.lang.Object [EMAIL PROTECTED] Detail > I don't know if I'm preaching to the choir, but just in case this is new > information to someone... you should aways keep Reflection referenced as > SoftReferences (if you really have to). Reflection is aways a new object so a > WeakReference is too weak. > On JBossSerialization I have solved this using an interesting way. I called > it PersistentReference. I'm using SoftReferences, and keeping the information > to recreate it case the SoftReference is cleared: > http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3 > And also... you guys should write a testcase to validate if the Caching is > being cleared. (I don't know if you have one). > http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java > You don't need to use the jboss-profiler API for this.. just create a > WeakReference to a new ClassLoader, and validate if it was released at the > end after some exercizing some code on this caching. You will > probably need to fill your memory almost to 100% on the test as SoftReference > are only gone when the memory is low. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-291) Circular Reference on WeakHashMap
[ https://issues.apache.org/jira/browse/BEANUTILS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591164#action_12591164 ] Niall Pemberton commented on BEANUTILS-291: --- I created a 1.8.0 RC1 for review here: http://people.apache.org/~niallp/beanutils-1.8.0-rc1/ RC1 thread: http://commons.markmail.org/message/lvy36frxdi2t2rxz > Circular Reference on WeakHashMap > - > > Key: BEANUTILS-291 > URL: https://issues.apache.org/jira/browse/BEANUTILS-291 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Niall Pemberton > Fix For: 1.8.0 > > Attachments: BEANUTILS-291-FixMemoryLeaks-v2.patch, > memoryLeakTests-new.zip, PropertyUtilsBean.java > > > Clebert Suconic wrote on the [EMAIL PROTECTED] list > (see http://tinyurl.com/2a9gan) > I have been investigating WeakHashMaps on BeanUtils 1.8 as part of a > investigation on this: > http://jira.jboss.com/jira/browse/JBAS-2299 > (Which is not actually an issue with JBAS, but an issue when using BeanUtils > as part of the classPath). > There is a circular reference on the WeakHashMap, The WeakHashMap will have > the ClassLoader as the key, and it will have a reference back to the Key from > one of the Reflection objects. This doesn't work! (Please.. no discussions > about this point.. if you don't believe me, do some testing with simple stuff > before discussing this and come back to me only after that) > [EMAIL PROTECTED] > !--- [EMAIL PROTECTED] > !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- [Ljava.lang.Object;@10800875 > !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- !--- !--- !--- !--- class java.lang.Class > !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [Ljava.util.HashMap$Entry;@28236766 > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !-- -!--- !--- !--- !--- !--- !--- > !---FieldReference private java.lang.Object [EMAIL PROTECTED] Detail > I don't know if I'm preaching to the choir, but just in case this is new > information to someone... you should aways keep Reflection referenced as > SoftReferences (if you really have to). Reflection is aways a new object so a > WeakReference is too weak. > On JBossSerialization I have solved this using an interesting way. I called > it PersistentReference. I'm using SoftReferences, and keeping the information > to recreate it case the SoftReference is cleared: > http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3 > And also... you guys should write a testcase to validate if the Caching is > being cleared. (I don't know if you have one). > http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java > You don't need to use the jboss-profiler API for this.. just create a > WeakReference to a new ClassLoader, and validate if it was released at the > end after some exercizing some code on this caching. You will > probably need to fill your memory almost to 100% on the test as SoftReference > are only gone when the memory is low. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-291) Circular Reference on WeakHashMap
[ https://issues.apache.org/jira/browse/BEANUTILS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591028#action_12591028 ] Niall Pemberton commented on BEANUTILS-291: --- Clebert, I have committed the changes to fix the memory issues, including recreating the method reference in MappedPropertyDescriptor. http://svn.apache.org/viewvc?view=rev&revision=650215 If this all looks OK, then I think we can go ahead with a BeanUtils release > Circular Reference on WeakHashMap > - > > Key: BEANUTILS-291 > URL: https://issues.apache.org/jira/browse/BEANUTILS-291 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Niall Pemberton > Fix For: 1.8.0 > > Attachments: BEANUTILS-291-FixMemoryLeaks-v2.patch, > memoryLeakTests-new.zip, PropertyUtilsBean.java > > > Clebert Suconic wrote on the [EMAIL PROTECTED] list > (see http://tinyurl.com/2a9gan) > I have been investigating WeakHashMaps on BeanUtils 1.8 as part of a > investigation on this: > http://jira.jboss.com/jira/browse/JBAS-2299 > (Which is not actually an issue with JBAS, but an issue when using BeanUtils > as part of the classPath). > There is a circular reference on the WeakHashMap, The WeakHashMap will have > the ClassLoader as the key, and it will have a reference back to the Key from > one of the Reflection objects. This doesn't work! (Please.. no discussions > about this point.. if you don't believe me, do some testing with simple stuff > before discussing this and come back to me only after that) > [EMAIL PROTECTED] > !--- [EMAIL PROTECTED] > !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- [Ljava.lang.Object;@10800875 > !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- !--- !--- !--- !--- class java.lang.Class > !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [Ljava.util.HashMap$Entry;@28236766 > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !-- -!--- !--- !--- !--- !--- !--- > !---FieldReference private java.lang.Object [EMAIL PROTECTED] Detail > I don't know if I'm preaching to the choir, but just in case this is new > information to someone... you should aways keep Reflection referenced as > SoftReferences (if you really have to). Reflection is aways a new object so a > WeakReference is too weak. > On JBossSerialization I have solved this using an interesting way. I called > it PersistentReference. I'm using SoftReferences, and keeping the information > to recreate it case the SoftReference is cleared: > http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3 > And also... you guys should write a testcase to validate if the Caching is > being cleared. (I don't know if you have one). > http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java > You don't need to use the jboss-profiler API for this.. just create a > WeakReference to a new ClassLoader, and validate if it was released at the > end after some exercizing some code on this caching. You will > probably need to fill your memory almost to 100% on the test as SoftReference > are only gone when the memory is low. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-163) FileUtils.toURLs() uses deprecated (and bad) method of conversion to URL
[ https://issues.apache.org/jira/browse/IO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-163. Resolution: Fixed Fix Version/s: 2.0 Assignee: Niall Pemberton Fixed thanks http://svn.apache.org/viewvc?view=rev&revision=647000 > FileUtils.toURLs() uses deprecated (and bad) method of conversion to URL > > > Key: IO-163 > URL: https://issues.apache.org/jira/browse/IO-163 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.4 >Reporter: Alex Miller >Assignee: Niall Pemberton >Priority: Minor > Fix For: 2.0 > > > The method FileUtils.toURLs() uses the following method to convert from File > to URL: > File.toURL(); > This method has scary warnings that it's a bad way to do the conversion > because characters will not be escaped as required in URL strings. In Java > 1.6, this method has actually been deprecated. All recent JDK versions > recommend instead using: > File.toURI().toURL(); > as the URI code will properly perform the escaping. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-291) Circular Reference on WeakHashMap
[ https://issues.apache.org/jira/browse/BEANUTILS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587021#action_12587021 ] Niall Pemberton commented on BEANUTILS-291: --- Clebrt, thanks for the feedback. It may take me a week or so to find time to look at this, but thanks for pointing out the issue. I'll look at caching the method info in (weak) references so that it can be re-created if required. > Circular Reference on WeakHashMap > - > > Key: BEANUTILS-291 > URL: https://issues.apache.org/jira/browse/BEANUTILS-291 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Niall Pemberton > Fix For: 1.8.0 > > Attachments: BEANUTILS-291-FixMemoryLeaks-v2.patch, > memoryLeakTests-new.zip, PropertyUtilsBean.java > > > Clebert Suconic wrote on the [EMAIL PROTECTED] list > (see http://tinyurl.com/2a9gan) > I have been investigating WeakHashMaps on BeanUtils 1.8 as part of a > investigation on this: > http://jira.jboss.com/jira/browse/JBAS-2299 > (Which is not actually an issue with JBAS, but an issue when using BeanUtils > as part of the classPath). > There is a circular reference on the WeakHashMap, The WeakHashMap will have > the ClassLoader as the key, and it will have a reference back to the Key from > one of the Reflection objects. This doesn't work! (Please.. no discussions > about this point.. if you don't believe me, do some testing with simple stuff > before discussing this and come back to me only after that) > [EMAIL PROTECTED] > !--- [EMAIL PROTECTED] > !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- [Ljava.lang.Object;@10800875 > !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- !--- !--- !--- !--- class java.lang.Class > !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [Ljava.util.HashMap$Entry;@28236766 > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !-- -!--- !--- !--- !--- !--- !--- > !---FieldReference private java.lang.Object [EMAIL PROTECTED] Detail > I don't know if I'm preaching to the choir, but just in case this is new > information to someone... you should aways keep Reflection referenced as > SoftReferences (if you really have to). Reflection is aways a new object so a > WeakReference is too weak. > On JBossSerialization I have solved this using an interesting way. I called > it PersistentReference. I'm using SoftReferences, and keeping the information > to recreate it case the SoftReference is cleared: > http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3 > And also... you guys should write a testcase to validate if the Caching is > being cleared. (I don't know if you have one). > http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java > You don't need to use the jboss-profiler API for this.. just create a > WeakReference to a new ClassLoader, and validate if it was released at the > end after some exercizing some code on this caching. You will > probably need to fill your memory almost to 100% on the test as SoftReference > are only gone when the memory is low. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-160) [patch] FileSystemUtils.freeSpace fails on solaris
[
https://issues.apache.org/jira/browse/IO-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586740#action_12586740
]
Niall Pemberton commented on IO-160:
Good point, I've made it final
http://svn.apache.org/viewvc?view=rev&revision=645828
> [patch] FileSystemUtils.freeSpace fails on solaris
> ---
>
> Key: IO-160
> URL: https://issues.apache.org/jira/browse/IO-160
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 1.3.2
>Reporter: Mike Bristow
> Attachments: jakarta-commons-io.patch
>
>
> FileSystemUtils.freeSpace fails its tests on Solaris. The following patch
> fixes it, and with it all tests pass on:
> RedHat (FC7, EL3, EL4, CentOS4, CentOS5) and Solaris (8, 9-sparc, 9-i386,
> 10-sparc, 10-i386).
> The fix is to force the use of /usr/xpg4/bin/df on Solaris, which is the
> posix version. This then means that the output-parsing works as expected.
> Index: src/java/org/apache/commons/io/FileSystemUtils.java
> ===
> RCS file:
> /cvsroot/upstream/jpackage/jakarta-commons-io/src/java/org/apache/commons/io/FileSystemUtils.java,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.2.3
> diff -u -r1.1.1.1 -r1.1.1.1.2.3
> --- src/java/org/apache/commons/io/FileSystemUtils.java 2 Mar 2007 06:31:03
> - 1.1.1.1
> +++ src/java/org/apache/commons/io/FileSystemUtils.java 28 Mar 2008 11:56:06
> - 1.1.1.1.2.3
> @@ -64,6 +64,10 @@
>
> /** The operating system flag. */
> private static final int OS;
> +
> +/** The path to df */
> +private static String dfPath = "df";
> +
> static {
> int os = OTHER;
> try {
> @@ -76,9 +80,6 @@
> if (osName.indexOf("windows") != -1) {
> os = WINDOWS;
> } else if (osName.indexOf("linux") != -1 ||
> -osName.indexOf("sun os") != -1 ||
> -osName.indexOf("sunos") != -1 ||
> -osName.indexOf("solaris") != -1 ||
> osName.indexOf("mpe/ix") != -1 ||
> osName.indexOf("freebsd") != -1 ||
> osName.indexOf("irix") != -1 ||
> @@ -86,6 +87,11 @@
> osName.indexOf("unix") != -1 ||
> osName.indexOf("mac os x") != -1) {
> os = UNIX;
> +} else if (osName.indexOf("sun os") != -1 ||
> +osName.indexOf("sunos") != -1 ||
> +osName.indexOf("solaris") != -1) {
> +os = POSIX_UNIX;
> +dfPath = "/usr/xpg4/bin/df";
> } else if (osName.indexOf("hp-ux") != -1 ||
> osName.indexOf("aix") != -1) {
> os = POSIX_UNIX;
> @@ -116,7 +122,7 @@
> * of [EMAIL PROTECTED] #freeSpaceKb(String)} which returns a result in
> kilobytes.
> *
> * Note that some OS's are NOT currently supported, including OS/390,
> - * OpenVMS and and SunOS 5. (SunOS is supported by
> freeSpaceKb.)
> + * OpenVMS.
> *
> * FileSystemUtils.freeSpace("C:"); // Windows
> * FileSystemUtils.freeSpace("/volume"); // *nix
> @@ -317,14 +323,14 @@
> flags += "P";
> }
> String[] cmdAttribs =
> -(flags.length() > 1 ? new String[] {"df", flags, path} : new
> String[] {"df", path});
> +(flags.length() > 1 ? new String[] {dfPath, flags, path} : new
> String[] {dfPath, path});
>
> // perform the command, asking for up to 3 lines (header,
> interesting, overflow)
> List lines = performCommand(cmdAttribs, 3);
> if (lines.size() < 2) {
> // unknown problem, throw exception
> throw new IOException(
> -"Command line 'df' did not return info as expected " +
> +"Command line '" + dfPath + "' did not return info as
> expected " +
> "for path '" + path + "'- response was " + lines);
> }
> String line2 = (String) lines.get(1); // the line we're interested in
> @@ -338,7 +344,7 @@
> tok = new StringTokenizer(line3, " ");
> } else {
> throw new IOException(
> -"Command line 'df' did not return data as expected "
> +
> +"Command line '" + dfPath + "' did not return data
> as expected " +
> "for path '" + path + "'- check path is valid");
> }
> } else {
> @@ -364,14 +370,14 @@
> long bytes = Long.parseLong(freeSpace);
> if (bytes < 0) {
> throw new IOException(
> -"Command line 'df' did not find free space in
> response " +
> +
[jira] Commented: (IO-160) [patch] FileSystemUtils.freeSpace fails on solaris
[
https://issues.apache.org/jira/browse/IO-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586708#action_12586708
]
Niall Pemberton commented on IO-160:
Stefan pointed out that since the dfPath is being set in the static initializer
then my thread-safe comment in nonsense :(
I've applied the patch, thanks
http://svn.apache.org/viewvc?view=rev&revision=645787
> [patch] FileSystemUtils.freeSpace fails on solaris
> ---
>
> Key: IO-160
> URL: https://issues.apache.org/jira/browse/IO-160
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 1.3.2
>Reporter: Mike Bristow
> Attachments: jakarta-commons-io.patch
>
>
> FileSystemUtils.freeSpace fails its tests on Solaris. The following patch
> fixes it, and with it all tests pass on:
> RedHat (FC7, EL3, EL4, CentOS4, CentOS5) and Solaris (8, 9-sparc, 9-i386,
> 10-sparc, 10-i386).
> The fix is to force the use of /usr/xpg4/bin/df on Solaris, which is the
> posix version. This then means that the output-parsing works as expected.
> Index: src/java/org/apache/commons/io/FileSystemUtils.java
> ===
> RCS file:
> /cvsroot/upstream/jpackage/jakarta-commons-io/src/java/org/apache/commons/io/FileSystemUtils.java,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.2.3
> diff -u -r1.1.1.1 -r1.1.1.1.2.3
> --- src/java/org/apache/commons/io/FileSystemUtils.java 2 Mar 2007 06:31:03
> - 1.1.1.1
> +++ src/java/org/apache/commons/io/FileSystemUtils.java 28 Mar 2008 11:56:06
> - 1.1.1.1.2.3
> @@ -64,6 +64,10 @@
>
> /** The operating system flag. */
> private static final int OS;
> +
> +/** The path to df */
> +private static String dfPath = "df";
> +
> static {
> int os = OTHER;
> try {
> @@ -76,9 +80,6 @@
> if (osName.indexOf("windows") != -1) {
> os = WINDOWS;
> } else if (osName.indexOf("linux") != -1 ||
> -osName.indexOf("sun os") != -1 ||
> -osName.indexOf("sunos") != -1 ||
> -osName.indexOf("solaris") != -1 ||
> osName.indexOf("mpe/ix") != -1 ||
> osName.indexOf("freebsd") != -1 ||
> osName.indexOf("irix") != -1 ||
> @@ -86,6 +87,11 @@
> osName.indexOf("unix") != -1 ||
> osName.indexOf("mac os x") != -1) {
> os = UNIX;
> +} else if (osName.indexOf("sun os") != -1 ||
> +osName.indexOf("sunos") != -1 ||
> +osName.indexOf("solaris") != -1) {
> +os = POSIX_UNIX;
> +dfPath = "/usr/xpg4/bin/df";
> } else if (osName.indexOf("hp-ux") != -1 ||
> osName.indexOf("aix") != -1) {
> os = POSIX_UNIX;
> @@ -116,7 +122,7 @@
> * of [EMAIL PROTECTED] #freeSpaceKb(String)} which returns a result in
> kilobytes.
> *
> * Note that some OS's are NOT currently supported, including OS/390,
> - * OpenVMS and and SunOS 5. (SunOS is supported by
> freeSpaceKb.)
> + * OpenVMS.
> *
> * FileSystemUtils.freeSpace("C:"); // Windows
> * FileSystemUtils.freeSpace("/volume"); // *nix
> @@ -317,14 +323,14 @@
> flags += "P";
> }
> String[] cmdAttribs =
> -(flags.length() > 1 ? new String[] {"df", flags, path} : new
> String[] {"df", path});
> +(flags.length() > 1 ? new String[] {dfPath, flags, path} : new
> String[] {dfPath, path});
>
> // perform the command, asking for up to 3 lines (header,
> interesting, overflow)
> List lines = performCommand(cmdAttribs, 3);
> if (lines.size() < 2) {
> // unknown problem, throw exception
> throw new IOException(
> -"Command line 'df' did not return info as expected " +
> +"Command line '" + dfPath + "' did not return info as
> expected " +
> "for path '" + path + "'- response was " + lines);
> }
> String line2 = (String) lines.get(1); // the line we're interested in
> @@ -338,7 +344,7 @@
> tok = new StringTokenizer(line3, " ");
> } else {
> throw new IOException(
> -"Command line 'df' did not return data as expected "
> +
> +"Command line '" + dfPath + "' did not return data
> as expected " +
> "for path '" + path + "'- check path is valid");
> }
> } else {
> @@ -364,14 +370,14 @@
> long bytes = Long.parseLong(freeSpace);
> if (bytes < 0) {
>
[jira] Commented: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586116#action_12586116 ] Niall Pemberton commented on IO-132: Added: http://svn.apache.org/viewvc/commons/proper/io/trunk/src/java/org/apache/commons/io/monitor/ > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > Attachments: FilesystemListener.java, FilesystemMonitor.java, > FilesystemObserver.java > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-298) MethodUtils.getAccessibleMethod(Method method) could not find right public method
[
https://issues.apache.org/jira/browse/BEANUTILS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-298.
---
Resolution: Fixed
Assignee: Niall Pemberton
Thanks for reporting this. Unfortunately in this scenario there is no fix for
MethodUtils.getAccessibleMethod(Method) - since it can only check
superclasses/interfaces of the class returned by Method.getDeclaringClass(). In
your scenario the declaring class is BaseX and therefore the interface IX is
not available. So I have added a new MethodUtils.getAccessibleMethod(Class,
Method) method which can be used instead. I have changed PropertyUtils to use
this new method so that now your PropertyUtils.getProperty(beanOfTypeBaseX,
"name") works:
http://svn.apache.org/viewvc?view=rev&revision=644143
Closing this as fixed.
> MethodUtils.getAccessibleMethod(Method method) could not find right public
> method
> -
>
> Key: BEANUTILS-298
> URL: https://issues.apache.org/jira/browse/BEANUTILS-298
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.7.0, 1.8.0-BETA
> Environment: Java 1.5, Windows XP
>Reporter: Roman Mukhin
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 1.8.0
>
>
> Let assume follows:
> public interface IX {
> getName();
> }
> class BaseX {
> public getName();
> }
> class ImplX extends BaseX implements IX {
> }
> For some reason I do not want that BaseX implements IX, but if we have a bean
> of type ImplX we can call getName().
> PropertyUtils.getProperty(beanOfTypeBaseX, "name") could not get the value,
> because the method MethodUtils.getAccessibleMethod(Method method) looks up
> only throunght supercalsses and interfaces of implementing class but not the
> subclasses and interfaces that they implement!
> So PropertyUtils.getProperty(beanOfTypeBaseX, "name") throws an Exception
> that the method is not accessible, but at the same time I can call
> beanOfTypeBaseX.getName()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-300) NPE in LazyDynaList
[
https://issues.apache.org/jira/browse/BEANUTILS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584698#action_12584698
]
Niall Pemberton commented on BEANUTILS-300:
---
I think this is probably a false positive, since the setElementType() /
setElementDynaClass() methods set either the wrapDynaClass or elementDynaClass
variables and theres code before the snippet you post which should ensure these
are called:
{code:java}
if (elementType == null) {
setElementDynaClass(new LazyDynaClass());
}
// Get DynaClass (restore WrapDynaClass lost in serialization)
DynaClass dynaClass = (elementDynaClass == null) ? wrapDynaClass :
elementDynaClass;
if (dynaClass == null) {
setElementType(elementType);
}
{code}
> NPE in LazyDynaList
> ---
>
> Key: BEANUTILS-300
> URL: https://issues.apache.org/jira/browse/BEANUTILS-300
> Project: Commons BeanUtils
> Issue Type: Bug
> Environment: Fortify
>Reporter: Henri Yandell
> Fix For: 1.8.0
>
>
> The transform() method does not protect lazyDynaClass from being null when
> the new DynaBean is created.
> Throw an exception? Or should the setElementType(..) call be joined by a
> lazyDynaClass=...something
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-300) NPE in LazyDynaList
[ https://issues.apache.org/jira/browse/BEANUTILS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584380#action_12584380 ] Niall Pemberton commented on BEANUTILS-300: --- OK but I'm not sure which lines you're referring to - any clue? > NPE in LazyDynaList > --- > > Key: BEANUTILS-300 > URL: https://issues.apache.org/jira/browse/BEANUTILS-300 > Project: Commons BeanUtils > Issue Type: Bug > Environment: Fortify >Reporter: Henri Yandell > Fix For: 1.8.0 > > > The transform() method does not protect lazyDynaClass from being null when > the new DynaBean is created. > Throw an exception? Or should the setElementType(..) call be joined by a > lazyDynaClass=...something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-160) [patch] FileSystemUtils.freeSpace fails on solaris
[
https://issues.apache.org/jira/browse/IO-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583076#action_12583076
]
Niall Pemberton commented on IO-160:
Your patch looks like its generated from CVS - but we moved to subversion a
year or two ago. Even when I tried to fix it for SVN I get a message saying its
outdated. Could you re-generate your patch using the latest trunk from
subversion please:
http://commons.apache.org/io/source-repository.html
Also, from a quick scan of your proposed patch - adding a static String
variable (i.e. dfPath) and updating it is a really bad idea since this method
is not thread safe.
> [patch] FileSystemUtils.freeSpace fails on solaris
> ---
>
> Key: IO-160
> URL: https://issues.apache.org/jira/browse/IO-160
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 1.3.2
>Reporter: Mike Bristow
> Attachments: jakarta-commons-io.patch
>
>
> FileSystemUtils.freeSpace fails its tests on Solaris. The following patch
> fixes it, and with it all tests pass on:
> RedHat (FC7, EL3, EL4, CentOS4, CentOS5) and Solaris (8, 9-sparc, 9-i386,
> 10-sparc, 10-i386).
> The fix is to force the use of /usr/xpg4/bin/df on Solaris, which is the
> posix version. This then means that the output-parsing works as expected.
> Index: src/java/org/apache/commons/io/FileSystemUtils.java
> ===
> RCS file:
> /cvsroot/upstream/jpackage/jakarta-commons-io/src/java/org/apache/commons/io/FileSystemUtils.java,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.2.3
> diff -u -r1.1.1.1 -r1.1.1.1.2.3
> --- src/java/org/apache/commons/io/FileSystemUtils.java 2 Mar 2007 06:31:03
> - 1.1.1.1
> +++ src/java/org/apache/commons/io/FileSystemUtils.java 28 Mar 2008 11:56:06
> - 1.1.1.1.2.3
> @@ -64,6 +64,10 @@
>
> /** The operating system flag. */
> private static final int OS;
> +
> +/** The path to df */
> +private static String dfPath = "df";
> +
> static {
> int os = OTHER;
> try {
> @@ -76,9 +80,6 @@
> if (osName.indexOf("windows") != -1) {
> os = WINDOWS;
> } else if (osName.indexOf("linux") != -1 ||
> -osName.indexOf("sun os") != -1 ||
> -osName.indexOf("sunos") != -1 ||
> -osName.indexOf("solaris") != -1 ||
> osName.indexOf("mpe/ix") != -1 ||
> osName.indexOf("freebsd") != -1 ||
> osName.indexOf("irix") != -1 ||
> @@ -86,6 +87,11 @@
> osName.indexOf("unix") != -1 ||
> osName.indexOf("mac os x") != -1) {
> os = UNIX;
> +} else if (osName.indexOf("sun os") != -1 ||
> +osName.indexOf("sunos") != -1 ||
> +osName.indexOf("solaris") != -1) {
> +os = POSIX_UNIX;
> +dfPath = "/usr/xpg4/bin/df";
> } else if (osName.indexOf("hp-ux") != -1 ||
> osName.indexOf("aix") != -1) {
> os = POSIX_UNIX;
> @@ -116,7 +122,7 @@
> * of [EMAIL PROTECTED] #freeSpaceKb(String)} which returns a result in
> kilobytes.
> *
> * Note that some OS's are NOT currently supported, including OS/390,
> - * OpenVMS and and SunOS 5. (SunOS is supported by
> freeSpaceKb.)
> + * OpenVMS.
> *
> * FileSystemUtils.freeSpace("C:"); // Windows
> * FileSystemUtils.freeSpace("/volume"); // *nix
> @@ -317,14 +323,14 @@
> flags += "P";
> }
> String[] cmdAttribs =
> -(flags.length() > 1 ? new String[] {"df", flags, path} : new
> String[] {"df", path});
> +(flags.length() > 1 ? new String[] {dfPath, flags, path} : new
> String[] {dfPath, path});
>
> // perform the command, asking for up to 3 lines (header,
> interesting, overflow)
> List lines = performCommand(cmdAttribs, 3);
> if (lines.size() < 2) {
> // unknown problem, throw exception
> throw new IOException(
> -"Command line 'df' did not return info as expected " +
> +"Command line '" + dfPath + "' did not return info as
> expected " +
> "for path '" + path + "'- response was " + lines);
> }
> String line2 = (String) lines.get(1); // the line we're interested in
> @@ -338,7 +344,7 @@
> tok = new StringTokenizer(line3, " ");
> } else {
> throw new IOException(
> -"Command line 'df' did not return data as expected "
> +
> +"Command line '" + dfPath + "' did not
[jira] Resolved: (BEANUTILS-294) BeanUtilsBean.setProperty() does not support nested map
[ https://issues.apache.org/jira/browse/BEANUTILS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-294. --- Resolution: Fixed Assignee: Niall Pemberton Fixed, thanks: http://svn.apache.org/viewvc?view=rev&revision=640274 > BeanUtilsBean.setProperty() does not support nested map > --- > > Key: BEANUTILS-294 > URL: https://issues.apache.org/jira/browse/BEANUTILS-294 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Stephen Leung >Assignee: Niall Pemberton >Priority: Critical > Fix For: 1.8.0 > > > I tried to call BeanUtilsBean.setProperty() with a DynaActionForm as the > "bean" and "someMap(x)(y)" as the "name". In BeanUtilsBean.setProperty(), > after the while loop at line 900, target became "null" and name became = > "(y)". And consequently IllegalArgumentException is thrown at line 930 when > setProperty() tried to getPropertyDescriptor() of a null bean. Specifically, > the following is the stack trace. Could somebody look into it? > Thanks. > java.lang.IllegalArgumentException: No bean specified > at > org.apache.common.beanutils.PropertyUtilsBean.getPropertyDescriptor(PropertyUtilsBean.java:871) > at > org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:930) > at > org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:829) > at > org.apache.commons.beanutils.BeanUtils.populate(BeanUtilsBean.java:433) > at org.apache.struts.util.RequestUtils.pouplate(RequestUtils.java:467) > .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-300) NPE in LazyDynaList
[ https://issues.apache.org/jira/browse/BEANUTILS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581445#action_12581445 ] Niall Pemberton commented on BEANUTILS-300: --- Any chance of a test case? > NPE in LazyDynaList > --- > > Key: BEANUTILS-300 > URL: https://issues.apache.org/jira/browse/BEANUTILS-300 > Project: Commons BeanUtils > Issue Type: Bug > Environment: Fortify >Reporter: Henri Yandell > Fix For: 1.8.0 > > > The transform() method does not protect lazyDynaClass from being null when > the new DynaBean is created. > Throw an exception? Or should the setElementType(..) call be joined by a > lazyDynaClass=...something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-311) DynaBean variables are evaluated before member variables.
[ https://issues.apache.org/jira/browse/BEANUTILS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-311. --- Resolution: Won't Fix > DynaBean variables are evaluated before member variables. > - > > Key: BEANUTILS-311 > URL: https://issues.apache.org/jira/browse/BEANUTILS-311 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Ivan Popov > > Hi, > I have a class that is a DynaBean (extends LazyDynaBean) and that has some > member variables, in addition to those of the DynaBean. > It seems as if dynaBean variables are evaluated first, and as the property to > evaluate is a member variable and not a dynaBean one, > it returns a NestedNullException. > Regards. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-297) ConvertingWrapDynaBean hides cause exceptions
[
https://issues.apache.org/jira/browse/BEANUTILS-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-297.
---
Resolution: Fixed
Fixed - http://svn.apache.org/viewvc?view=rev&revision=640259
> ConvertingWrapDynaBean hides cause exceptions
> -
>
> Key: BEANUTILS-297
> URL: https://issues.apache.org/jira/browse/BEANUTILS-297
> Project: Commons BeanUtils
> Issue Type: Improvement
> Components: DynaBean
>Affects Versions: 1.8.0-BETA
>Reporter: Alex Tkachev
> Fix For: 1.8.0
>
>
> ConvertingWrapDynaBean.set(String,Object) method hides cause exception.
> This issue relates to BEANUTILS-23 that partially fixed this problem, by
> adding only the message of the cause exception to IllegalArgumentException
> that is being thrown:
> try {
> BeanUtils.copyProperty(instance, name, value);
> } catch (InvocationTargetException ite) {
> Throwable cause = ite.getTargetException();
> throw new IllegalArgumentException
> ("Error setting property '" + name +
> "' nested exception - " + cause);
> } catch (Throwable t) {
> throw new IllegalArgumentException
> ("Error setting property '" + name +
> "', exception - " + t);
> }
> I think that the cause exception (ie Throwable t) should be passed to newly
> generated IllegalArgumentException (as second parameter). I don't really see
> no good in hiding it, it only causes problems in identifying the cause why
> the setter has failed. Good example why this is important is using Jelly. If
> for some reason the setter fails (for instance, some illegal value was passed
> and nested exception was thrown by the setter), you have no way of knowing
> the cause of it. The only way to find out the real cause is through
> debugging, setting some complex conditional breakpoints.
> My proposed code is:
> try {
> BeanUtils.copyProperty(instance, name, value);
> } catch (InvocationTargetException ite) {
> Throwable cause = ite.getTargetException();
> throw new IllegalArgumentException
> ("Error setting property '" + name +
> "' nested exception - " + cause, t);
> } catch (Throwable t) {
> throw new IllegalArgumentException
> ("Error setting property '" + name +
> "', exception - " + t, t);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-291) Circular Reference on WeakHashMap
[ https://issues.apache.org/jira/browse/BEANUTILS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-291: -- Attachment: (was: BEANUTILS-291-FixMemoryLeaks-v1.patch) > Circular Reference on WeakHashMap > - > > Key: BEANUTILS-291 > URL: https://issues.apache.org/jira/browse/BEANUTILS-291 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Niall Pemberton > Fix For: 1.8.0 > > Attachments: BEANUTILS-291-FixMemoryLeaks-v2.patch, > memoryLeakTests-new.zip, PropertyUtilsBean.java > > > Clebert Suconic wrote on the [EMAIL PROTECTED] list > (see http://tinyurl.com/2a9gan) > I have been investigating WeakHashMaps on BeanUtils 1.8 as part of a > investigation on this: > http://jira.jboss.com/jira/browse/JBAS-2299 > (Which is not actually an issue with JBAS, but an issue when using BeanUtils > as part of the classPath). > There is a circular reference on the WeakHashMap, The WeakHashMap will have > the ClassLoader as the key, and it will have a reference back to the Key from > one of the Reflection objects. This doesn't work! (Please.. no discussions > about this point.. if you don't believe me, do some testing with simple stuff > before discussing this and come back to me only after that) > [EMAIL PROTECTED] > !--- [EMAIL PROTECTED] > !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- [Ljava.lang.Object;@10800875 > !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- !--- !--- !--- !--- class java.lang.Class > !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [Ljava.util.HashMap$Entry;@28236766 > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !-- -!--- !--- !--- !--- !--- !--- > !---FieldReference private java.lang.Object [EMAIL PROTECTED] Detail > I don't know if I'm preaching to the choir, but just in case this is new > information to someone... you should aways keep Reflection referenced as > SoftReferences (if you really have to). Reflection is aways a new object so a > WeakReference is too weak. > On JBossSerialization I have solved this using an interesting way. I called > it PersistentReference. I'm using SoftReferences, and keeping the information > to recreate it case the SoftReference is cleared: > http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3 > And also... you guys should write a testcase to validate if the Caching is > being cleared. (I don't know if you have one). > http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java > You don't need to use the jboss-profiler API for this.. just create a > WeakReference to a new ClassLoader, and validate if it was released at the > end after some exercizing some code on this caching. You will > probably need to fill your memory almost to 100% on the test as SoftReference > are only gone when the memory is low. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-291) Circular Reference on WeakHashMap
[ https://issues.apache.org/jira/browse/BEANUTILS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-291: -- Attachment: BEANUTILS-291-FixMemoryLeaks-v2.patch I have resolved one of the memory leak issues - Converters holding a reference to Class. http://svn.apache.org/viewvc?view=rev&revision=640131 This is an incompatible change to BeanUtils 1.8.0-BETA (but not to the previous 1.7.0 release). The incompatible changes are: - AbstractConverter - constructor signatures are different and getDefaultType() method is now abstract - DateTimeConverter - now an abstract class and constructor signatures are different - NumberConverter - now an abstract class and constructor signatures are different Attaching a revised patch for the other proposed changes > Circular Reference on WeakHashMap > - > > Key: BEANUTILS-291 > URL: https://issues.apache.org/jira/browse/BEANUTILS-291 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Niall Pemberton > Fix For: 1.8.0 > > Attachments: BEANUTILS-291-FixMemoryLeaks-v2.patch, > memoryLeakTests-new.zip, PropertyUtilsBean.java > > > Clebert Suconic wrote on the [EMAIL PROTECTED] list > (see http://tinyurl.com/2a9gan) > I have been investigating WeakHashMaps on BeanUtils 1.8 as part of a > investigation on this: > http://jira.jboss.com/jira/browse/JBAS-2299 > (Which is not actually an issue with JBAS, but an issue when using BeanUtils > as part of the classPath). > There is a circular reference on the WeakHashMap, The WeakHashMap will have > the ClassLoader as the key, and it will have a reference back to the Key from > one of the Reflection objects. This doesn't work! (Please.. no discussions > about this point.. if you don't believe me, do some testing with simple stuff > before discussing this and come back to me only after that) > [EMAIL PROTECTED] > !--- [EMAIL PROTECTED] > !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- [Ljava.lang.Object;@10800875 > !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > !--- !--- !--- !--- !--- !--- !--- class java.lang.Class > !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [Ljava.util.HashMap$Entry;@28236766 > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- [EMAIL > PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > [EMAIL PROTECTED] > !--- !--- !--- !--- !--- !--- !--- !--- !-- -!--- !--- !--- !--- !--- !--- > !---FieldReference private java.lang.Object [EMAIL PROTECTED] Detail > I don't know if I'm preaching to the choir, but just in case this is new > information to someone... you should aways keep Reflection referenced as > SoftReferences (if you really have to). Reflection is aways a new object so a > WeakReference is too weak. > On JBossSerialization I have solved this using an interesting way. I called > it PersistentReference. I'm using SoftReferences, and keeping the information > to recreate it case the SoftReference is cleared: > http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3 > And also... you guys should write a testcase to validate if the Caching is > being cleared. (I don't know if you have one). > http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java > You don't need to use the jboss-profiler API for this.. just create a > WeakReference to a new ClassLoader, and validate if it was released at the > end after some exercizing some code on this caching. You will > probably need to fill your memory almost to 100% on the test as SoftReference > are only gone when the memory is low. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (POOL-127) deneme2
[ https://issues.apache.org/jira/browse/POOL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton deleted POOL-127: - > deneme2 > --- > > Key: POOL-127 > URL: https://issues.apache.org/jira/browse/POOL-127 > Project: Commons Pool > Issue Type: Sub-task >Reporter: Bengül Demiralay > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (POOL-128) deneme3
[ https://issues.apache.org/jira/browse/POOL-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton deleted POOL-128: - > deneme3 > --- > > Key: POOL-128 > URL: https://issues.apache.org/jira/browse/POOL-128 > Project: Commons Pool > Issue Type: Sub-task >Reporter: Bengül Demiralay > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (POOL-126) deneme1
[ https://issues.apache.org/jira/browse/POOL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton deleted POOL-126: - > deneme1 > --- > > Key: POOL-126 > URL: https://issues.apache.org/jira/browse/POOL-126 > Project: Commons Pool > Issue Type: Sub-task >Reporter: Bengül Demiralay > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (PRIMITIVES-11) tst3
[ https://issues.apache.org/jira/browse/PRIMITIVES-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton deleted PRIMITIVES-11: -- > tst3 > > > Key: PRIMITIVES-11 > URL: https://issues.apache.org/jira/browse/PRIMITIVES-11 > Project: Commons Primitives > Issue Type: Sub-task >Reporter: Bengül Demiralay > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (PRIMITIVES-9) tst1
[ https://issues.apache.org/jira/browse/PRIMITIVES-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton deleted PRIMITIVES-9: - > tst1 > > > Key: PRIMITIVES-9 > URL: https://issues.apache.org/jira/browse/PRIMITIVES-9 > Project: Commons Primitives > Issue Type: Sub-task >Reporter: Bengül Demiralay > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (PRIMITIVES-10) tst2
[ https://issues.apache.org/jira/browse/PRIMITIVES-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton deleted PRIMITIVES-10: -- > tst2 > > > Key: PRIMITIVES-10 > URL: https://issues.apache.org/jira/browse/PRIMITIVES-10 > Project: Commons Primitives > Issue Type: Sub-task >Reporter: Bengül Demiralay > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (PRIMITIVES-8) test1
[ https://issues.apache.org/jira/browse/PRIMITIVES-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton deleted PRIMITIVES-8: - > test1 > - > > Key: PRIMITIVES-8 > URL: https://issues.apache.org/jira/browse/PRIMITIVES-8 > Project: Commons Primitives > Issue Type: Test >Reporter: Bengül Demiralay > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-311) DynaBean variables are evaluated before member variables.
[ https://issues.apache.org/jira/browse/BEANUTILS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580419#action_12580419 ] Niall Pemberton commented on BEANUTILS-311: --- Ivan, Its not really a "bean with a Map" but an alternative to a POJO bean - see: http://commons.apache.org/beanutils/apidocs/org/apache/commons/beanutils/package-summary.html#dynamic One reason I don't think its a good idea is because of the very question "which should be evaulated first"? Another is because it could be inconsistent, depending on whether a property exists in a DynaBean or not. BeanUtils only ever treats DynaBean as DynaBeans (the same with Maps btw) - this is straightforward and consistent and I'm against making it any other way. Starting coding getters/setters for DynaBean would seem bizarre to me - since one of their main points is not having to do that. If you want to though, then I suggest overriding the DynaBean's get/set methods and invoking your hand coded methods. > DynaBean variables are evaluated before member variables. > - > > Key: BEANUTILS-311 > URL: https://issues.apache.org/jira/browse/BEANUTILS-311 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Ivan Popov > > Hi, > I have a class that is a DynaBean (extends LazyDynaBean) and that has some > member variables, in addition to those of the DynaBean. > It seems as if dynaBean variables are evaluated first, and as the property to > evaluate is a member variable and not a dynaBean one, > it returns a NestedNullException. > Regards. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-311) DynaBean variables are evaluated before member variables.
[ https://issues.apache.org/jira/browse/BEANUTILS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580332#action_12580332 ] Niall Pemberton commented on BEANUTILS-311: --- I don't think its a good idea to mix DynaBean with regular properties - so I think we should close this as WONTFIX. > DynaBean variables are evaluated before member variables. > - > > Key: BEANUTILS-311 > URL: https://issues.apache.org/jira/browse/BEANUTILS-311 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Ivan Popov > > Hi, > I have a class that is a DynaBean (extends LazyDynaBean) and that has some > member variables, in addition to those of the DynaBean. > It seems as if dynaBean variables are evaluated first, and as the property to > evaluate is a member variable and not a dynaBean one, > it returns a NestedNullException. > Regards. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-281) Change maven build to create Collections Test Framework jar
[ https://issues.apache.org/jira/browse/COLLECTIONS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580301#action_12580301 ] Niall Pemberton commented on COLLECTIONS-281: - I applied all of the patch - so AFAIC its done: http://svn.apache.org/viewvc?view=rev&revision=638061 Running the three builds (ant, m1 & m2) the source/target options used are inconsistent: - Ant: doesn't use any source/target options when compiling, but has 1.2 in the jar's manifest for X-Compile-Source-JDK/X-Compile-Target-JDK (hard coded in src/conf/MANIFEST.MF) - m1: uses 1.3/1.1 values for source/target options - m2: uses 1.3/1.3 values for source/target options IMO we should just use 1.3 for both source/target as1.2 is so old I see no reason to attempt to support it (anyone wanting 1.2 compataible versions will have to stay on an older release) > Change maven build to create Collections Test Framework jar > --- > > Key: COLLECTIONS-281 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-281 > Project: Commons Collections > Issue Type: Task >Affects Versions: 3.2 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 3.3 > > Attachments: COLLECTIONS-281-build-testframework.patch > > > Currently the m2 build does not create the Collections Test Framework jar > (ant and m1 builds do) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-416) Import MethodUtils and ConstructorUtils from BeanUtils
[ https://issues.apache.org/jira/browse/LANG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579975#action_12579975 ] Niall Pemberton commented on LANG-416: -- I am hoping to release BeanUtils 1.8.0 - but after that I'm not sure. BeanUtils is less relevant with the advent of the "independant EL", grew (IMO) too big in scope (conversion at least should be a separate component) and is hampered by the existing API. Since there doesn't seem to be anyone else interested, then I guess its in maintenance mode and therefore duplicating its functionality, rather than developing within BeanUtils is probably a reasonable route. I believe Stephen was referring to "reflect" and not "clazz": http://svn.apache.org/viewvc/commons/dormant/reflect/ ...although perhaps theres stuff relevant in both. I could see this area growing quite big, so perhaps reflect should be resurrected, rather than putting it in lang - but I guess that decision could wait until theres something concrete that could be considered for release and an idea about future growth of that area. > Import MethodUtils and ConstructorUtils from BeanUtils > -- > > Key: LANG-416 > URL: https://issues.apache.org/jira/browse/LANG-416 > Project: Commons Lang > Issue Type: New Feature >Affects Versions: 2.4 >Reporter: Matt Benson > Fix For: 3.0 > > > Mentioned on the mailing list... After we release 2.4 I'd like to: > - import ConstructorUtils > - make CU.getMatchingAccessibleConstructor() public > - import MethodUtils > - factor best-match calculation code out of MethodUtils into abstract > superclass MemberUtils, make ConstructorUtils extend MemberUtils and use the > same code (be on the lookout for ways to improve best-match calcs; my > original description was based on javadoc that said the first matching method > encountered was used, but this comment seems to have been outdated). > - merge any other duplicate (or near-duplicate) code from CU/MethodU into > MemberU and remove anything else that doesn't make sense in the context of > Lang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-310) Provide facility to configure and clear MethodUtils cache
[ https://issues.apache.org/jira/browse/BEANUTILS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-310. --- Resolution: Fixed Fixed: http://svn.apache.org/viewvc?view=rev&revision=636797 > Provide facility to configure and clear MethodUtils cache > - > > Key: BEANUTILS-310 > URL: https://issues.apache.org/jira/browse/BEANUTILS-310 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.8.0 > > > Provide the faciltity to configure whether MethodUtils caches methods > (currently always does) and to clear the method cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-291) Circular Reference on WeakHashMap
[ https://issues.apache.org/jira/browse/BEANUTILS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-291: -- Attachment: BEANUTILS-291-FixMemoryLeaks-v1.patch Clebert, My apologies that its taken so long to get round to looking at your patches. The memory leak test case, links to your wiki on Weak/SoftReferences and JBoss Profiler were all very useful - thanks. I have just commited a MemoryLeakTestCase - based on the one you supplied: http://svn.apache.org/viewvc?view=rev&revision=636989 ...but with additional tests because, unfortunately, there are more scenarios within BeanUtils for memory leaks. I believe the following is the complete list (including those you're know): - PropertyUtilsBean, descriptorsCache, FastHashMap - PropertyUtilsBean, mappedDescriptorsCache, FastHashMap> - MethodUtils, cache, WeakHashMap - WrapDynaClass, dynaClasses, Map - ConvertUtilsBean, converters, HashMap - LocaleConvertUtilsBean, mapConverters, FastHashMap> 1) PropertyUtilsBean - descriptorsCache: FastHashMap - mappedDescriptorsCache: FastHashMap> I looked at the changes you propose for PropertyUtilsBean and I don't believe its necessary in this case to use your ProxyHashMap - which is effectively a "cache of caches" keyed by ClassLoader. We already have the equivalent of this called ContextClassLoaderLocal[1] which stores an instance of BeanUtilsBean for each ClassLoader - and each BeanUtilsBean has a PropertyUtilsBean instance. So looks to me like we simply need to change the descriptorsCache and mappedDescriptorsCache to be WeakHashMap instead of FastHashMap. I'm not even sure why those are FastHashMap because they have "fast" set to true and in "fast" mode FastHashMap operates as a HashMap, with no synchronization. I tried this out using your test case - it seems to resolve the memory leak for descriptorsCache, but not mappedDescriptorsCache. From what I can tell there are two additional problems with mappedDescriptorsCache: - It uses MethodUtils which also has a cache that can leak - ignore that for now I'll come to that below. - MappedPropertyDescriptor(MPD) is a custom BeanUtils implementation of PropertyDescriptor that has one Class and two Method instance variables. Changing these to SoftReference seems to resolve the issue. [1] http://svn.apache.org/repos/asf/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ContextClassLoaderLocal.java 2) MethodUtils -- cache: WeakHashMap The cache in MethodUtils is a static WeakHashMap instance and the Method value stores seems to prevent gc. Putting the Method in a WeakReference seems to resolve this. Perhaps it should be a SoftReference, but the only danger seems to be that it will get re-created more often. 3) WrapDynaClass dynaClasses: Map I had already done some work to move the static dynaClasses cache into a "by ClassLoader" cache (using ContextClassLoaderLocal). Unfortunately its a hack since it was "protected" visibility and I'm avoiding breaking binary compatibility with the previous release. Anyway, your test showed that the problem still wasn't resolved and the issue seems to be the Class instance variable WrapDynaClass has. Moving this into a SoftReference seems to resolve it. 4) ConvertUtilsBean --- converters: HashMap There are two issues here - the cache and the fact that AbstractConverter (which many of the Converters stored in the cache derive from) has a reference to Class. Changing the HashMap to a WeakHashMap and putting the AbstractConverter's Class reference into a SoftReference seems to resolve this. However I think it would be best to remove the Class reference from AbstractConverter all together, since if that reference is garbage collected then the Converters will fail, unless some magic is done to re-create it. 5) LocaleConvertUtilsBean - mapConverters: FastHashMap> I believe this should have been straight forward to fix, simply replacing FastHashMap with WeakHashMap. However the FastHashMap is exposed in the API so changing to WeakHashMap breaks compatibility. So I've tried creating a WeakFastHashMap, which is a nasty hack but seems to work. I'm attaching a patch to this ticket with some proposed changes - although it uses SoftReference in AbstractConverter which I probably won't do as I said above. These changes all seem to make the memory leak tests pass using JDK 1.5.0_07. However I tried running the tests using JDK 1.4.2_12 and JDK 1.3.1_18 and three out of the six memory leak tests fail (both PropertyUtilsBean tests and the WrapDynaClass test) - so not sure why that is. I'm hoping that you still have time and interest in this, despite how long its taken for me to get round to doing anything. Any feedback on my modified version of your tests and propo
[jira] Created: (BEANUTILS-310) Provide facility to configure and clear MethodUtils cache
Provide facility to configure and clear MethodUtils cache - Key: BEANUTILS-310 URL: https://issues.apache.org/jira/browse/BEANUTILS-310 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Affects Versions: 1.8.0-BETA Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 Provide the faciltity to configure whether MethodUtils caches methods (currently always does) and to clear the method cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: FilesystemMonitor.java FilesystemObserver.java FilesystemListener.java Stephen's comment was that it seemed too much like a framework. I've re-written the implementations with a single concrete implementation of FilesystemObserver. With that refactoring and being able to use JDK 1.5 features I believe it is much more straight forward - attaching the following: - FilesystemListener - interface which receives create/change/delete events for files/directories - FilesystemObserver - checks the current state of a directory against what it has cached from the previous invocation and notifies listeners - FilesystemMonitor - Runnable that invokes registered observers at a specified interval I also have a do nothing FilesystemListenerAdaptor implementation and FilesystemObserver test case. I'll leave this for review/comment for a while before I commit. > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > Attachments: FilesystemListener.java, FilesystemMonitor.java, > FilesystemObserver.java > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileObserverImplTestCase.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileObserver.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: JDKLoggingFileListener.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileObserverImpl.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileMonitor.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: CollectionFileListener.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: AbstractFileObserverTestCase.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: CollectionFileListenerTestCase.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileListener.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileListenerAdaptor.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: AbstractFileObserver.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > Attachments: AbstractFileObserverTestCase.java, > CollectionFileListener.java, CollectionFileListenerTestCase.java, > FileListener.java, FileListenerAdaptor.java, FileMonitor.java, > FileObserver.java, FileObserverImpl.java, FileObserverImplTestCase.java, > JDKLoggingFileListener.java > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-158) ReaderInputStream implementation
[ https://issues.apache.org/jira/browse/IO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576840#action_12576840 ] Niall Pemberton commented on IO-158: I found three of them, but not the James one: Ant: http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/util/ReaderInputStream.java iBatis http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/src/com/ibatis/common/io/ReaderInputStream.java XMLBeans: http://svn.apache.org/repos/asf/xmlbeans/trunk/src/common/org/apache/xmlbeans/impl/common/ReaderInputStream.java >From an initial scan I would pick the ant one - XMLBeans needs other classes >and iBatis has some copyright stuff that would be simpler to not have to work >out what needs to go in our NOTICE file - also I found a test case for the ant >impl: http://svn.apache.org/repos/asf/ant/core/trunk/src/tests/junit/org/apache/tools/ant/util/ReaderInputStreamTest.java > ReaderInputStream implementation > > > Key: IO-158 > URL: https://issues.apache.org/jira/browse/IO-158 > Project: Commons IO > Issue Type: Wish >Reporter: Andreas Veithen >Priority: Minor > > The standard Java class InputStreamReader converts a Reader into an > InputStream. In some cases it is necessary to do the reverse, i.e. to convert > a Reader into an InputStream. Several frameworks and libraries have their own > implementation of this functionality (google for "ReaderInputStream"). Among > these are at least four Apache projects: Ant, iBatis, James and XMLBeans. > Commons IO would be a good place to share a common implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-416) Import MethodUtils and ConstructorUtils from BeanUtils
[ https://issues.apache.org/jira/browse/LANG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576532#action_12576532 ] Niall Pemberton commented on LANG-416: -- Don't remember that thread and I can't seem to find it. Perhaps you could post a link to it. Initial reaction is why? Don't really see the point of duplicating code accross different components. > Import MethodUtils and ConstructorUtils from BeanUtils > -- > > Key: LANG-416 > URL: https://issues.apache.org/jira/browse/LANG-416 > Project: Commons Lang > Issue Type: New Feature >Affects Versions: 2.4 >Reporter: Matt Benson > Fix For: 3.0 > > > Mentioned on the mailing list... After we release 2.4 I'd like to: > - import ConstructorUtils > - make CU.getMatchingAccessibleConstructor() public > - import MethodUtils > - factor best-match calculation code out of MethodUtils into abstract > superclass MemberUtils, make ConstructorUtils extend MemberUtils and use the > same code (be on the lookout for ways to improve best-match calcs; my > original description was based on javadoc that said the first matching method > encountered was used, but this comment seems to have been outdated). > - merge any other duplicate (or near-duplicate) code from CU/MethodU into > MemberU and remove anything else that doesn't make sense in the context of > Lang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-187) TFTP Server for commons net
[ https://issues.apache.org/jira/browse/NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576302#action_12576302 ] Niall Pemberton commented on NET-187: - Logically you're right and seeing a rash of server implementations here would not be a good idea. But I don't think thats whats going on here or likely to happen - one trivial impl. thats useful for people to test and IMO *violate* is too strong a word to characterize whats being proposed. Sitting from my armchair IMO Dan has made a good case for adding this one impl. here and just because we accept that doesn't mean we can't say "hey stop, lets not do this" when someone proposes a second. Precedent has some weight to a certain point, but this is not the legal system and the PMC can make whatever decisions it likes - including preventing further implementations despite accepting this one. > TFTP Server for commons net > > > Key: NET-187 > URL: https://issues.apache.org/jira/browse/NET-187 > Project: Commons Net > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Dan Armbrust >Priority: Minor > Fix For: 2.0 > > Attachments: TFTPServer and Tests.patch > > > Bug for attaching TFTP Server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-187) TFTP Server for commons net
[ https://issues.apache.org/jira/browse/NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576253#action_12576253 ] Niall Pemberton commented on NET-187: - I agree with James - personal comments just detract. But my view of the ASF is its a do-ocracy rather than about rigid rules. Since Rory has been doing all the work on Net and saw fit to include it and it is a *trivial* implementation then I don't see any problem. Your point about maintaining it is true of any code we choose to release and again since Rory accepted it, I see no reason to assume he doesn't intend to fix bugs. How comprehensive the impelmentation is or becomes is down to the Net devs - users may ask for or want more - but its within the Net devs control on what they choose to provide and to set the scope and limitations of the implementation provided. Anyway, thats my 2 cents from someone else who hasn't fixed a line of Net code. > TFTP Server for commons net > > > Key: NET-187 > URL: https://issues.apache.org/jira/browse/NET-187 > Project: Commons Net > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Dan Armbrust >Priority: Minor > Fix For: 2.0 > > Attachments: TFTPServer and Tests.patch > > > Bug for attaching TFTP Server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575979#action_12575979 ] Niall Pemberton commented on IO-140: Hmm, for generic types I was guided by eclipse's warnings, but I only had WARN set for "Unchecked generic type operation" and not "Usage of raw type" as well - these are now fixed: http://svn.apache.org/viewvc?view=rev&revision=634474 thanks Niall > IO 2.0 - Move to JDK 1.5 > > > Key: IO-140 > URL: https://issues.apache.org/jira/browse/IO-140 > Project: Commons IO > Issue Type: Wish >Reporter: Niall Pemberton > Fix For: 2.0 > > Attachments: IO-2.0-deprecate-and-jdk5.patch > > > I just created IO-139 for a StringBuilder Writer implementation that requies > JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all > deprecations and 2) Making appropriate JDK 1.5 changes (generics, using > StringBuilder and new Appendable for Writers). Below is a summary, thought it > could be a starting point for discussion about IO 2.0 > 1) DEPRECATIONS > - CopyUtils > - FileCleaner > - WildcardFilter > - FileSystemUtils freeSpace(String) > - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) > 2) JDK 1.5 > - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter > implementations > - getFileFilters() and setFileFilters() use generic List > - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, > WildcardFileFilter use generic List > - replace StringBuffer with StringBuilder where appropriate > (FilenameUtils, FileSystemUtils, HexDump,IOUtils > - FileUtils > - convertFileCollectionToFileArray() --> Collection > - listFiles() --> Collection > - listFiles() --> Collection > - writeStringToFile String-->CharSequence (JDK 1.4+) > - ProxyReader - add read(CharBuffer) > - IOUtils > - readLines(Reader) return List > - toInputStream(String) --> toInputStream(CharSequence) (JDK 1.4+) > - write(String data, OutputStream) and write(StringBuffer data, > OutputStream) --> write(CharSequence data, OutputStream) > - write(String, Writer) and write(StringBuffer, Writer) --> > write(CharSequence data, Writer) > - LineIterator Iterator --> Iterator - NullWriter - add "Appendable" methods > - ProxyWriter - add "Appendable" methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575858#action_12575858 ] Niall Pemberton commented on IO-140: There was talk, but no concrete proposal/patches put forward > IO 2.0 - Move to JDK 1.5 > > > Key: IO-140 > URL: https://issues.apache.org/jira/browse/IO-140 > Project: Commons IO > Issue Type: Wish >Reporter: Niall Pemberton > Fix For: 2.0 > > Attachments: IO-2.0-deprecate-and-jdk5.patch > > > I just created IO-139 for a StringBuilder Writer implementation that requies > JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all > deprecations and 2) Making appropriate JDK 1.5 changes (generics, using > StringBuilder and new Appendable for Writers). Below is a summary, thought it > could be a starting point for discussion about IO 2.0 > 1) DEPRECATIONS > - CopyUtils > - FileCleaner > - WildcardFilter > - FileSystemUtils freeSpace(String) > - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) > 2) JDK 1.5 > - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter > implementations > - getFileFilters() and setFileFilters() use generic List > - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, > WildcardFileFilter use generic List > - replace StringBuffer with StringBuilder where appropriate > (FilenameUtils, FileSystemUtils, HexDump,IOUtils > - FileUtils > - convertFileCollectionToFileArray() --> Collection > - listFiles() --> Collection > - listFiles() --> Collection > - writeStringToFile String-->CharSequence (JDK 1.4+) > - ProxyReader - add read(CharBuffer) > - IOUtils > - readLines(Reader) return List > - toInputStream(String) --> toInputStream(CharSequence) (JDK 1.4+) > - write(String data, OutputStream) and write(StringBuffer data, > OutputStream) --> write(CharSequence data, OutputStream) > - write(String, Writer) and write(StringBuffer, Writer) --> > write(CharSequence data, Writer) > - LineIterator Iterator --> Iterator - NullWriter - add "Appendable" methods > - ProxyWriter - add "Appendable" methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-251) url with brackets is not validated thru URLvalidator class.
[
https://issues.apache.org/jira/browse/VALIDATOR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved VALIDATOR-251.
---
Resolution: Duplicate
> url with brackets is not validated thru URLvalidator class.
> ---
>
> Key: VALIDATOR-251
> URL: https://issues.apache.org/jira/browse/VALIDATOR-251
> Project: Commons Validator
> Issue Type: Wish
> Components: Routines
>Affects Versions: 1.3.1 Release
> Environment: Java 1.4
>Reporter: Meenal Gupta
> Fix For: 1.4
>
>
> Please let me know when VALIDATOR-218, Committed revision 590915 is gng on
> release.
> As the Below issue is already solved in the bug is VALIDATOR-218.
> I cannot find this bus fix in Relaese not for the latest version of commons
> jar.
> This is very critical for the my application currrent release.
> URLvalidator isValid() returns false for validation of urls's which have
> brackets "(" , ")" as one of the content.
> url with brackets in them are valid urls , as brackets () are part of the
> unreserved characters.
> We are using the URLValidator isValid() method to validate Urls.
> if (urlValidator.isValid(url)) {
> return true;
> }
> But one of the url is with brackets are rejected by this method.
> i am using 1.3.1 version.
> Is there something in latest version which already have have fix to this bug.
> or my understanding is not correct
> Please clarify.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-251) url with brackets is not validated thru URLvalidator class.
[
https://issues.apache.org/jira/browse/VALIDATOR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575760#action_12575760
]
Niall Pemberton commented on VALIDATOR-251:
---
Validator 1.4 will run on JDK 1.4
> url with brackets is not validated thru URLvalidator class.
> ---
>
> Key: VALIDATOR-251
> URL: https://issues.apache.org/jira/browse/VALIDATOR-251
> Project: Commons Validator
> Issue Type: Wish
> Components: Routines
>Affects Versions: 1.3.1 Release
> Environment: Java 1.4
>Reporter: Meenal Gupta
> Fix For: 1.4
>
>
> Please let me know when VALIDATOR-218, Committed revision 590915 is gng on
> release.
> As the Below issue is already solved in the bug is VALIDATOR-218.
> I cannot find this bus fix in Relaese not for the latest version of commons
> jar.
> This is very critical for the my application currrent release.
> URLvalidator isValid() returns false for validation of urls's which have
> brackets "(" , ")" as one of the content.
> url with brackets in them are valid urls , as brackets () are part of the
> unreserved characters.
> We are using the URLValidator isValid() method to validate Urls.
> if (urlValidator.isValid(url)) {
> return true;
> }
> But one of the url is with brackets are rejected by this method.
> i am using 1.3.1 version.
> Is there something in latest version which already have have fix to this bug.
> or my understanding is not correct
> Please clarify.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-308) Cannot instantiate BeanUtilsBean class
[ https://issues.apache.org/jira/browse/BEANUTILS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-308. --- Resolution: Invalid OK np, thanks for feeding back > Cannot instantiate BeanUtilsBean class > -- > > Key: BEANUTILS-308 > URL: https://issues.apache.org/jira/browse/BEANUTILS-308 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA > Environment: OP: Windows 2000 Professional > Software Plataform: SDK Java 1.5.0_06_b05 + IDE Eclipse 3.3.1.1 >Reporter: Marcelo Ingarano > Fix For: LATER THAN 1.8.0 > > > I cannot instantiate BeanUtilsBean class with the singleton method > "getInstance()" neither with "new" clause em Java. > Stack Description: > Caused by: java.lang.NoSuchMethodError: > org.apache.commons.beanutils.converters.StringConverter.(Ljava/lang/Object;)V > at > org.apache.commons.beanutils.ConvertUtilsBean.registerStandard(ConvertUtilsBean.java:680) > at > org.apache.commons.beanutils.ConvertUtilsBean.deregister(ConvertUtilsBean.java:578) > at > org.apache.commons.beanutils.ConvertUtilsBean.(ConvertUtilsBean.java:164) > at > org.apache.commons.beanutils.BeanUtilsBean.(BeanUtilsBean.java:117) > at > org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68) > at > org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153) > at > org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (BEANUTILS-308) Cannot instantiate BeanUtilsBean class
[ https://issues.apache.org/jira/browse/BEANUTILS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened BEANUTILS-308: --- > Cannot instantiate BeanUtilsBean class > -- > > Key: BEANUTILS-308 > URL: https://issues.apache.org/jira/browse/BEANUTILS-308 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA > Environment: OP: Windows 2000 Professional > Software Plataform: SDK Java 1.5.0_06_b05 + IDE Eclipse 3.3.1.1 >Reporter: Marcelo Ingarano > Fix For: LATER THAN 1.8.0 > > > I cannot instantiate BeanUtilsBean class with the singleton method > "getInstance()" neither with "new" clause em Java. > Stack Description: > Caused by: java.lang.NoSuchMethodError: > org.apache.commons.beanutils.converters.StringConverter.(Ljava/lang/Object;)V > at > org.apache.commons.beanutils.ConvertUtilsBean.registerStandard(ConvertUtilsBean.java:680) > at > org.apache.commons.beanutils.ConvertUtilsBean.deregister(ConvertUtilsBean.java:578) > at > org.apache.commons.beanutils.ConvertUtilsBean.(ConvertUtilsBean.java:164) > at > org.apache.commons.beanutils.BeanUtilsBean.(BeanUtilsBean.java:117) > at > org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68) > at > org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153) > at > org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-309) Passing a null argument to ConstructorUtils.invokeConstructor causes NullPointerException
[
https://issues.apache.org/jira/browse/BEANUTILS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575319#action_12575319
]
Niall Pemberton commented on BEANUTILS-309:
---
btw there is also the following invokeConstructor() method:
public static Object invokeConstructor(Class, Object[], Class[])
..where you can specify the parameter types and avoid this issue. So in the
example I gave above you would do the following to invoked the String
constructor with a null argument:
ConstructorUtils.invokeConstructor(Foo.class, new Object[] {null}, new Class[]
{String.class});
> Passing a null argument to ConstructorUtils.invokeConstructor causes
> NullPointerException
> -
>
> Key: BEANUTILS-309
> URL: https://issues.apache.org/jira/browse/BEANUTILS-309
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.7.0, 1.8.0-BETA
>Reporter: Xavier Poinsard
>
> I am invoking ConstructorUtils.invokeConstructor with an array of arguments
> and one of these arguments is null.
> This causes a NullPointerException line 120 in Class ConstructorUtils.
> Since its not forbidden to pass null argument to a constructor,
> ConstructorUtils should handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-309) Passing a null argument to ConstructorUtils.invokeConstructor causes NullPointerException
[
https://issues.apache.org/jira/browse/BEANUTILS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575318#action_12575318
]
Niall Pemberton commented on BEANUTILS-309:
---
The problem is it uses the type (class) of the parameters to find the
appropriate constructor to invoke - so for example if you had something like
the following
public class Foo {
public Foo(String param) {
}
public Foo(Integer param) {
}
}
And called
ConstructorUtils.invokeConstructor(Foo.class, new Object[] {null});
Which constructor should it use? I guess it could just pick one arbitarily, but
it might still cause problems.
It will probably be a while before I get round to looking at this, but if you
provide a patch with test cases then it will move up on my list
> Passing a null argument to ConstructorUtils.invokeConstructor causes
> NullPointerException
> -
>
> Key: BEANUTILS-309
> URL: https://issues.apache.org/jira/browse/BEANUTILS-309
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.7.0, 1.8.0-BETA
>Reporter: Xavier Poinsard
>
> I am invoking ConstructorUtils.invokeConstructor with an array of arguments
> and one of these arguments is null.
> This causes a NullPointerException line 120 in Class ConstructorUtils.
> Since its not forbidden to pass null argument to a constructor,
> ConstructorUtils should handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575195#action_12575195 ] Niall Pemberton commented on LANG-362: -- I think so > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > ExtendedMessageFormatTest.java, FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-308) Cannot instantiate BeanUtilsBean class
[ https://issues.apache.org/jira/browse/BEANUTILS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575176#action_12575176 ] Niall Pemberton commented on BEANUTILS-308: --- Looks like this is a problem in your environment with having an older copy of BeanUtils in your classpath. Before BeanUtils 1.8.0-BETA StringConverter implementation had the default no-args constructor (by omission), but the 1.8.0-BETA introduced an additional StringConverter(Object) constructor which this stack trace indicates it can't find. > Cannot instantiate BeanUtilsBean class > -- > > Key: BEANUTILS-308 > URL: https://issues.apache.org/jira/browse/BEANUTILS-308 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA > Environment: OP: Windows 2000 Professional > Software Plataform: SDK Java 1.5.0_06_b05 + IDE Eclipse 3.3.1.1 >Reporter: Marcelo Ingarano > > I cannot instantiate BeanUtilsBean class with the singleton method > "getInstance()" neither with "new" clause em Java. > Stack Description: > Caused by: java.lang.NoSuchMethodError: > org.apache.commons.beanutils.converters.StringConverter.(Ljava/lang/Object;)V > at > org.apache.commons.beanutils.ConvertUtilsBean.registerStandard(ConvertUtilsBean.java:680) > at > org.apache.commons.beanutils.ConvertUtilsBean.deregister(ConvertUtilsBean.java:578) > at > org.apache.commons.beanutils.ConvertUtilsBean.(ConvertUtilsBean.java:164) > at > org.apache.commons.beanutils.BeanUtilsBean.(BeanUtilsBean.java:117) > at > org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68) > at > org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153) > at > org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575173#action_12575173 ] niallp edited comment on LANG-362 at 3/4/08 2:42 PM: -- OK commenting out works for me - I'll do that unless you beat me to it. The failing stack trace for the test is below (snipped after ExtendedMessageFormatTest) - java version 1.5.0_07 java.lang.IllegalArgumentException: unknown format type at at java.text.MessageFormat.makeFormat(MessageFormat.java:1426) at java.text.MessageFormat.applyPattern(MessageFormat.java:447) at java.text.MessageFormat.(MessageFormat.java:365) at java.text.MessageFormat.subformat(MessageFormat.java:1214) at java.text.MessageFormat.format(MessageFormat.java:825) at java.text.Format.format(Format.java:133) at org.apache.commons.lang.text.ExtendedMessageFormatTest.testExtendedWithChoiceFormat(ExtendedMessageFormatTest.java:138) was (Author: niallp): OK commenting out works for me - I'll do that unless you beat me to it. The failing stack trace for the test is below (snipped after ExtendedMessageFormatTest) java.lang.IllegalArgumentException: unknown format type at at java.text.MessageFormat.makeFormat(MessageFormat.java:1426) at java.text.MessageFormat.applyPattern(MessageFormat.java:447) at java.text.MessageFormat.(MessageFormat.java:365) at java.text.MessageFormat.subformat(MessageFormat.java:1214) at java.text.MessageFormat.format(MessageFormat.java:825) at java.text.Format.format(Format.java:133) at org.apache.commons.lang.text.ExtendedMessageFormatTest.testExtendedWithChoiceFormat(ExtendedMessageFormatTest.java:138) > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > ExtendedMessageFormatTest.java, FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575173#action_12575173 ] Niall Pemberton commented on LANG-362: -- OK commenting out works for me - I'll do that unless you beat me to it. The failing stack trace for the test is below (snipped after ExtendedMessageFormatTest) java.lang.IllegalArgumentException: unknown format type at at java.text.MessageFormat.makeFormat(MessageFormat.java:1426) at java.text.MessageFormat.applyPattern(MessageFormat.java:447) at java.text.MessageFormat.(MessageFormat.java:365) at java.text.MessageFormat.subformat(MessageFormat.java:1214) at java.text.MessageFormat.format(MessageFormat.java:825) at java.text.Format.format(Format.java:133) at org.apache.commons.lang.text.ExtendedMessageFormatTest.testExtendedWithChoiceFormat(ExtendedMessageFormatTest.java:138) > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > ExtendedMessageFormatTest.java, FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575128#action_12575128 ] Niall Pemberton commented on LANG-362: -- Please don't remove the test cases - they may save some effort in the future if this gets implemented > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > ExtendedMessageFormatTest.java, FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574469#action_12574469 ] Niall Pemberton commented on LANG-362: -- I'm happy with the public API were now exposing to the users and while I haven't looked in detail at the code, it is greatly simplified (thanks Matt!) and writing a test case for it gives me confidence that it works pretty well. So the only outstanding issue is wether we want to suport custom Format implementations in sub-formats (i.e. choice) or just document that they are not supported. I'm happy either way so I would say if Matt has the time and inclination to do it soon then great - otherwise lets just document they are not currently supported (in the ExtendedMessageFormat javadocs) and leave if for a later release. > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > ExtendedMessageFormatTest.java, FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-402) OSGi-ify Lang
[ https://issues.apache.org/jira/browse/LANG-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-402. -- Resolution: Fixed The maven-build-plugin is now in commons-parent 8 and lang has been configured and updated to use that version - so this now resolved for m2 http://svn.apache.org/viewvc/commons/proper/lang/trunk/pom.xml?r1=612787&r2=632815 > OSGi-ify Lang > - > > Key: LANG-402 > URL: https://issues.apache.org/jira/browse/LANG-402 > Project: Commons Lang > Issue Type: Task >Reporter: Henri Yandell >Assignee: Niall Pemberton > Fix For: 2.4 > > Attachments: LANG-402-OSGi-jar-maniest.patch > > > Pre-release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-307) BeanUtils.setProperty(...) not working for property "xValue" (see description for reason)
[ https://issues.apache.org/jira/browse/BEANUTILS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-307. --- Resolution: Invalid OK I'll close this then - thanks for checking > BeanUtils.setProperty(...) not working for property "xValue" (see description > for reason) > - > > Key: BEANUTILS-307 > URL: https://issues.apache.org/jira/browse/BEANUTILS-307 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA > Environment: linux, jdk 1.6, beanutils 1.8 beta >Reporter: Alexander Koppelhuber > > setting values for a property that has one lower case character at the > beginning > followed by an upper case character does not work. for example "xValue" or > "zIndex". > The reason (as far as I found out) is as follows: > Introspector.getBeanInfo() gets the property names from the get/set methods. > In Introspector.getTargetPropertyInfo() the following code creates a > PropertyDescriptor: > >pd = new PropertyDescriptor(decapitalize(name.substring(3)),..) > decapitalize() says "when there is more than one character and both > the first and second characters are upper case, we leave it alone..." > which results in the name = "XValue" for the method getXValue() > so setProperty(...) does not find a descriptor for "xValue" and cannot call > the setXValue method > I think this issue is not limited to 1.8 beta but also to earlier versions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-307) BeanUtils.setProperty(...) not working for property "xValue" (see description for reason)
[ https://issues.apache.org/jira/browse/BEANUTILS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573379#action_12573379 ] Niall Pemberton commented on BEANUTILS-307: --- OK its been a while since I looked at the java beans spec - my first thought is you should be using "XValue" as the property name instead of "xValue". > BeanUtils.setProperty(...) not working for property "xValue" (see description > for reason) > - > > Key: BEANUTILS-307 > URL: https://issues.apache.org/jira/browse/BEANUTILS-307 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA > Environment: linux, jdk 1.6, beanutils 1.8 beta >Reporter: Alexander Koppelhuber > > setting values for a property that has one lower case character at the > beginning > followed by an upper case character does not work. for example "xValue" or > "zIndex". > The reason (as far as I found out) is as follows: > Introspector.getBeanInfo() gets the property names from the get/set methods. > In Introspector.getTargetPropertyInfo() the following code creates a > PropertyDescriptor: > >pd = new PropertyDescriptor(decapitalize(name.substring(3)),..) > decapitalize() says "when there is more than one character and both > the first and second characters are upper case, we leave it alone..." > which results in the name = "XValue" for the method getXValue() > so setProperty(...) does not find a descriptor for "xValue" and cannot call > the setXValue method > I think this issue is not limited to 1.8 beta but also to earlier versions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-285) Wish : method unaccent
[ https://issues.apache.org/jira/browse/LANG-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-285: - Attachment: LANG-285-unaccent-using-Collator.patch Perhaps an alternative to using a Map of characters is to use a Collator to compare characters to the standard 26 latin chars? http://java.sun.com/j2se/1.3/docs/api/java/text/Collator.html Attaching LANG-285-unaccent-using-Collator.patch which does this and includes Guillaume Coté's test case - which it passes. > Wish : method unaccent > -- > > Key: LANG-285 > URL: https://issues.apache.org/jira/browse/LANG-285 > Project: Commons Lang > Issue Type: New Feature >Reporter: Guillaume Coté >Priority: Minor > Fix For: 3.0 > > Attachments: LANG-285-unaccent-using-Collator.patch, MapBuilder.java, > unaccent.patch, UnnacentMap.java > > > I would like to add a method that replace accented caracter by unaccented > one. For example, with the input String "L'été où j'ai dû aller à l'île > d'Anticosti commenca tôt", the method would return "L'ete ou j'ai du aller à > l'ile d'Anticosti commenca tot". > I suggest to call that method unaccent and to add it in StringUtils. > If we cannot covert all case, the first version could only covert iso-8859-1. > If you are willing to go forward with that idea, I am willing to contribute a > patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572966#action_12572966 ] Niall Pemberton commented on LANG-362: -- OK I've commited my test case: http://svn.apache.org/viewvc?view=rev&revision=631639 Mind if I delete the other four? - AbstractMessageFormatTest - ExtendedMessageFormatBaselineTest - MessageFormatExtensionTest - MessageFormatTest > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > ExtendedMessageFormatTest.java, FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
