What is the primary problem? ----------------------------
The primary problem came from trying to integrate the package into Fortress so that we can use the same meta info in both Fortress and Merlin.
It became painfully obvious to me that the certain divisions in the system seemed artificial and broken. How many different applications will actually use the meta info? Containers and tools. That's about it. Yet the model is separated from the writers and the readers--which both the containers and tools will need to work with the system.
Can you detail the divisions that in your opinion are artificial and broken?
Secondly, in order to support the Fortress meta info reading the package needs to be altered because it assumes one file to one component.
In Fortress the meta info is split between two files --one for component
info and one for dependencies. There was no simple way to change that.
If you moving to Avalon Meta then that means supporting the Avalon Meta file formats (XML and serial). The meta file are what enable tools and containers to read the component type and service information into a container independent way (via the Type instance).
If you looking at the migration question - then yes, you would need to roll a class together that reads in Fortress meta info and from that generates a Type instance (e.g. FortressTypeCreator implementing the TypeCreator interface included under the spi package). You can then use existing facilities to write that instance out in a serialized or XML format.
Thirdly, in order to maintain the ability to automatically assertain which components were available to Fortress, I would have to have Fortress load the JAR files and scan them for the meta info. Fortress was originally designed to work in situations where
the JAR files were already loaded into classloaders.
Locating meta-info is a container concern. Scanning a jar file is one approach but you could also push this in meta-data. Different approaches have different advantages and disadvantages - scanning has the benefit of supporting the dynamic addition of jar files to a running system and reduces the amount of container specific meta-data.
Lastly, the XML panaceia syndrome.
<snip/>
The conclusion is that there is no easy way to incorporate the meta package into anything besides Merlin where it makes all the assumptions that make the package a decent solution for it.
It seems to me you really have one issue to deal with (based on what you describe in your rationalization) and that's the question of "how to map service class names to component type descriptors in Fortress". If you don't want scan then why don't you just create an ant task to generate the list?
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]
