Mario Ivankovits wrote:
Philippe Poulard wrote:
Resource getResource() throws FileSystemException, XMLDBException {
boolean isXML = true;
Collection coll = DatabaseManager.getCollection(
XMLDBFileObject.this.getParent().getName().getURI()
);
for ( Iterator it =
XMLDBFileObject.this.getContent().getAttributes().entrySet().iterator()
; it.hasNext() ; ) {
/*
* getAttributes() fails here because the type
* is FileType.IMAGINARY : it has been set when
* delete() has been called
So the problem is that imaginray files are not allowed to have attributes.
Why not simply avoid the loop over the attributes if the file is of type
IMAGINARY?
i need these attributes to create the file : XML:DB oblige to indicate
if a file is XML or binary ; other attributes may also be required
according to the provider ; so, if IMAGINARY was a type that would
accept attributes, all would work fine
thus when i perform a copy, i know that the target is intending to be a
FILE, so i could use attributes ; but if it has been previously deleted
and marked IMAGINARY, its attributes are kept but can't be used
i don't know why IMAGINARY files can't have attributes ; if the file
system is said that attributes are supported, why blocking their usage
with the type ??? it's not fair !
a smart solution for me is to override the method that checks the type
and throws an exception, but i'd prefer a change on the IMAGINARY type
I also do not fully understandy why it works if you call close() after
delete() - during the attach() the file should still be IMAGINARY as it
is deleted.
Might it be that your FileObject.doGetType() do not correctly report the
type of the file?
right : if it is not a FOLDER, it is a FILE ; that's why it works
i will fix it...
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
