Jack Woehr wrote:
Steve Loughran wrote:
Even if you could retro-fit every task out there with getters,
-what about overloaded set operatons? which one should the get return?
-what about property assignments. Tasks get their setters with
properties expanded.
also there is the issue of addXXX things; that is, nested elements.
Hmm. Ah, well. Writing out the project seems to be a fairly obvious
functionality in comparison
to some of the exotic functionality of Ant. I guess it's just one of
those things which in hindsight
the design should have accomodated, but which are difficult to retrofit
given that the design
did not so accomodate.
Maybe it depends what you want to write things out for. It isnt normal
'build process' stuff, and the more you add to the requirements of a
task, the harder it is for a task to be implemented,
In smartfrog, the deployment descriptors do get marshalled across the
network, so there is a model of the configuration graph that is separate
from the state of the components that deploy the different things on the
graph. But this is done at the expense of introspective binding to
setters; you need to explicitly get things, here getting some options
with the default false and a required flag of false (i.e. optional).
mustExist = getBool(ATTR_MUST_EXIST, false, false);
mustRead = getBool(ATTR_MUST_WRITE, false, false);
mustWrite = getBool(ATTR_MUST_READ, false, false);
mustBeDir = getBool(ATTR_MUST_BE_DIR, false, false);
mustBeFile = getBool(ATTR_MUST_BE_FILE, false, false);
testOnStartup = getBool(ATTR_TEST_ON_STARTUP, false, false);
testOnLiveness = getBool(ATTR_TEST_ON_LIVENESS, false, false);
In this bit of the fileimpl class, I then set more attributes describing
file state:, after probing the full path/state of the file, namely the
absolutePath and uri attributes, plus some boolean values
String
absolutePath=FileSystem.lookupAbsolutePath(this,ATTR_FILENAME,
defval,null, true,null);
File newfile=new File(absolutePath);
sfReplaceAttribute(ATTR_ABSOLUTE_PATH, newfile.getAbsolutePath());
String uri;
uri = newfile.toURI().toString();
sfReplaceAttribute(ATTR_URI, uri);
setAttribute(ATTR_EXISTS, exists);
setAttribute(ATTR_IS_DIRECTORY, isDirectory);
setAttribute(ATTR_IS_FILE, isFile);
setAttribute(ATTR_IS_EMPTY, isEmpty);
setAttribute(ATTR_IS_HIDDEN, isHidden);
setAttribute(ATTR_TIMESTAMP, timestamp);
setAttribute(ATTR_LENGTH, length);
String name = getFile().getName();
setAttribute(ATTR_SHORTNAME, name);
This is cool, as then other things can be deployed that are bound at
runtime to the absolute values of things, even things deployed on
different boxes. But this was (a) designed from the outset, (b)
increases some of the complexity of binding to the system and (c) also
drops out early-binding cross-references, things that are resolved
during the parse phase. Which is what you need when you want to sign a
descriptor as secure before you send it to someone - late binding
information is more of a security risk, as the things you bind to may be
less secure.
note also that the security person always complains if we set attributes
to things that arent serializable. Really the signature of the attribute
set/replace operations should be (String, Serializable), not (String,
Object).
A weakness of this approach is that after something is deployed, its
state isnt always updated, so there is no way to change a deployed
component except by undeploying/redeploying it. Ant lets you set
different attributes and call execute() again.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
