[jira] [Resolved] (VFS-285) AbstractFileObject.getChildren(): internal structures will be left inconsistent if the excepion is thrown

2013-01-16 Thread Thomas Neidhart (JIRA)

 [ 
https://issues.apache.org/jira/browse/VFS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved VFS-285.
-

   Resolution: Fixed
Fix Version/s: 2.1

Committed an improved patch in r1433872.

Instead of catching the (possible) FileSystemException, use a temporary storage 
that will be assigned to the member filed only after successfully resolving 
children.

 AbstractFileObject.getChildren(): internal structures will be left 
 inconsistent if the excepion is thrown
 -

 Key: VFS-285
 URL: https://issues.apache.org/jira/browse/VFS-285
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Kirill Safonov
Priority: Critical
 Fix For: 2.1

 Attachments: VFS-285.patch


 AbstractFileObject.getChildren() creates *children* array and then fills it 
 by resolving child names via FileSystemManager.resolveName(). If the latter 
 method throws an exception (in my case it's Invalid descendent file name 
 pci-:00:07.1-scsi-0:0:0:0), children array is left as is with some of 
 the entries = null, that inevitably results in NPE on the next getChildren() 
 call:
 at 
 org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:319)
   at 
 org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:314)
   at 
 org.apache.commons.vfs.provider.AbstractFileObject.resolveFile(AbstractFileObject.java:723)
   at 
 org.apache.commons.vfs.provider.AbstractFileObject.resolveFiles(AbstractFileObject.java:715)
   at 
 org.apache.commons.vfs.provider.AbstractFileObject.getChildren(AbstractFileObject.java:618)
   at 
 org.apache.commons.vfs.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:412)
 since AbstractFileObject.getChildren() only checks that *children* instance 
 is not null

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (VFS-396) RAM FileSystem allows the file system size to exceed the max size limit.

2013-01-16 Thread Thomas Neidhart (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13554892#comment-13554892
 ] 

Thomas Neidhart commented on VFS-396:
-

I just realized that there is a potential glitch that could/should be improved:

the write method of the RAMFileOutputStream will only throw an IOException, 
while the close may throw a (delayed) FileSystemException.
As the OutputStream as received by FileContent.getOutputStream will be wrapped 
by another, buffered stream, a user may either receive the actual exception 
when calling flush or close and it will be an FileSystemException instead of 
the IOException if the content is immediately written by write.

 RAM FileSystem allows the file system size to exceed the max size limit.
 

 Key: VFS-396
 URL: https://issues.apache.org/jira/browse/VFS-396
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.0
 Environment: All
Reporter: Rupesh Kumar
   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 When a new file is created in the RAM file system, and content is written to 
 its outputstream, there is a check in place for ensuring that file system 
 size does not exceed the max limit set. But that check is wrong.
 In RamFileOutputStream.write(), you calculate the size, newsize and call 
 file.resize(newSize)
 And in the RamFileObject.resize(), there is a check 
  if (fs.size() + newSize - this.size()  maxSize)
 {
 throw new IOException(FileSystem capacity ( + maxSize
 + ) exceeded.);
 }
 This check is wrong. 
 Consider this case of a new file system where the file system size is set to 
 5 MB and I am trying to create a file of 10 MB in the RAM file system. the 
 file is being written in the chunk of 8 kb. For every resize check, fs.size() 
 would be 0 and (newsize - this.size()) would be 8 kb and therefore the check 
 never passes.
  It could have been correct if the old size was locked down to the size 
 that was registered with the file system but the old size (this.size()) keeps 
 changing at every write. Thus the difference in newSize and this.size() would 
 always be the chunk size (typically 8 kb) and therefore no exception would be 
 thrown ever.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (DAEMON-274) procrun ignores shutdown

2013-01-16 Thread Hsehdar (JIRA)

[ 
https://issues.apache.org/jira/browse/DAEMON-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13554961#comment-13554961
 ] 

Hsehdar commented on DAEMON-274:


