I am not sure that I understood an important detail of your description above:
do you load features using the load/unload feature menu entry in tools OR
do you add config maps describing features as prerequisite configuration maps in you own configuration maps and then do you load them using the configuration map browser?
The later, I fear, won't work.
Feature load from the tool menu does more than loading configuration maps (and prerequisites) out of the configuration map browser.
It is likely that you are missing s.th. doing so. Feature load was provided by ABT (Vast IBM) and configuration load was provided by Envy (OTI).
Feature load is based loading maps, but it does more... (particularly in XD packaging).
I start out to load all required features first in an image (which may be stored aside for later to save time) and then to load my stuff (organized in configuration maps).
My configuration maps never had prerequisite references to features (to avoid potential losses).
And I inspected your example
'...' sstAsUrl fetch
sstAsUrl (of SstUrl) cracks the string and looks up for the scheme to dispatch to the right parser. Here it instantiates the url in the string as instance of SstHttpUrl.
Otherwise it will fail (SstUrl instances do not understand fetch).
Check if
('...' sstAsUrl) isKindOf: SstHttpUrl
is true at run time. It is not, then the Sst registry of schemes, parsers, transport, ... is broken.
Reasons of broken registry are missing execution of loaded, startUp, initialize methods in the packaged image or that loaded structures (of the development image) are not copied properly over to the runtime image.
Later practice was very useful for fast startups of runtime images - but heavily restricted in XD images (only simply objects like strings, numbers, symbols etc. may be copied into a XD runtime image). Using XD required significant preparation not to lose s.th. when packaging.
I assume that you use XD to package a Linux Image under Windows to be
run on the Raspberry.
In that case I assume that you are aware about the XD image restrictions.
Marcus
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2ad19f53-e190-4d7f-83be-d59e77464c0fn%40googlegroups.com.
When working on the CI building system for smalltalk, we tried using ‘just config maps’ to bootstrap XD images for builds and packaging, but XD features do differ from config maps in 3 ways - main/development image features are very similar to a config map, but XD features are not.
The contents of an XD Feature are defined by a config map, but
1. The feature will hunt for the appropriate version of the config map as already noted. As most application versions are tied to a specific VAST version, tying to a specific z config map version is not all that problematic.
2. The feature can set settings into the image. Specifically for SST it sets a subsystem value.
3. The feature loader is different to the config map loader in that the config map loader loads applications and required maps in a fixed order as defined by the maps. The feature loader builds a list of applications to load using the content of the config map it links to, but does not use the order in the config maps. It re-orders the load of applications based on a dependency analysis.
More technically XD Features are objects which are subclasses of AbtAbstractXDFeature. These can do more than what a config map can do. For example, AbtSstFeature>>#subsystemTypesFor: adds extra sub-systems to the image when you load the XD SST feature. You cannot do that via a loading a config map alone.
Basically, the loading of the 'Server Smalltalk Framework (SST)' XD feature into an UNIX XD image is equivalent to doing the following steps:
- Adding an SCI: UNIX subsystem
- Loading the zz.Server.Hidden.AbtSstHiddenFeature config map
- Loading the zz.Server.SstFeature config map
You can look at https://github.com/instantiations/ci-examples-vast/blob/master/scripts/abt.cnf#L141 for where the seaside example application loads the seaside feature into UNIX XD image.
For my application, which uses SST HTTP we have to do the following instead
installFeatures
add: (Smalltalk classAt: 'AbtSstFeature' asSymbol) new;
add: (Smalltalk classAt: 'AbtSstWebFeature' asSymbol) new;
add: (Smalltalk classAt: 'AbtWebConnFeature' asSymbol) new.
If you just load the config map manually into the XD image, the correct subsystems won’t be set, and the application will spit out all sorts of cryptic errors as the bits needed by the relevant sub-systems won’t be included in the package.
From: va-sma...@googlegroups.com <va-sma...@googlegroups.com>
On Behalf Of Joachim Tuchel
Sent: Friday, 5 February 2021 05:54
To: VA Smalltalk <va-sma...@googlegroups.com>
Subject: Re: Packaging problem
EXTERNAL: Do not click links or open attachments if you do not recognize the sender.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/89c2128b-df62-4d99-86b4-fe19d0bbd5fen%40googlegroups.com.