bean utils : automatic type conversion newbie question

[Paul Hussein]

Hi,

I am trying to use Bean Utils to fill my bean. I am expecting automatic
conversion from String to BigDecimal or Float and various other base types.
However for me this is not working.


When I call

PropertyUtils.setProperty(bean, VALUE, 125.0)

on a method

public void setVALUE(Float VALUE) {

I get the error 'argument type mismatch - had objects of type
java.lang.String but expected signature java.lang.Float'

Am I missing somethimg ? DO I have to explicitly state which converters to
use automatically ???

Thanks

Paul.


0[main] DEBUG
org.apache.commons.beanutils.converters.BooleanConverter.setDefaultValue  -
Setting default value: false
6[main] DEBUG
org.apache.commons.beanutils.converters.BooleanConverter.convert  -
Converting 'Boolean' value 'false' to type 'Boolean'
8[main] DEBUG
org.apache.commons.beanutils.converters.BooleanConverter.convert  - No
conversion required, value is already a Boolean
16   [main] DEBUG
org.apache.commons.beanutils.converters.ByteConverter.setDefaultValue  -
Setting default value: 0
19   [main] DEBUG
org.apache.commons.beanutils.converters.ByteConverter.convert  - Converting
'Integer' value '0' to type 'Byte'
27   [main] DEBUG
org.apache.commons.beanutils.converters.ByteConverter.convert  -
Converted to Byte value '0'
30   [main] DEBUG
org.apache.commons.beanutils.converters.CharacterConverter.setDefaultValue
- Setting default value:
32   [main] DEBUG
org.apache.commons.beanutils.converters.CharacterConverter.convert  -
Converting 'Character' value ' ' to type 'Character'
33   [main] DEBUG
org.apache.commons.beanutils.converters.CharacterConverter.convert  - No
conversion required, value is already a Character
36   [main] DEBUG
org.apache.commons.beanutils.converters.DoubleConverter.setDefaultValue  -
Setting default value: 0
37   [main] DEBUG
org.apache.commons.beanutils.converters.DoubleConverter.convert  -
Converting 'Integer' value '0' to type 'Double'
38   [main] DEBUG
org.apache.commons.beanutils.converters.DoubleConverter.convert  -
Converted to Double value '0.0'
40   [main] DEBUG
org.apache.commons.beanutils.converters.FloatConverter.setDefaultValue  -
Setting default value: 0
41   [main] DEBUG
org.apache.commons.beanutils.converters.FloatConverter.convert  - Converting
'Integer' value '0' to type 'Float'
42   [main] DEBUG
org.apache.commons.beanutils.converters.FloatConverter.convert  -
Converted to Float value '0.0'
44   [main] DEBUG
org.apache.commons.beanutils.converters.IntegerConverter.setDefaultValue  -
Setting default value: 0
46   [main] DEBUG
org.apache.commons.beanutils.converters.IntegerConverter.convert  -
Converting 'Integer' value '0' to type 'Integer'
47   [main] DEBUG
org.apache.commons.beanutils.converters.IntegerConverter.convert  - No
conversion required, value is already a Integer
48   [main] DEBUG
org.apache.commons.beanutils.converters.LongConverter.setDefaultValue  -
Setting default value: 0
49   [main] DEBUG
org.apache.commons.beanutils.converters.LongConverter.convert  - Converting
'Integer' value '0' to type 'Long'
50   [main] DEBUG
org.apache.commons.beanutils.converters.LongConverter.convert  -
Converted to Long value '0'
52   [main] DEBUG
org.apache.commons.beanutils.converters.ShortConverter.setDefaultValue  -
Setting default value: 0
54   [main] DEBUG
org.apache.commons.beanutils.converters.ShortConverter.convert  - Converting
'Integer' value '0' to type 'Short'
55   [main] DEBUG
org.apache.commons.beanutils.converters.ShortConverter.convert  -
Converted to Short value '0'
58   [main] DEBUG
org.apache.commons.beanutils.converters.BigDecimalConverter.setDefaultValue
- Setting default value: 0.0
59   [main] DEBUG
org.apache.commons.beanutils.converters.BigDecimalConverter.convert  -
Converting 'BigDecimal' value '0.0' to type 'BigDecimal'
60   [main] DEBUG
org.apache.commons.beanutils.converters.BigDecimalConverter.convert  -
No conversion required, value is already a BigDecimal
63   [main] DEBUG
org.apache.commons.beanutils.converters.BigIntegerConverter.setDefaultValue
- Setting default value: 0
64   [main] DEBUG
org.apache.commons.beanutils.converters.BigIntegerConverter.convert  -
Converting 'BigInteger' value '0' to type 'BigInteger'
65   [main] DEBUG
org.apache.commons.beanutils.converters.BigIntegerConverter.convert  -
No conversion required, value is already a BigInteger
66   [main] DEBUG
org.apache.commons.beanutils.converters.BooleanConverter.setDefaultValue  -
Setting default value: false
67   [main] DEBUG
org.apache.commons.beanutils.converters.BooleanConverter.convert  -
Converting 'Boolean' value 'false' to type 'Boolean'
70   [main] DEBUG
org.apache.commons.beanutils.converters.BooleanConverter.convert  - No
conversion required, value is already a Boolean
71   [main] DEBUG
org.apache.commons.beanutils.converters.ByteConverter.setDefaultValue  -
Setting default value: 0
72   [main] DEBUG
org.apache.commons.beanutils.converters.ByteConverter.convert  - Converting
'Integer' value '0' 

Common Net 1.4.1

[bhamilton]

I'm using Common Net 1.4.1, the FTPClient listFiles() method to an array 
of FTPFile objects.  The Calendar object, within the FTPFile object, has 
a TimeZone of GMT.  One question is how is that determined?  On the 
client machine, the default TimeZone is 'America/New_York'.


The dates returned in the Calendar are not consistent.  When the process 
ran at 6:02 this morning, a certain file had a date time of 20080303 
06:05:00.  When the process ran 5 minutes later, at 6:07am, the same 
file had a date and time of 20090303 06:05:00.


Any thoughts?

Thanks!
Brenda Hamilton

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Common Net 1.4.1

[bhamilton]

A little more information.  The FTPFile Calendar object is reporting the 
year, for most of the files as 2008.  All of the files are from 2009.


bhamilton wrote:
The client process is running on a linux.  I can't confirm, but I 
believe the ftp server is also a linux machine.  I can normalize the 
times between the differing TimeZones but the dates returned by the 
FTPClient listFiles(), run 5 minutes apart, return different years for 
the same file.


Rusty Wright wrote:
The underlying operating system, unix for sure, but I'm not sure 
about windows, stores time values in GMT.  When it *displays* them it 
converts them to whatever the local time zone is.



bhamilton wrote:
I'm using Common Net 1.4.1, the FTPClient listFiles() method to an 
array of FTPFile objects.  The Calendar object, within the FTPFile 
object, has a TimeZone of GMT.  One question is how is that 
determined?  On the client machine, the default TimeZone is 
'America/New_York'.


The dates returned in the Calendar are not consistent.  When the 
process ran at 6:02 this morning, a certain file had a date time of 
20080303 06:05:00.  When the process ran 5 minutes later, at 6:07am, 
the same file had a date and time of 20090303 06:05:00.


Any thoughts?

Thanks!
Brenda Hamilton

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Common Net 1.4.1

[bhamilton]

I think I may see the problem.

The files on the remote server at stored with the date time in GMT where 
as my client server is 'American/New_York'.  The ftp client gets the 
results of the LIST command.  Suppose a file 'A' has a date 'Mar 03' and 
time of '13:00'.  That date and time is GMT.  If the ftp client date is 
'Mar 03' and time of '12:30', then the time of '13:00' is in the future 
and the list parser assumes the file year is 2008.


Now to think of a workaround...

bhamilton wrote:
A little more information.  The FTPFile Calendar object is reporting 
the year, for most of the files as 2008.  All of the files are from 2009.


bhamilton wrote:
The client process is running on a linux.  I can't confirm, but I 
believe the ftp server is also a linux machine.  I can normalize the 
times between the differing TimeZones but the dates returned by the 
FTPClient listFiles(), run 5 minutes apart, return different years 
for the same file.


Rusty Wright wrote:
The underlying operating system, unix for sure, but I'm not sure 
about windows, stores time values in GMT.  When it *displays* them 
it converts them to whatever the local time zone is.



bhamilton wrote:
I'm using Common Net 1.4.1, the FTPClient listFiles() method to an 
array of FTPFile objects.  The Calendar object, within the FTPFile 
object, has a TimeZone of GMT.  One question is how is that 
determined?  On the client machine, the default TimeZone is 
'America/New_York'.


The dates returned in the Calendar are not consistent.  When the 
process ran at 6:02 this morning, a certain file had a date time of 
20080303 06:05:00.  When the process ran 5 minutes later, at 
6:07am, the same file had a date and time of 20090303 06:05:00.


Any thoughts?

Thanks!
Brenda Hamilton

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: FTPClient Stalls on STOR

[sebb]

Aren't there two connections involved here - i.e. the control and data
connections?

Surely the data connection will be kept alive by the STOR command; the
NOOP is presumably only needed on the control connection?

I would question whether the F5 load balancer is working correctly if
it fails to take the data connection traffic into account. But I could
be wrong.

On 03/03/2009, Meeraj Kunnumpurath mkunnumpur...@googlemail.com wrote:
 Hi,

  That is what I have done.

  If I do the STOR and NOOP on two threads, isn't there a possible race
  condition with the response for STOR and NOOP coming back the same time as
  they share the same socket?
  Ta

 Meeraj


  On Tue, Mar 3, 2009 at 6:54 PM, Daniel F. Savarese d...@savarese.org wrote:

  
   In message 66a7a36a-d185-419a-8462-dc6450237...@eircom.net, Rory Winston
   writ
   es:
   Currently, FTPClient doesnt support keepalive, but I suspect that it
   probably should. I'll raise a JIRA ticket.
  
   There's nothing stopping the programmer fromn sending a NOOP every
   t seconds over the control connection.  However, if one expects
   FTPClient to do it automatically, then, sure, it doesn't support it.
  
   daniel
  
  
  
   -
   To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
   For additional commands, e-mail: user-h...@commons.apache.org
  
  


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: JXPath over Generic Collection?, How?

[Andrew Hughes]

For efficiency reasons I can see why you are using String[] here and not
List.add()...
Anyway, I have a fix (sort of) for this bug. The number of names needs to be
calculated a little differently to what it currently is...

public String[] getPropertyNames() {
/* @todo do something about the sorting - LIKE WHAT? - MJB */
if (names == null) {
DynaClass dynaClass = dynaBean.getDynaClass();
DynaProperty[] properties = dynaClass.getDynaProperties();
int count = properties.length;
boolean hasClass = dynaClass.getDynaProperty(class) != null;

//count the number of property names we have
count = 0;
for (int i = 0; i  properties.length; i++) {
String name = properties[i].getName();
if (!hasClass || !name.equals(class)) {
count++; //it's only a property is it's not a class and
doesn't just have a class property.
}
}
//read the property names into a String[] to return
names = new String[count];
for (int i = 0, j = 0; i  properties.length; i++) {
String name = properties[i].getName();
if (!hasClass || !name.equals(class)) {
names[j++] = name;
}
}
Arrays.sort(names);
}
return names;
}

Now I can sort of sucessfully run all my expressions, yippee!! However, I
now have a problem with multiple deep results. Queries like //dog/* I would
expect to return all dog's[] but this just returns the first one it finds.
Maybe this is asking a little too much of JXPath and child/node
step-up/step-down traversal? Matt can probably tell me if this is or is not
the case plase :)