Thanks [~mt...@apache.org] for sharing the 1.0.12 release artifacts. Tested 
with the app which was causing this issue found it is no more a problem.

 procrun ignores shutdown
 

 Key: DAEMON-274
 URL: https://issues.apache.org/jira/browse/DAEMON-274
 Project: Commons Daemon
  Issue Type: Bug
  Components: Procrun
Affects Versions: 1.0.10
 Environment: Windows OS
Reporter: Hsehdar
Assignee: Mladen Turk
  Labels: procrun
 Fix For: 1.0.12


 Procrun does not gracefully shut down when OS shut down occurs. Operating 
 system kills the service started. Service started using procrun is with state 
 IGNORES_SHUTDOWN.
 What was expected?
 Procrun service registered to be ACCEPTS_SHUTDOWN such that procrun shuts 
 down gracefully within the time allocated by OS.
 It would be great if this becomes command line parameter. It will be a bonus 
 :)
 Author requests assignee to change this issue details.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (CLI-229) Missing place holder in required argument

2013-01-16 Thread Palmer Eldritch (JIRA)

[ 
https://issues.apache.org/jira/browse/CLI-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13554974#comment-13554974
 ] 

Palmer Eldritch commented on CLI-229:
-

Could you try with version 1.2 - just to verify ?
Are you on Java 7 ?

 Missing place holder in required argument
 -

 Key: CLI-229
 URL: https://issues.apache.org/jira/browse/CLI-229
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
Affects Versions: 1.2
 Environment: Windows 7 x64, Java 1.7.9
Reporter: Palmer Eldritch
Priority: Minor
 Fix For: 1.3


 The code below :
 {code}
 @SuppressWarnings(static-access)
 public class CliArgBug {
   private static final Options OPTIONS = new Options();
   static {
   // FIXME : bug ? usage prints --seq1 --seq2 arg - notice arg
   // missing in seq1 - corrected by adding .withArgName(file1)
   OPTIONS.addOption(OptionBuilder
   .withLongOpt(seq1)
   .withDescription(
   REQUIRED : the file containing 
 sequence 1)
   .hasArg().isRequired().create());
   OPTIONS.addOption(OptionBuilder
   .withLongOpt(seq2)
   .withDescription(
   REQUIRED : the file containing 
 sequence 2)
   .hasArg().isRequired().create());
   }
   public static void main(String[] args) {
   HelpFormatter formatter = new HelpFormatter();
   formatter.printHelp(Notice arg is missing in seq1, OPTIONS, 
 true);
   }
 }
 {code}
 Produces :
 {code}
 usage: Notice arg is missing in seq1 --seq1 --seq2 arg
 --seq1 REQUIRED : the file containing sequence 
 --seq2 arg   REQUIRED : the file containing sequence 2
 {code}
 Also I was not able to find any info on where this placeholder arg is 
 defined - please add this to the javadoc
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (DAEMON-274) procrun ignores shutdown

2013-01-16 Thread Adam Fanello (JIRA)

[ 
https://issues.apache.org/jira/browse/DAEMON-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555421#comment-13555421
 ] 

Adam Fanello commented on DAEMON-274:
-

Tested. It's working for me as well.

 procrun ignores shutdown
 

 Key: DAEMON-274
 URL: https://issues.apache.org/jira/browse/DAEMON-274
 Project: Commons Daemon
  Issue Type: Bug
  Components: Procrun
Affects Versions: 1.0.10
 Environment: Windows OS
Reporter: Hsehdar
Assignee: Mladen Turk
  Labels: procrun
 Fix For: 1.0.12


 Procrun does not gracefully shut down when OS shut down occurs. Operating 
 system kills the service started. Service started using procrun is with state 
 IGNORES_SHUTDOWN.
 What was expected?
 Procrun service registered to be ACCEPTS_SHUTDOWN such that procrun shuts 
 down gracefully within the time allocated by OS.
 It would be great if this becomes command line parameter. It will be a bonus 
 :)
 Author requests assignee to change this issue details.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (OGNL-230) Update Javassist to 3.17.1

