Re: problem with SetPropertyRule
From: tushar mishra tush_mis...@yahoo.co.in
To: user@commons.apache.org user@commons.apache.org
Sent: Sunday, 25 September 2011 4:36 PM
Subject: problem with SetPropertyRule
Hi,
I am facing problem running a simple example using digester.
Reference - http://commons.apache.org/digester/guide/core.html
File Name - foo.xml
?xml version='1.0'?
foo fooName=The Parent
bar id=123 title=The First Child /
bar id=456 title=The Second Child /
/foo
File Name - Foo.javapackage mypackage;
import java.util.Iterator;
public class Foo
{String name;public String getName(){
return name;
}
public void setName(String name)
{
this.name = name;
}
}
File Name - Client.java
package mypackage;
import org.apache.commons.digester3.Digester;
public class Client
{
public static void main(String[] args)
{
String filename = C:\\development\\projects\\test\\resources\\foo.xml;
Foo foo = null;
Digester d = new Digester();
d.setValidating(false);
addRules(d);
// Process the input file.
try
{
java.io.File srcfile = new java.io.File(filename);
foo = (Foo) d.parse(srcfile);
}
catch (java.io.IOException ioe)
{
System.out.println(Error reading input file: + ioe.getMessage());
System.exit(-1);
}
catch (org.xml.sax.SAXException se)
{
System.out.println(Error parsing input file: + se.getMessage());
System.exit(-1);
}
System.out.println(foo.getName());
}
private static void addRules(Digester digester)
{
digester.addObjectCreate(foo, mypackage.Foo);
digester.addSetProperty(foo, fooName, name);}
}
Output
Error parsing input file:Error at line 2 char 27: Bean has no property named
The Parent
Sep 25, 2011 4:12:48 PM org.apache.commons.digester3.Digester startElement
SEVERE: Begin event threw exception
java.lang.NoSuchMethodException:Bean has no property named The Parent
at org.apache.commons.digester3.SetPropertyRule.begin(SetPropertyRule.java:133)
at org.apache.commons.digester3.Digester.startElement(Digester.java:1319)
Question Analysis
Class - SetPropertyRule
if ( attributeName.equals( this.name ) )
{
actualName = value;
}
1. What is this check for ? The documents gets parsed. It also finds the
attribute names correctly. But here, due to this condition, the attribute name
- fooName changes to The Parent.
What am I missing ?
Thanks for your time.
- Tushar
Re: problem with SetPropertyRule
Hi Tushar,
looks like you misinterpreted the SetProperty rule, read the
javadoc[1] for its description.
What would fit for your case is the SetPropertiesRule[2], so your code
should be changed to
private static void addRules(Digester digester)
{
digester.addObjectCreate( foo, mypackage.Foo );
digester.addSetProperties( foo, fooName, name );
}
HTH, have a nice day!
Simo
[1] http://s.apache.org/G2t
[2] http://s.apache.org/DuX
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 25, 2011 at 2:37 PM, tushar mishra tush_mis...@yahoo.co.in wrote:
From: tushar mishra tush_mis...@yahoo.co.in
To: user@commons.apache.org user@commons.apache.org
Sent: Sunday, 25 September 2011 4:36 PM
Subject: problem with SetPropertyRule
Hi,
I am facing problem running a simple example using digester.
Reference - http://commons.apache.org/digester/guide/core.html
File Name - foo.xml
?xml version='1.0'?
foo fooName=The Parent
bar id=123 title=The First Child /
bar id=456 title=The Second Child /
/foo
File Name - Foo.javapackage mypackage;
import java.util.Iterator;
public class Foo
{String name;public String getName(){
return name;
}
public void setName(String name)
{
this.name = name;
}
}
File Name - Client.java
package mypackage;
import org.apache.commons.digester3.Digester;
public class Client
{
public static void main(String[] args)
{
String filename = C:\\development\\projects\\test\\resources\\foo.xml;
Foo foo = null;
Digester d = new Digester();
d.setValidating(false);
addRules(d);
// Process the input file.
try
{
java.io.File srcfile = new java.io.File(filename);
foo = (Foo) d.parse(srcfile);
}
catch (java.io.IOException ioe)
{
System.out.println(Error reading input file: + ioe.getMessage());
System.exit(-1);
}
catch (org.xml.sax.SAXException se)
{
System.out.println(Error parsing input file: + se.getMessage());
System.exit(-1);
}
System.out.println(foo.getName());
}
private static void addRules(Digester digester)
{
digester.addObjectCreate(foo, mypackage.Foo);
digester.addSetProperty(foo, fooName, name);}
}
Output
Error parsing input file:Error at line 2 char 27: Bean has no property named
The Parent
Sep 25, 2011 4:12:48 PM org.apache.commons.digester3.Digester startElement
SEVERE: Begin event threw exception
java.lang.NoSuchMethodException:Bean has no property named The Parent
at
org.apache.commons.digester3.SetPropertyRule.begin(SetPropertyRule.java:133)
at org.apache.commons.digester3.Digester.startElement(Digester.java:1319)
Question Analysis
Class - SetPropertyRule
if ( attributeName.equals( this.name ) )
{
actualName = value;
}
1. What is this check for ? The documents gets parsed. It also finds the
attribute names correctly. But here, due to this condition, the attribute
name - fooName changes to The Parent.
What am I missing ?
Thanks for your time.
- Tushar
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [io] Should FileUtils.writeByteArrayToFile(...) not use a BufferedOutputStream?
Hello everyone, sorry to bump this, but does anyone not have a comment to my question? I really think I missed something, I can't imagine that the Commons IO forgot to buffer the bytes that should be written to a file. Please see my original question below. Thanks a lot! - Hello, I recently started using the FileUtils class of Commons IO, and had a quick look into the source code. The method FileUtils.writeByteArrayToFile(...) internally uses the private method openOutputStream(...), which creates (after some smart checks) an FileOutputStream. But, shouldn't writeByteArrayToFile(...) or openOutputStream(...) not use/create a BufferedOutputStream, wrapping the FileOutputStream? Or do I overlook something? I think one should always buffer the bytes when writing to a file... Any thoughts? Thanks ! - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [io] Should FileUtils.writeByteArrayToFile(...) not use a BufferedOutputStream?
Hi Timo, Timo Rumland wrote: Hello everyone, sorry to bump this, but does anyone not have a comment to my question? I really think I missed something, I can't imagine that the Commons IO forgot to buffer the bytes that should be written to a file. Please see my original question below. Why should it? You provide all the bytes which are written immediately and the stream is closed afterwards. So what should a buffer be good for except for decreasing performance? - Jörg Thanks a lot! - Hello, I recently started using the FileUtils class of Commons IO, and had a quick look into the source code. The method FileUtils.writeByteArrayToFile(...) internally uses the private method openOutputStream(...), which creates (after some smart checks) an FileOutputStream. But, shouldn't writeByteArrayToFile(...) or openOutputStream(...) not use/create a BufferedOutputStream, wrapping the FileOutputStream? Or do I overlook something? I think one should always buffer the bytes when writing to a file... Any thoughts? Thanks ! - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [io] Should FileUtils.writeByteArrayToFile(...) not use a BufferedOutputStream?
Buffering is important if you are writing many small chunks in a row. I haven't looked at the implementation of writeByteArrayToFile, but I'm assuming it the entire byte array in one shot and then closes the stream. Buffering would actually add extra overhead, as it would copy the byte array into another buffer, and the write that to the final output stream. On Sun, Sep 25, 2011 at 9:45 AM, Timo Rumland timo.ruml...@the-cr.dewrote: Hello everyone, sorry to bump this, but does anyone not have a comment to my question? I really think I missed something, I can't imagine that the Commons IO forgot to buffer the bytes that should be written to a file. Please see my original question below. Thanks a lot! - Hello, I recently started using the FileUtils class of Commons IO, and had a quick look into the source code. The method FileUtils.writeByteArrayToFile(...) internally uses the private method openOutputStream(...), which creates (after some smart checks) an FileOutputStream. But, shouldn't writeByteArrayToFile(...) or openOutputStream(...) not use/create a BufferedOutputStream, wrapping the FileOutputStream? Or do I overlook something? I think one should always buffer the bytes when writing to a file... Any thoughts? Thanks ! - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [io] Should FileUtils.writeByteArrayToFile(...) not use a BufferedOutputStream?
It does seem like an omission indeed. Gary On Sep 25, 2011, at 12:46, Timo Rumland timo.ruml...@the-cr.de wrote: Hello everyone, sorry to bump this, but does anyone not have a comment to my question? I really think I missed something, I can't imagine that the Commons IO forgot to buffer the bytes that should be written to a file. Please see my original question below. Thanks a lot! - Hello, I recently started using the FileUtils class of Commons IO, and had a quick look into the source code. The method FileUtils.writeByteArrayToFile(...) internally uses the private method openOutputStream(...), which creates (after some smart checks) an FileOutputStream. But, shouldn't writeByteArrayToFile(...) or openOutputStream(...) not use/create a BufferedOutputStream, wrapping the FileOutputStream? Or do I overlook something? I think one should always buffer the bytes when writing to a file... Any thoughts? Thanks ! - 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: [io] Should FileUtils.writeByteArrayToFile(...) not use a BufferedOutputStream?
The buffer increases performance actually. Its faster to write a file in 8KB blocks than 1 byte at a time. Gary On Sep 25, 2011, at 13:55, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Timo, Timo Rumland wrote: Hello everyone, sorry to bump this, but does anyone not have a comment to my question? I really think I missed something, I can't imagine that the Commons IO forgot to buffer the bytes that should be written to a file. Please see my original question below. Why should it? You provide all the bytes which are written immediately and the stream is closed afterwards. So what should a buffer be good for except for decreasing performance? - Jörg Thanks a lot! - Hello, I recently started using the FileUtils class of Commons IO, and had a quick look into the source code. The method FileUtils.writeByteArrayToFile(...) internally uses the private method openOutputStream(...), which creates (after some smart checks) an FileOutputStream. But, shouldn't writeByteArrayToFile(...) or openOutputStream(...) not use/create a BufferedOutputStream, wrapping the FileOutputStream? Or do I overlook something? I think one should always buffer the bytes when writing to a file... Any thoughts? Thanks ! - 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: [io] Should FileUtils.writeByteArrayToFile(...) not use a BufferedOutputStream?
True. I need to look at the impl to see how it writes the buffer. Gary On Sep 25, 2011, at 13:59, Daniel Pitts dan...@coloraura.com wrote: Buffering is important if you are writing many small chunks in a row. I haven't looked at the implementation of writeByteArrayToFile, but I'm assuming it the entire byte array in one shot and then closes the stream. Buffering would actually add extra overhead, as it would copy the byte array into another buffer, and the write that to the final output stream. On Sun, Sep 25, 2011 at 9:45 AM, Timo Rumland timo.ruml...@the-cr.dewrote: Hello everyone, sorry to bump this, but does anyone not have a comment to my question? I really think I missed something, I can't imagine that the Commons IO forgot to buffer the bytes that should be written to a file. Please see my original question below. Thanks a lot! - Hello, I recently started using the FileUtils class of Commons IO, and had a quick look into the source code. The method FileUtils.writeByteArrayToFile(...) internally uses the private method openOutputStream(...), which creates (after some smart checks) an FileOutputStream. But, shouldn't writeByteArrayToFile(...) or openOutputStream(...) not use/create a BufferedOutputStream, wrapping the FileOutputStream? Or do I overlook something? I think one should always buffer the bytes when writing to a file... Any thoughts? Thanks ! - 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: [io] Should FileUtils.writeByteArrayToFile(...) not use a BufferedOutputStream?
In this case we call FileOutputStream.write(byte[]) so the array should be output in one shot. Gary On Sep 25, 2011, at 13:59, Daniel Pitts dan...@coloraura.com wrote: Buffering is important if you are writing many small chunks in a row. I haven't looked at the implementation of writeByteArrayToFile, but I'm assuming it the entire byte array in one shot and then closes the stream. Buffering would actually add extra overhead, as it would copy the byte array into another buffer, and the write that to the final output stream. On Sun, Sep 25, 2011 at 9:45 AM, Timo Rumland timo.ruml...@the-cr.dewrote: Hello everyone, sorry to bump this, but does anyone not have a comment to my question? I really think I missed something, I can't imagine that the Commons IO forgot to buffer the bytes that should be written to a file. Please see my original question below. Thanks a lot! - Hello, I recently started using the FileUtils class of Commons IO, and had a quick look into the source code. The method FileUtils.writeByteArrayToFile(...) internally uses the private method openOutputStream(...), which creates (after some smart checks) an FileOutputStream. But, shouldn't writeByteArrayToFile(...) or openOutputStream(...) not use/create a BufferedOutputStream, wrapping the FileOutputStream? Or do I overlook something? I think one should always buffer the bytes when writing to a file... Any thoughts? Thanks ! - 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: [vfs] webdav problem
Sorry for taking so long to reply. I'm a bit confused as the XML response
below contains D:collection/ which, IIRC, is the indicator being checked for
to indicate it is a folder. I can't see why that would turn into an ArrayList.
Can you provide the stack trace for the ClassCastException?
If Alfresco is returning a Collection for this property then I'm guessing it
will return Collections for all of them, which is also going to cause problems.
I think I'm going to have to download Alfresco and try it.
Ralph
On Sep 19, 2011, at 7:21 AM, Julián Cerviño Iglesia wrote:
Hi,
It's an ArrayList with 2 elements:
[0] Type: DeferredElementNSImpl - Value: [D:collection: null]
[1] Type: DeferredTextImpl - Value: [#text: \n ]
And the exception: java.util.ArrayList cannot be cast to org.w3c.dom.Node
I'm taking a look at the http conversation with WireShark and found that
first response it's a 401 (but user/pass are ok and it seems we are using
the correct JSESSIONID)...
PROPFIND /alfresco/webdav/test/1 HTTP/1.1
Depth: 0
User-Agent: Jakarta-Commons-VFS
Cache-control: no-cache
Cache-store: no-store
Pragma: no-cache
Expires: 0
Host: hostname
Cookie: $Version=0; JSESSIONID=CE4C1C3825257DD4E320EAF32B6F08C6;
$Path=/alfresco
Content-Length: 112
Content-Type: text/xml; charset=UTF-8
?xml version=1.0 encoding=UTF-8?D:propfind
xmlns:D=DAV:D:propD:resourcetype//D:prop/D:propfindHTTP/1.1 401
No Autorizado
Date: Mon, 19 Sep 2011 14:14:33 GMT
Server: Apache-Coyote/1.1
WWW-Authenticate: BASIC realm=Alfresco DAV Server
Via: 1.1 hostname
Content-Length: 0
Content-Type: text/plain
PROPFIND /alfresco/webdav/test/1 HTTP/1.1
Depth: 0
User-Agent: Jakarta-Commons-VFS
Cache-control: no-cache
Cache-store: no-store
Pragma: no-cache
Expires: 0
Content-Length: 112
Content-Type: text/xml; charset=UTF-8
Authorization: Basic eGlhbjpqdWwwNzk=
Host: hostname
Cookie: $Version=0; JSESSIONID=CE4C1C3825257DD4E320EAF32B6F08C6;
$Path=/alfresco
?xml version=1.0 encoding=UTF-8?D:propfind
xmlns:D=DAV:D:propD:resourcetype//D:prop/D:propfindHTTP/1.1 207
Multi-Estado
Date: Mon, 19 Sep 2011 14:14:33 GMT
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Via: 1.1 hostname
Vary: Accept-Encoding
Transfer-Encoding: chunked
155
?xml version=1.0 encoding=UTF-8?
D:multistatus xmlns:D=DAV:
D:response
D:href/alfresco/webdav/test/1//D:href
D:propstat
D:prop
D:resourcetype
D:collection//D:resourcetype
/D:prop
D:statusHTTP/1.1 200 OK/D:status
/D:propstat
/D:response
/D:multistatus
0
Thx
-Mensaje original-
De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Enviado el: lunes, 19 de septiembre de 2011 15:51
Para: Commons Users List
Asunto: Re: [vfs] webdav problem
An ArrayList containing what?
Ralph
On Sep 19, 2011, at 12:16 AM, Julián Cerviño Iglesia wrote:
Hi all,
I'm trying to use VFS2 to access a webdav server an replicate a folder
structure.
The problem is that the file system manager cannot determine the type of a
remote folder. I debugged the code and found that the root problem is a
Class Cast Exception in this method (class WebdavFileObject.java), somehow
property.getValue() is an ArrayList, and not a Node.
private boolean isDirectory(URLFileName name) throws IOException
{
try
{
DavProperty property = getProperty(name,
DavConstants.PROPERTY_RESOURCETYPE);
Node node;
-- if (property != null (node = (Node) property.getValue()) !=
null)
{
return
node.getLocalName().equals(DavConstants.XML_COLLECTION);
}
else
{
return false;
}
}
catch (FileNotFoundException fse)
{
throw new FileNotFolderException(name);
}
}
Webdav Server its an Alfresco Repository, and other operations work fine
(for example copy a file), so the connection seems ok.
Thx in advance,
Julian
-
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