On Wed, Mar 4, 2009 at 9:38 AM, Andrew Hughes ahhug...@gmail.com wrote:

 Pretty sure this is a bug in JXPath - and it is not tested by the current
 unit tests.
 I can't quite work out 100% of what's going on here... but it has to do
 with gathering the property names from a DynaBean child member of a (parent)
 DynaBean. Especially, when it try's to deal with the property named 'name'
 and 'class'.

 The problem with query '//dog' etc's 'ArrayOutOfBoundsException 0' occurs
 below. And rightfully so, names[] is a zero length array and for some
 reason JXPath is trying to set a value for the first entry of a zero length
 array.  That aint ever going to work! But why is the array length zero?
 Because the properties.length==1, however the 'hasClass==true' and it's
 count-- then negates the correct count calculated from properties.length. I
 think the problem is in the hasClass calculation... 'boolean hasClass =
 dynaClass.getDynaProperty(class) != null;'  or the conditional 'if'
 statement. I don't understand the JXPath logic here completely, but I know
 it doesn't deal with the way I am using it and I genuinely feel this is a
 bug we can fix :'(


 public String[] getPropertyNames() {
 /* @todo do something about the sorting - LIKE WHAT? - MJB */
 if (names == null) {
 DynaClass dynaClass = dynaBean.getDynaClass();
 DynaProperty[] properties = dynaClass.getDynaProperties();
  //returns one property 'name=root' (correct)
 int count = properties.length; //returns/set's '1' (correct)
 boolean hasClass = dynaClass.getDynaProperty(class) != null;
 //returns/sets 'true' (?unknown?)
 if (hasClass) { //this is true and executes
 count--;   // Exclude class from properties
 }
 names = new String[count]; //names is a zero length array.
 WRONG!!! I do have at least 1 property called 'name'
 for (int i = 0, j = 0; i  properties.length; i++) {
 String name = properties[i].getName();
 if (!hasClass || !name.equals(class)) {
 names[j++] = name; //it breaks here
 ArrayOutOfBoundsException 0! WRONG :'(
 }
 }
 Arrays.sort(names);
 }
 return names;
 }




 On Fri, Feb 27, 2009 at 10:02 AM, Andrew Hughes ahhug...@gmail.comwrote:

 Thanks again Matt, good to hear that it's working at your end :) At my end
 JXPath's DynaBeanPropertyPointer seems to get into problems
 with ArraIndexOutOfBounds exceptions on the PropertyNames of my DynaBean (see
 the strack trace below) with many of the queries. I can only speculate
 why this might be... and I won't speculate publically. I'm running the code
 with JXPath 1.3,  BeanUtils 1.8.0, and Java 1.6_u11 (within eclipse 3.4). The
 code I'm trying to run is pasted below VERBATIM if that works on your
 environment and not mine then it must be a compatibility/platform problem.
 You've helped me out heaps so far Matt but can I please ask you to
 copy/paste the VERBATIM code and test?

 2009-02-27 08:43:59,940 ERROR (Main.java:89) [runEvaluation] Failed to
 

