Berin Loritsch wrote:
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?
I just detailed one of them.
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.
Again, more reasons not to like what I am *forced* to accept with the Meta package. BTW, I heard that Java just released and Alpha version of JDK 1.5...
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.
However, there is no out of box support to do what Fortress already does-- without the need to scan JAR files or build in a whole lot more infrastructure.
You see the problem? I have to do a whole lot more work than I think I should just to adop the Meta package. To me that is a design smell (to use XP terminology). Compare that with Leo's attribute package, and you will find that the attribute package is a lot simpler to adapt to Fortress than the meta package. That is a problem.
The thing is when a library is so difficult to integrate with existing work, it is not a good candidate for a library. It is truly part and parsel to Merlin and its tools.
Now, using the Attributes package as a simpler sub layer will make both Fortress and Merlin happy as far as consistently declared meta info and the ability to add whatever infrastructure on top your heart desires.
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?
I already have one which I use. However, such things are not standard to the system, and I cannot rely on all JARs with components to include this list if I adopt the Meta package. See the conundrum? I have a lot of work to do for very little gain if I am going to use the Meta package. It is not convenient or time saving in the long run IMO.
--
"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]
