Berin Loritsch wrote:
In order to solve "model" issues much easier and much more flexibly,
What "model" issues are your referring to?
Sometimes new features need new meta info to help fine tune those features. For instance, dynamic generation of intrumentation points, or JMX control points. It would be easier to handle these with a less strict meta model than the one under the Meta system.
I also do view and always have viewed the keeping of the meta info in separate files from the class as a weakness in the system. I have worked with too many third party classloaders that were broken to make that not work. Not to mention the serialized meta info would be broken if passed between different JVMs.
Keep in mind that the Avalon Meta package is about meta-info associated with component types and service definitions. There are no issues with this that I am aware of. Certainly nothing has been posted to the list on this subject.
Only that the storage in XML is not a good thing and the inflexibility of that model stifles innovation without breaking the system.
I propose to use the work that Leo did a while back with the Attributes embedded in the class file itself. It is a much more flexible way of doing things which will not require future
modifications to the meta model to take care of enhancements.
The only enhancement I am aware of is the discussion concerning code security. That could be easily addresses under the current approach by extending the definition without breaking any existing component meta-info definitions.
It is a refactoring primarily, which will allow for more creative solutions in the future. The current model and way of accessing it is not very friendly to incorporating into any other existing container (AKA Fortress). These are true concerns.
Can we go back to the underlying reason for the proposal, and secondly, how the proposal will ensure that existing XML and serial representations are supported.
The current meta package would have to be kept for a while until all have migrated to the newer format. The actual objects created and accessed by Merlin would be consistent with the new attribute system, but we would have to maintain the current XML representations. The serial representations are problematic for other JVM and classloader reasons.
The main thing is to migrate from rigid to firm. This will also help us prepare for the migration to JDK 1.5 when it comes.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