Re: FTPClient Stalls on STOR

[Rory Winston]

Yes. The control connection is what is timing out. I've seen other  
clients (FileZilla etc) use a timer to send NOOPs over the control  
connection periodically.


And Meeraj, yes, I think there may be a potential race condition with  
NOOPs being executed whilst another command is currently pending.



On 3 Mar 2009, at 22:14, sebb wrote:


Aren't there two connections involved here - i.e. the control and data
connections?

Surely the data connection will be kept alive by the STOR command; the
NOOP is presumably only needed on the control connection?

I would question whether the F5 load balancer is working correctly if
it fails to take the data connection traffic into account. But I could
be wrong.

On 03/03/2009, Meeraj Kunnumpurath mkunnumpur...@googlemail.com  
wrote:

Hi,

That is what I have done.

If I do the STOR and NOOP on two threads, isn't there a possible race
condition with the response for STOR and NOOP coming back the same  
time as

they share the same socket?
Ta

Meeraj


On Tue, Mar 3, 2009 at 6:54 PM, Daniel F. Savarese  
d...@savarese.org wrote:




In message 66a7a36a-d185-419a-8462-dc6450237...@eircom.net, Rory  
Winston

writ
es:
Currently, FTPClient doesnt support keepalive, but I suspect that  
it

probably should. I'll raise a JIRA ticket.


