Jean-Sebastien Delfino wrote:
Pete Robbins wrote:
Yes it does help! I need to go and read the Assembly spec again ;0)
But for now I think the change I put in is fine.
Cheers,
Pete,
I thought that your change was OK too, but I just rebuilt everything
after updating from SVN and unfortunately this change breaks the Ruby
extension. Sorry I should have detected this before... but line 75 of
RubyImplementation.cpp needs the root directory of the composite to
find the Ruby script, as most people will specify a path to the script
file relative to the .composite file in <implementation.ruby
script="..."/>.
The Ruby extension hits what I was trying to describe earlier in this
thread. Implementation artifacts are packaged with the composite, so
they need to know which composite they are packaged in, the current
directory etc. The Python and PHP extensions probably do not run into
this because they don't look at the script until the first invoke (and
are passed the composite at that point), but they will run into this
as soon as they try to read and introspect a script earlier in the
load sequence.
So right now the Ruby extension is broken by this change. To build on
Linux without it, use configure --enable-ruby=no.
Pete,
I tried to find a work around for this problem - so that you wouldn't
have to revert some of these changes :) and avoid loading the script
up-front, but then realized that I really need to, to introspect it and
derive the services and references that will be presented to the other
components in the composite for wiring for example. This is way before
the first invocation comes or the first ServiceWrapper gets created.
Also we can have multiple ServiceWrappers for a single Implementation
object and we should load the script only once per Implementation, so
I'll recommend that the Python and PHP extension load their scripts as
well in the Implementation instead of the ServiceWrapper (but this can
wait, we don't need to change that right now).
So I don't see any easy way around this... If the other people are OK
with that I can live without the Ruby extension for some time until you
get to it or we find another solution, but I'm afraid we're going to
have to put this Composite* back...
Thanks,
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
