On 30/11/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 30/11/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> 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?
No, that's about it.
2. XSD loading can be done by convention (schemas for the runtime are
always in a folder called 'xsd'
1. Could be solved in a similar way by only loading libraries in a folder
called ???
3. Can be solved by just ignoring the load errors/issuing a warning rather
than giving up
4. Can be solved by solution to 3.
I recall now why 3. was a big problem. Windows sometimes throws up an error
dialog when the load fails so it was not just a case of the runtime handling
the load failure so we had to "disable" the extension.
Cheers,
--
Pete
--
Pete
