Gary Shea wrote:
Congrats on getting it rolled out... I'm still digging around, getting a feel for it. I haven't seen evidence yet of how to show block-to-block dependencies, but if there's javadoc for it, I'll find it no problem. Everything else I've looked at seems sensible enough...
Actually, you may find this a little harder than anticipated bacause
management of block level depedencies are not implemented yet.
Conceptually - consider the following:
1. component type declares static dependencies
2. component profile establishes a deployment template for the type
3. an appliance is the object that is established to handle
deployment of a component based on a supplied template and any
other supplimentary data the user provides
All of the above is handled in the avalon-sandbox/assembly package.
Now do a jump to the block concept. A block is equivalent to an
appliance except that it is managing a container heirachy (which is
component but needs special treatment during deployment).
Specifically:
1. a Container is a type of component
2. Block is a specialization of Appliance that manages
a container heirachy
3. a block exposes services and dependencies (like a Type does)
3. which means a Block basically bahaves as a dynamic Type and
displays appliance behaviour
Now I need to explain why I going into all of this detail - basically
a block exposes depedencies and services related to its implementation
(where the blocik implememntation is the containment heirachy). In
addition the block can exopose service and dependencies which are
basically the external contract of the block. For example, a block
may be composed of many related compoents and containers, however,
these components and containers are isolated within the block and
specific services and dependecies are exposed.
Depedency management is fully implementated at the component and
container levels. Bloc-level dependency management is not
implemented yet. For the time being this is not a problem as
containers do not typically expose dependencies. But it something
comming because its something I really need (some of my component
assemblies are simply getting too complicated and I need a composite
component deployment and packaging solution.
With the introduction of block level dependencies a containers will be
assembled based on the dependency ordering (as opposed to the current
physical ordering).
This approach means that it will be possible in the future to do
dynamic plugging in of complex system into an environment because
we only need to be concerned with the block level dependencies (all of
the container heirachy and component stuff is encapsualted and hidden
away).
I've just signed a couple of the jar files and I see what the problem is. The signing process adds name entries for each file (class, xml, whatever)Something that came up in connection with web start... that program is kind of pissing me off. Turns out that when jarsigner does its thing, it only attaches sig info (the md5 digest I suppose) to the Name: sections that are associated with files. WebStart insists that every single Name: section be signed, or it considers the jar incorrectly signed and won't load it. So any required entries in the manifest that do not directly correspond to a file automatically break Web Start. I submitted a bug report, but Web Start releases are only every six months to a year. There are open source implementations but they aren't very complete. Urk.
in the jar file together with the digest for that class file. If WebStart
is requiring that every Name: entry has a corresponding digist - then we
are in trouble.
The purpose of the Avalon-Block is to mark the jar file as a file to be
scanned for component type defintions. This ensures that we are not
wasting time scanning jar files that don't have components defined. An
alternative approach to the manifest entry would be to simply look for a
blocks.xml resource and if that exists - we know we need to scan the jar
for type and service defintions. This could actually be an improvement
because it means that we would no longer need to worry about
supplimentary manifest entries (but it would mandate the requirement for
a block.xml within the jar file).
Would that solve the problem?
Cheers, Steve.
So anyway, the obvious question, is the Avalon-Block header needed? It occurs to me that I can simply create a file called Avalon-Block!!! Urk... Gary
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