2013-01-16 Thread Eduardo Macarron (JIRA)
Eduardo Macarron created OGNL-230:
-

 Summary: Update Javassist to 3.17.1
 Key: OGNL-230
 URL: https://issues.apache.org/jira/browse/OGNL-230
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Affects Versions: 3.0
Reporter: Eduardo Macarron
Priority: Trivial


Hello. 

I have just tested latest MyBatis trunk with OGNL 4 and all test pass. Good 
work!

I noticed OGNL 4 depends on a quite old Javassist version (3.12.1). I would 
like to suggest to upgrade to 3.17.1 (still jdk 5) before going GA.

BTW, this version is ASL 2.0 (old versions are not)

Note Javasisst maven groupid has changed:
from:

dependency
  groupIdjavassist/groupId
  artifactIdjavassist/artifactId
  version3.12.1-GA/version
/dependency

to: 

dependency
  groupIdorg.javassist/groupId
  artifactIdjavassist/artifactId
  version3.17.1-GA/version
/dependency


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (OGNL-230) Update Javassist to 3.17.1

2013-01-16 Thread Eduardo Macarron (JIRA)

 [ 
https://issues.apache.org/jira/browse/OGNL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduardo Macarron updated OGNL-230:
--

Affects Version/s: (was: 3.0)

 Update Javassist to 3.17.1
 --

 Key: OGNL-230
 URL: https://issues.apache.org/jira/browse/OGNL-230
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Reporter: Eduardo Macarron
Priority: Trivial
  Labels: javassist
   Original Estimate: 1h
  Remaining Estimate: 1h

 Hello. 
 I have just tested latest MyBatis trunk with OGNL 4 and all test pass. Good 
 work!
 I noticed OGNL 4 depends on a quite old Javassist version (3.12.1). I would 
 like to suggest to upgrade to 3.17.1 (still jdk 5) before going GA.
 BTW, this version is ASL 2.0 (old versions are not)
 Note Javasisst maven groupid has changed:
 from:
 dependency
   groupIdjavassist/groupId
   artifactIdjavassist/artifactId
   version3.12.1-GA/version
 /dependency
 to: 
 dependency
   groupIdorg.javassist/groupId
   artifactIdjavassist/artifactId
   version3.17.1-GA/version
 /dependency

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (OGNL-230) Update Javassist to 3.17.1

2013-01-16 Thread Lukasz Lenart (JIRA)

[ 
https://issues.apache.org/jira/browse/OGNL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555919#comment-13555919
 ] 

Lukasz Lenart commented on OGNL-230:


I've tried compile commons-ognl with the version 3.17.1-GA on JDK5 but got

[ERROR] bad class file: 
/Users/lukaszlenart/.m2/repository/org/javassist/javassist/3.17.1-GA/javassist-3.17.1-GA.jar(javassist/CannotCompileException.class)
[ERROR] class file has wrong version 50.0, should be 49.0

looks like the jar in the Maven Central was build with JDK6 :\ When I try to 
build on JDK6 many tests fail.

The only version which works is 3.16.1-GA, I had the same with OGNL 3.x (but 
just only on JDK6).

 Update Javassist to 3.17.1
 --

 Key: OGNL-230
 URL: https://issues.apache.org/jira/browse/OGNL-230
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Reporter: Eduardo Macarron
Priority: Trivial
  Labels: javassist
   Original Estimate: 1h
  Remaining Estimate: 1h

 Hello. 
 I have just tested latest MyBatis trunk with OGNL 4 and all test pass. Good 
 work!
 I noticed OGNL 4 depends on a quite old Javassist version (3.12.1). I would 
 like to suggest to upgrade to 3.17.1 (still jdk 5) before going GA.
 BTW, this version is ASL 2.0 (old versions are not)
 Note Javasisst maven groupid has changed:
 from:
 dependency
   groupIdjavassist/groupId
   artifactIdjavassist/artifactId
   version3.12.1-GA/version
 /dependency
 to: 
 dependency
   groupIdorg.javassist/groupId
   artifactIdjavassist/artifactId
   version3.17.1-GA/version
 /dependency

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (OGNL-230) Update Javassist to 3.17.1

2013-01-16 Thread Lukasz Lenart (JIRA)

[ 
https://issues.apache.org/jira/browse/OGNL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555923#comment-13555923
 ] 

Lukasz Lenart commented on OGNL-230:


This can be related
https://issues.jboss.org/browse/JASSIST-178

Maybe it's better to wait for 3.17.2-GA ;-)

 Update Javassist to 3.17.1
 --

 Key: OGNL-230
 URL: https://issues.apache.org/jira/browse/OGNL-230
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Reporter: Eduardo Macarron
Priority: Trivial
  Labels: javassist
   Original Estimate: 1h
  Remaining Estimate: 1h

 Hello. 
 I have just tested latest MyBatis trunk with OGNL 4 and all test pass. Good 
 work!
 I noticed OGNL 4 depends on a quite old Javassist version (3.12.1). I would 
 like to suggest to upgrade to 3.17.1 (still jdk 5) before going GA.
 BTW, this version is ASL 2.0 (old versions are not)
 Note Javasisst maven groupid has changed:
 from:
 dependency
   groupIdjavassist/groupId
   artifactIdjavassist/artifactId
   version3.12.1-GA/version
 /dependency
 to: 
 dependency
   groupIdorg.javassist/groupId
   artifactIdjavassist/artifactId
   version3.17.1-GA/version
 /dependency

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (OGNL-230) Update Javassist to 3.17.1

2013-01-16 Thread Eduardo Macarron (JIRA)

[ 
https://issues.apache.org/jira/browse/OGNL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555940#comment-13555940
 ] 

Eduardo Macarron commented on OGNL-230:
---

Hi Lukasz.

You are right. My fault! 

source1.6/source
target1.6/target

Is quite difficult to follow with JDK is javassist compiled on, it changes 
quite frequently ;)

