Gary Shea wrote:
I suspect my comment about block level dependencies is a red herring...Not necessarily.
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.
A block can declare a classpath and as such its declaring dpendecies on a set of related jar files. The assembly engine will take care of scanning these jar files automatrically. So basically - a single block is very similar to the 2.0 version - i.e. a container heirachy, multiple components, multiple jar files, possibility to include container specific extension directories, etc.
In you case I would suggest packaging your content as a single block (as per the prev model).
My guess is that if I inform merlin about the two blocks in blocks.xml,Service publication from a block is in place but service propergation across blocks is not. This still needs more work on the URL model for service references and some stuff related to the assembly strategy. Once that's in place - then yes - block level interconnection will be possible.
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
Update you manifest to: Name: Avalon-Block Block-Package: org.whatever I've also updated the source so that Block-Name works as well.
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 ;)
I imagine :-) Either updating sources from CVS or changing the manifest to Block-Package will fix this.
It's possible - all we need is something in the block.xml file that tells the system where to read the information form. The default can be the block.xml file but this can easily be updated to read from an external source. There is code to do this sort of thing when handling configurations so its much more a case of cut and paste.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.
Refer - DefaultKernel.getBlockConfiguration( JarFile jar )
Normally the block.xml would look like this:
<block>
<services>
<service type="org.apache.avalon.playground.StandardService:1.1" />
</services>
<implementation>
<container name="test">
<appliance name="standard"
class="org.apache.avalon.playground.StandardComponent"
activation="startup">
<context class="org.apache.avalon.playground.StandardContextImp"/>
</appliance>
</container>
</implementation>
</block>
This could be updated to include support for a reference to an external file.
<block>
<implementation src="my-external-implementation-file.xml" />
</block>
I agree that this would be helpful during development.
Cheers, Steve.
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 aActually, you may find this a little harder than anticipated bacause
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...
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 isI've just signed a couple of the jar files and I see what the problem 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.
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]>
