Stephen McConnell wrote:
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.
Have you tried using attributes which are part of the model definition. On those occasions where I need supplementary info I just add a single attribute which I use to flag a component as having additional collocated info. Using this approach I can basically do what I want without breaking any apis or serial forms.
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.
Can you point me to some concrete examples where third party classloaders cannot access resources in a jar file? It's not a problem I'm seeing. In fact I would be really surprised if this was a real problem as it would negate just about any real application out there.
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.
So what we are actually talking about is the XML format (and the related internalization and externalization processes)? If extensibility of the XML format is the issue - then that something that can be addressed without breaking the existing format - but that's not the same as what your proposing.
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.
Have you experimented with the declaration of attributes using the existing meta info model?
http://avalon.apache.org/meta/meta/info/attributes/index.html
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.
No. I didn't ask for the ramifications .. I just asked you what your underlying reasons were. Presumably you are trying to do *something* and its not easy to do.
What is that *something*?
Stephen.
-- |------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