Note that 3.17.0 is JDK 1.7, but according to the issue you point, it was a 
mistake that was fixed in 3.17.1.

Note that next version will be 3.18.0 but it looks that from now over all 
javassist versions are going to require JDK 1.6  so I suppose that commons-ognl 
should stay in 3.16.1-GA then.

Thanks for looking into this!


 Update Javassist to 3.17.1
 --

 Key: OGNL-230
 URL: https://issues.apache.org/jira/browse/OGNL-230
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Reporter: Eduardo Macarron
Priority: Trivial
  Labels: javassist
   Original Estimate: 1h
  Remaining Estimate: 1h

 Hello. 
 I have just tested latest MyBatis trunk with OGNL 4 and all test pass. Good 
 work!
 I noticed OGNL 4 depends on a quite old Javassist version (3.12.1). I would 
 like to suggest to upgrade to 3.17.1 (still jdk 5) before going GA.
 BTW, this version is ASL 2.0 (old versions are not)
 Note Javasisst maven groupid has changed:
 from:
 dependency
   groupIdjavassist/groupId
   artifactIdjavassist/artifactId
   version3.12.1-GA/version
 /dependency
 to: 
 dependency
   groupIdorg.javassist/groupId
   artifactIdjavassist/artifactId
   version3.17.1-GA/version
 /dependency

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (OGNL-230) Update Javassist to 3.17.1

2013-01-16 Thread Eduardo Macarron (JIRA)

[ 
https://issues.apache.org/jira/browse/OGNL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555940#comment-13555940
 ] 

Eduardo Macarron edited comment on OGNL-230 at 1/17/13 7:10 AM:


Hi Lukasz.

You are right. My fault! 

source1.6/source
target1.6/target

It is quite difficult to follow which JDK is javassist compiled on, it changes 
quite frequently ;)

Note that 3.17.0 is JDK 1.7, but according to the issue you point, it was a 
mistake that was fixed in 3.17.1.

Note that next version will be 3.18.0 but it looks that from now over all 
javassist versions are going to require JDK 1.6  so I suppose that commons-ognl 
should stay in 3.16.1-GA then.

