I suspect my comment about block level dependencies is a red herring...
I have two jars that contain components. One contains only the
XML:DB-related code, consisting of exactly one component (an
XMLDBConnection). The other jar contains the rest of the (primarily
singleton) components in the app.
If I understand things correctly, this means I have two blocks.
My guess is that if I inform merlin about the two blocks in blocks.xml,
that'll take care of the application block finding the XMLDBConnection
components from the XML:DB block.
So, I have blocks.xml which enumerates the two blocks. I have added
BLOCK-INF/block.xml files to both jars.
No service
in the app block is used outside that block, so I've left the
<services/> section empty. The XML:DB block.xml exports the
XMLDBConnection service. The body of the app block is basically the
merlin2 kernel.xml stuff between the <container></container> tags, with
the XMLDBConnection component removed to the XML:DB block.
The two jars both have Avalon-Block entries with Block-Name: fields,
but I haven't figured out yet where those values get used.
At the moment I'm getting:
java.lang.IllegalArgumentException: Missing package declaration in
block: file:/home/shea/work/proj/mfg/head/ft/tmp/m21/order.jar
at the very beginning of the 'Block installation phase'.
I'm a bit concerned at this point, because I have a half-dozen
different packages containing components in the app jar file!
I wouldn't object to a hint at this point ;)
Gary
p.s. I'm kinda bummed about having to put the former content of the
kernel.xml inside the jar file in block.xml, because I _loved_ having
kernel.xml sitting out in the filesystem where I could tweak it without
having to get ant involved.
On Tue, 7 Jan 2003, at 02:38 [+0100], Stephen McConnell ([EMAIL PROTECTED]:
>
>
> 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).
>
> >
> >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.
> >
>
> 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)
> 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]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