There's nothing stopping the programmer fromn sending a NOOP every
t seconds over the control connection.  However, if one expects
FTPClient to do it automatically, then, sure, it doesn't support it.

daniel



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org






-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: bean utils : automatic type conversion newbie question

[Niall Pemberton]

On Tue, Mar 3, 2009 at 2:24 PM, Paul Hussein paul.huss...@hapnin.net wrote:
 Hi,

 I am trying to use Bean Utils to fill my bean. I am expecting automatic
 conversion from String to BigDecimal or Float and various other base types.
 However for me this is not working.


 When I call

 PropertyUtils.setProperty(bean, VALUE, 125.0)

PropertyUtils doesnt do conversion - it just calls the setter with the
supplied value - you need to use BeanUtils to get value conversion,
try

BeanUtils.setProperty(bean, VALUE, 125.0)

Niall

 on a method

    public void setVALUE(Float VALUE) {

 I get the error 'argument type mismatch - had objects of type
 java.lang.String but expected signature java.lang.Float'

 Am I missing somethimg ? DO I have to explicitly state which converters to
 use automatically ???

 Thanks

 Paul.


 0    [main] DEBUG
 org.apache.commons.beanutils.converters.BooleanConverter.setDefaultValue  -
 Setting default value: false
 6    [main] DEBUG
 org.apache.commons.beanutils.converters.BooleanConverter.convert  -
 Converting 'Boolean' value 'false' to type 'Boolean'
 8    [main] DEBUG
 org.apache.commons.beanutils.converters.BooleanConverter.convert  -     No
 conversion required, value is already a Boolean
 16   [main] DEBUG
 org.apache.commons.beanutils.converters.ByteConverter.setDefaultValue  -
 Setting default value: 0
 19   [main] DEBUG
 org.apache.commons.beanutils.converters.ByteConverter.convert  - Converting
 'Integer' value '0' to type 'Byte'
 27   [main] DEBUG
 org.apache.commons.beanutils.converters.ByteConverter.convert  -
 Converted to Byte value '0'
 30   [main] DEBUG
 org.apache.commons.beanutils.converters.CharacterConverter.setDefaultValue
 - Setting default value:
 32   [main] DEBUG
 org.apache.commons.beanutils.converters.CharacterConverter.convert  -
 Converting 'Character' value ' ' to type 'Character'
 33   [main] DEBUG
 org.apache.commons.beanutils.converters.CharacterConverter.convert  -     No
 conversion required, value is already a Character
 36   [main] DEBUG
 org.apache.commons.beanutils.converters.DoubleConverter.setDefaultValue  -
 Setting default value: 0
 37   [main] DEBUG
 org.apache.commons.beanutils.converters.DoubleConverter.convert  -
 Converting 'Integer' value '0' to type 'Double'
 38   [main] DEBUG
 org.apache.commons.beanutils.converters.DoubleConverter.convert  -
 Converted to Double value '0.0'
 40   [main] DEBUG
 org.apache.commons.beanutils.converters.FloatConverter.setDefaultValue  -
 Setting default value: 0
 41   [main] DEBUG
 org.apache.commons.beanutils.converters.FloatConverter.convert  - Converting
 'Integer' value '0' to type 'Float'
 42   [main] DEBUG
 org.apache.commons.beanutils.converters.FloatConverter.convert  -
 Converted to Float value '0.0'
 44   [main] DEBUG
 org.apache.commons.beanutils.converters.IntegerConverter.setDefaultValue  -
 Setting default value: 0
 46   [main] DEBUG
 org.apache.commons.beanutils.converters.IntegerConverter.convert  -
 Converting 'Integer' value '0' to type 'Integer'
 47   [main] DEBUG
 org.apache.commons.beanutils.converters.IntegerConverter.convert  -     No
 conversion required, value is already a Integer
 48   [main] DEBUG
 org.apache.commons.beanutils.converters.LongConverter.setDefaultValue  -
 Setting default value: 0
 49   [main] DEBUG
 org.apache.commons.beanutils.converters.LongConverter.convert  - Converting
 'Integer' value '0' to type 'Long'
 50   [main] DEBUG
 org.apache.commons.beanutils.converters.LongConverter.convert  -
 Converted to Long value '0'
 52   [main] DEBUG
 org.apache.commons.beanutils.converters.ShortConverter.setDefaultValue  -
 Setting default value: 0
 54   [main] DEBUG
 org.apache.commons.beanutils.converters.ShortConverter.convert  - Converting
 'Integer' value '0' to type 'Short'
 55   [main] DEBUG
 org.apache.commons.beanutils.converters.ShortConverter.convert  -
 Converted to Short value '0'
 58   [main] DEBUG
 org.apache.commons.beanutils.converters.BigDecimalConverter.setDefaultValue
 - Setting default value: 0.0
 59   [main] DEBUG
 org.apache.commons.beanutils.converters.BigDecimalConverter.convert  -
 Converting 'BigDecimal' value '0.0' to type 'BigDecimal'
 60   [main] DEBUG
 org.apache.commons.beanutils.converters.BigDecimalConverter.convert  -
 No conversion required, value is already a BigDecimal
 63   [main] DEBUG
 org.apache.commons.beanutils.converters.BigIntegerConverter.setDefaultValue
 - Setting default value: 0
 64   [main] DEBUG
 org.apache.commons.beanutils.converters.BigIntegerConverter.convert  -
 Converting 'BigInteger' value '0' to type 'BigInteger'
 65   [main] DEBUG
 org.apache.commons.beanutils.converters.BigIntegerConverter.convert  -
 No conversion required, value is already a BigInteger
 66   [main] DEBUG
 org.apache.commons.beanutils.converters.BooleanConverter.setDefaultValue  -
 Setting default value: false
 67   [main] DEBUG
 org.apache.commons.beanutils.converters.BooleanConverter.convert  -
 Converting 'Boolean' value 'false' to type