Thanks for looking into this!


  was (Author: emacarron):
Hi Lukasz.

You are right. My fault! 

source1.6/source
target1.6/target

Is quite difficult to follow with JDK is javassist compiled on, it changes 
quite frequently ;)

Note that 3.17.0 is JDK 1.7, but according to the issue you point, it was a 
mistake that was fixed in 3.17.1.

Note that next version will be 3.18.0 but it looks that from now over all 
javassist versions are going to require JDK 1.6  so I suppose that commons-ognl 
should stay in 3.16.1-GA then.

Thanks for looking into this!

  
 Update Javassist to 3.17.1
 --

 Key: OGNL-230
 URL: https://issues.apache.org/jira/browse/OGNL-230
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Reporter: Eduardo Macarron
Priority: Trivial
  Labels: javassist
   Original Estimate: 1h
  Remaining Estimate: 1h

 Hello. 
 I have just tested latest MyBatis trunk with OGNL 4 and all test pass. Good 
 work!
 I noticed OGNL 4 depends on a quite old Javassist version (3.12.1). I would 
 like to suggest to upgrade to 3.17.1 (still jdk 5) before going GA.
 BTW, this version is ASL 2.0 (old versions are not)
 Note Javasisst maven groupid has changed:
 from:
 dependency
   groupIdjavassist/groupId
   artifactIdjavassist/artifactId
   version3.12.1-GA/version
 /dependency
 to: 
 dependency
   groupIdorg.javassist/groupId
   artifactIdjavassist/artifactId
   version3.17.1-GA/version
 /dependency

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (OGNL-230) Update Javassist to 3.17.1

2013-01-16 Thread Eduardo Macarron (JIRA)

[ 
https://issues.apache.org/jira/browse/OGNL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555940#comment-13555940
 ] 

Eduardo Macarron edited comment on OGNL-230 at 1/17/13 7:10 AM:


Hi Lukasz.

You are right. My fault! 

source1.6/source
target1.6/target

It is quite difficult to follow which JDK is javassist compiled on, it changes 
quite frequently ;)

Note that 3.17.0 is JDK 1.7, but according to the issue you pointed, it was a 
mistake that was fixed in 3.17.1.

Note that next version will be 3.18.0 but it looks that from now over all 
javassist versions are going to require JDK 1.6  so I suppose that commons-ognl 
should stay in 3.16.1-GA then.

Thanks for looking into this!


  was (Author: emacarron):
Hi Lukasz.

You are right. My fault! 

source1.6/source
target1.6/target

It is quite difficult to follow which JDK is javassist compiled on, it changes 
quite frequently ;)

Note that 3.17.0 is JDK 1.7, but according to the issue you point, it was a 
mistake that was fixed in 3.17.1.

Note that next version will be 3.18.0 but it looks that from now over all 
javassist versions are going to require JDK 1.6  so I suppose that commons-ognl 
should stay in 3.16.1-GA then.

Thanks for looking into this!

  
 Update Javassist to 3.17.1
 --

 Key: OGNL-230
 URL: https://issues.apache.org/jira/browse/OGNL-230
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Reporter: Eduardo Macarron
Priority: Trivial
  Labels: javassist
   Original Estimate: 1h
  Remaining Estimate: 1h

 Hello. 
 I have just tested latest MyBatis trunk with OGNL 4 and all test pass. Good 
 work!
 I noticed OGNL 4 depends on a quite old Javassist version (3.12.1). I would 
 like to suggest to upgrade to 3.17.1 (still jdk 5) before going GA.
 BTW, this version is ASL 2.0 (old versions are not)
 Note Javasisst maven groupid has changed:
 from:
 dependency
   groupIdjavassist/groupId
   artifactIdjavassist/artifactId
   version3.12.1-GA/version
 /dependency
 to: 
 dependency
   groupIdorg.javassist/groupId
   artifactIdjavassist/artifactId
   version3.17.1-GA/version
 /dependency

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira