This can be usefull for servlets too. They store URI property as an attribute of
FileObject.

Target milestone -> 3.3.1.

This is already true of localization-related attrs, template-related
attrs, ... currently all these are hardcoded in FileUtil.

It should be extended by idea of attribute's TTL. We need attributes
that are invalidated by move and TTL period expiration. 

Well, it is only optimalization allowing to "garbage collect"
attributes that were not accessed for long time and can be
reconstructed by module (e.g. prompting the user).

The problem is that we need to find a declarative solution. Our goal
is to not execute anything when a module is started. Methods like this
one seem to encourage people to execute a code at the startup and thus
load some module classes into VM. 

That is why the suggested method is not suitable solution. Please find
some declarative one.

You may be right, but declare transient attributes in layers is also
not right solution because filesystems should be standalone. Then new
set of methods (copy, move) on FileObject could be introduced, which
would allow to pass set of transient attributes. I suggest not to
duplicate support methods in FileUtil (copy,2x copyFile, moveFile).

The problem is, that the object, that calls copy usually do not know
about transient attributes. The owner of the attribute should be able
to specify whether the attribute will be transient or not.

OK method copy, move with set of tranisent attributes has mentioned
drawback that FileObject is
often widely reachable and then another code may copy such attributes.
Perhaps better would be to have possibility to setAttribute with a
flag transient, but that means that filesystem.dtd would need to be
changed.

The code does not know about transient attributes? So why is the code
copying the fileobject? I believe one should know what is doing...

The same argument can be used in oposite way - by specifying the
attributes in global way one forbids somebody else to copy attribute
that could be copied.

There was no reply to last comment (Jaroslav Tulach 2002-03-12 08:57
PST). Then will be implemented soon according to comment (Radek Matous
2002-03-12 08:08 PST) as long as any new objections don`t appear.

If you mean

"Then new set of methods (copy, move) on FileObject could be
introduced, which would allow to pass set of transient attributes."

then I don't really agree; see Martin's comment: the copy doing
copying (e.g. FileEntry.handleCopy) cannot be expected to know about
various attributes supplied by modules which should be transient. So I
think passing an explicit list of attributes would not help in most
situations.

To Yarda: using FileUtil.copyFile you get the normal behavior of
copying only nontransient attrs. If you really know for sure that you
want to copy all attrs (or specific ones), nothing is stopping you
from doing so, without using FileUtil at all. But I think it would be
less common.

I do sort of like the idea of marking an attr transient when it is
set. However as you say a 1.2 XMLFS DTD would be needed to make it
possible to do this declaratively too. (Also a new .nbattrs DTD to
match - BTW shouldn't this DTD import the XMLFS DTD to reuse it?)

Maybe should be taken to dev@openide since there does not seem to be
consensus.

Thanx for your reply Jesse. I would also prefer the idea of marking an
attr transient when it is set .

To Yarda last comment: In this case owner is the one who sets
attributes and owner should be the one who controls access and decides
if copy or not.

I took it to dev@openide on friday   (aware of the fact that there is
not agreement)and I got no response. BTW.: I think that all interested
people are registered in IZ and interest seems to be limited. So,
before impl. I would really like to hear opinions and preferences (we
do not need useless API changes). 

I would also like to have the option to set the transitivity of the
attribute when setting the attribute itself. Otherwise it's of no use
to me. The generic copy action can not know about "my transient
attributes". I like the Radek's solution.

Implemented (but not yet commited). Transitivity is set when setting
the attribute itself according to last comments. I did  a little
change, because I avoided to introduce new method and change API.
So,instead of method: setAttribute (attrName, value, isTransient) can
be used current setAttribute ("transient:"+attrName,value). Diff will
be attched.

Created attachment 5424 [details]
Impl. of transient attributes - diff

Fixed in trunk according to diff in attachement.

DefaultAttributes.java
new revision: 1.58; previous revision: 1.57

FileUtil.java
new revision: 1.58; previous revision: 1.57

XMLMapAttr.java
new revision: 1.31; previous revision: 1.30

Please update Javadoc for FileObject.{get,set}Attribute and also
AbstractFileSystem.Attr.* to mention the change. 

Question: if you do

fo.setAttribute("transient:foo", "bar")

then is it true that

fo.getAttribute("foo").equals("bar")

?

Also apichanges.xml should mention it, so there should ideally be a
new spec version too.

Yes, fo.getAttribute("foo").equals("bar") == true
 
I`m ready to document it, consider it as API change and keep back
compatibility. Any objections (before I do it)?

verified

Resolved for 3.4.x or earlier, no new info since then -> closing.