Stephen McConnell wrote:
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.
You mean the separation of writers and readers? If that is you concern then think about the fact that you don't need a Fortress writer, you just need a reader to convert current Fortress meta into a standard Type and Service instances. If that separation is bugging you perhaps you could explain why it is bugging you?
To be clear - I do not see the problems you are alluding to.
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.
Getting in place a reader is something you can do on a Sunday afternoon.
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.
Like I said before - scanning is one option, you have already said its not an option, so stick with approach of harvesting this information at build time.
You see the problem? I have to do a whole lot more work than I think I should just to adop the Meta package.
What your saying is that you have to reimplement some things so that you work against a common API. Yes - you need to make some changes - but the changes are not "big" - certainly not as big as your implying.
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 Avalon Meta package is the defining what it is to be a component. Yes - it is strict with respect to the explicitness of the information it provides. I sure would not want a woolly type definition But this is orthogonal to an implementation approach.
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.
With all due respect, IMHO - your conclusion is grossly incorrect.
If you really believe that Avalon Meta does not let you do what your want to do, then go ahead, branch, get something working, demonstrate its API and SPI compliance and then post a note explain why its a good idea to migrate from the released package. In the meantime the programmatic evolution of meta as the strict contract definition can proceed without disruption. However, I would suggest that you could get what you want much faster using what is there.
Have you considered using the attribute fields available on <info>, <context>, <service>, <dependency>, <extension>, <stage> and <category>? This provides more than enough to do the things your doing in Fortress today ... all your doing is moving from a Fortress specific format to a standard format.
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.
No problem - so long as the implementation does not break the API and the implementation itself delivers sufficient added value over and above what we have - but that's a subject for the future when you have something demonstratable.
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 understand the problem.
Effectively Fortress is not managing the class loading environment and as such does not have access to the information about available components. As such, Fortress users are forced to use a container specific build time process to generate supplementary info in order to deploy under Fortress. But this is not a issue with the meta package - this is a issue with Fortress.
As things stand Fortress generates a list of candidate component implementation class names keyed by service interface class name at build time. Why don't you add these references to the meta-info generated as part of a service definition (using the existing package)? This would let you key of a service request (via interface class name), load the service descriptor, then load a list of candidates via service descriptor attributes./
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]
