avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Rationalization
Date Wed, 07 Jan 2004 17:20:09 GMT
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.

>> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message