Pete Robbins wrote:
Our current method of packaging and loading an extension is fairly
simple:
we load all schema and libraries in the extensions path. This has a
number
of problems.
1. An extension may consist of more than one library e.g.
libmy_extension.so
and libmy_extension_utils.so. Our current loading scheme will attempt to
load both of these and may fail on the one that doesn't provide the
extension initialize method. On MacOS the output of our build produces a
libx.dylib and a series of symlinks to this called libx.0.dylib,
libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause
problems as they are all the sam library and just repeatedly register to
handle the same requests. Very inefficient though!
2. Control of whether or not to load an extension library is currently by
renaming the library so the runtime doesn't find it. An example is
that we
ship our python extension as libtuscany_sca_python.so.diabled. This is
horrible and error prone.
We could improve this by having a system configuration file that lists
the
required extensions but the I like the self contained package approach
that
we have now. I'd like to implement an improved scheme for packaging an
extension by introducing a per extension configuration file. Something
like:
tuscany_sca_ws_binding.extension
<scacpp:extension name="ws binding" enabled="true">
<library name="tuscany_sca_ws_reference"/>
<library name="tuscany_sca_ws_service"/>
</scacppp:extension>
So the package would look like:
extensions/
ws/
tusany_sca_ws_binding.extension
lib/
xsd/
other_folder/
...
The .extension configuration file is saying to load the library which is
located somewhere in the package... the runtime will find it... no
need to
specify a path.
Taking this further the configuration file could list the schema to be
loaded. Currently the runtime will just load any it finds but these
may not
be needed by the runtime e.g. the schema may be for some extension
implementation specific purpose.
I think it would also be good for the extension initialization()
method to
take as a parameter the root of the extension e.g.
extension("/tuscany/extensions/ws"). This would allow the extension
package
to contain any configuration information that it needs.
I'd like to start by at least introducing the .extension file for each
extension and loading only the specified library(ies) if the extension is
enabled.
Any thoughts?
Two thoughts:
- convention over configuration
- the runtime should be consumable without having to go tweak XML
configuration files
If I remember correctly, renaming the dlls to .disabled was a last
minute change to work around DLL loading errors with our M2 release on
Windows.
I agree that we should do better than renaming to .disabled, but I'd
like to understand better the actual issues that we faced before
inventing yet another XML based runtime configuration language :)
I'm aware of the following issues:
1. We need the runtime to load extension libs only, not other libs under
the extension directory which are not actual extensions
2. Same for XSDs, we need to load XSDs that contribute to SCDL, and
leave other XSDs under the extension directory alone
3. Extensions that cannot be loaded because some of their dependencies
are not there should no break the runtime
4. The system admin / installer should be able to disable extensions
that won't load because their dependencies are not there (I'm not yet
convinced that this is still an issue if we manage to solve issue #3)
Did we run into any other big issues?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
