You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2004/01/07 15:10:33 UTC
Rationalization (was [RT] Changing Meta Package)
I thought my original email had rationalizations and what good I had hoped to
gain by changing the Meta package. However, it seems that I was not successful
in communicating that yesterday. A couple of you got hostile and assumed I had
no rationalization simply because I did not have the time to spell it out for
you completely ad nauseum. That is what this email is for.
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.
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.
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.
Reloading the JARs just to scan them would be bad--esp. if you did not know
where those JARs were.
Lastly, the XML panaceia syndrome. XML is a great tool for certain situations,
but not for all. In the situation where we are recording meta info for
components, the XML is verbose, and the parsing and generating overhead adds
up. I suppose one could argue that the serialization solution is one way around
it, but that will run into problems reading meta info generated from one JVM
into another.
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. Quite frankly the number of assumptions in the
package, and the inflexibility of it to do ad hoc attributes of any deliniation
(like @jmx.bean or @instrument name=foo) leads me to the conclusion that it is
a special purpose library for a special purpose solution, and not the general
solution it is touted for.
Why use Leo's Attributes Package?
---------------------------------
Leo's Attributes package is a much easier integration into any system. It
does not require many different resource files like the Fortress and Merlin
solutions do. It is neatly contained, and automatically handles any attribute
without question or special coding to make it work. If I want a model for
new attributes that are no where close to what the Meta package offers, I would
have to make non-trivial code changes with impact on a number of systems.
Do I have specific examples of arbitrary attributes at this time? Not yet,
but I do have a general idea of where I would want to use them. The thing is
that inflexibility causes more long term harm than good. Rather than creating
an environment that is as inflexible as a fascist, creating a system that deals
with change provides better robustness.
My suggestion is not only for the current needs of integrating with Fortress,
but for the future needs that *will* arise. In fact, it very well may help
make these feature requests from JAMES and company easier to work with.
--
"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
Re: Rationalization
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Rationalization
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: Rationalization
Posted by Stephen McConnell <mc...@apache.org>.
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?
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org