commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject [attributes] Limitations of current implementations
Date Tue, 17 Jun 2003 23:04:52 GMT
Hello,

I have been investigating commons-attributes for use with XML-RPC, 
specifically to denote which methods on a given class should be exposed 
via an XML-RPC server.  I have done some reading on the web about 
metadata, including JSR175.

I would like to get feedback from some more experienced developers about 
some implementation decisions.  In particular, both attrib4j and 
commons-attributes make the following assumptions:
- There is one set of metadata for a given language structure
- An attribute set and the attribute values are immutable

These assumptions seem to be unnecessary and they limit what can be 
accomplished using metadata.  I could not find language addressing them 
in JSR175.

First, the assumption that there is only one set of metadata for a given 
language structure is already more restrictive than the current usage of 
deployment descriptors in J2EE.  A class might have separate types of 
metadata for different runtime or deployment time usage.  Attributes 
used for EJB code generation might be better kept separate from 
attributes for persistence, security, RPC, and other concerns.

Second, I do not understand the need for an attribute to remain constant 
for a particular version of a class.  Some attributes might be better 
defined by the application deployer than by the class programmer.  
Future users of the class might want to assign additional attributes to 
language structures that were not foreseen by the programmer.  A 
container might be able to leverage a facility for runtime attribute 
modification in order to perform its duties.

If anyone can shed some light on these issues, I would greatly 
appreciate it.

Thanks,
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message