[Bug 546] New: Deployer programs can not specify component path for plugin search

For more infomation about this bug, visit
Summary: Deployer programs can not specify component path for
plugin search
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Deployment
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

The deployment component has a property to specify the component path, which
provides additional directories to search for components. Unfortunately, the
deployer programs do not use a property file to configure the deployer
component instance. The result is that plugins (eg the KDL toolkit) can't be
found if you are using a non-standard install directory.

Could we simply mod the deployer's to use an optional property file?

[Bug 546] Deployer programs can not specify component path for p

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=546

--- Comment #11 from Peter Soetens <peter [..] ...> 2009-05-23 14:24:58 ---
(In reply to comment #7)
> Can't we use the program-options of the deployer to give the component-path, i
> have a local patch that does it. I'll attach it. Maybe we should extend the
> deployer to work with a list of path's instead of only one path. Since my
> components are all over the place.

Yes. Just like PATH, LIBRARY_PATH, CLASSPATH etc, a list of paths should be
accepted as well, double colon or semicolon separated (I would accept both).

Peter

Ruben Smits's picture

[Bug 546] Deployer programs can not specify component path for p

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=546

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #430 is|0 |1
obsolete| |

--- Comment #10 from Ruben Smits <ruben [dot] smits [..] ...> 2009-05-23 00:02:30 ---
Created an attachment (id=431)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=431)
adds path option to the deployer and deployer-corba

fixes typo in previous patch: attachment 430

Ruben Smits's picture

[Bug 546] Deployer programs can not specify component path for p

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=546

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #429 is|0 |1
obsolete| |

--- Comment #9 from Ruben Smits <ruben [dot] smits [..] ...> 2009-05-22 23:56:44 ---
Created an attachment (id=430)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=430)
adds path option to the deployer and deployer-corba

Ruben Smits's picture

[Bug 546] Deployer programs can not specify component path for p

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=546

--- Comment #8 from Ruben Smits <ruben [dot] smits [..] ...> 2009-05-22 23:54:31 ---
Created an attachment (id=429)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=429)
adds path option to the deployer

Ruben Smits's picture

[Bug 546] Deployer programs can not specify component path for p

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=546

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |ruben [dot] smits [..] ...en.b
| |e

--- Comment #7 from Ruben Smits <ruben [dot] smits [..] ...> 2009-05-22 23:51:57 ---
Can't we use the program-options of the deployer to give the component-path, i
have a local patch that does it. I'll attach it. Maybe we should extend the
deployer to work with a list of path's instead of only one path. Since my
components are all over the place.

Ruben

(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=288)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=288) [details] [details]
> > Add "Include" property, similar to import, but for xml files.
>
> Applied on trunk/ocl:
> $ svn ci doc deployment -m"Fix part of bug #546: Deployer programs can not
> specify component path for plugin search
> > Adds the "Include" directive.
> > "
> Sending deployment/DeploymentComponent.cpp
> Sending deployment/tests/deployment.cpf
> Sending doc/xml/orocos-deployment.xml
> Transmitting file data ...
> Committed revision 29282.
>
> I'm not sure if there is use leaving this report open. I'm still unsure about a
> good 'PATH' solution.

[Bug 546] Deployer programs can not specify component path for p

For more infomation about this bug, visit

--- Comment #6 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-05-14 22:31:24 ---
(In reply to comment #5)
> Created an attachment (id=288)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=288) [details]
> Add "Include" property, similar to import, but for xml files.

Applied on trunk/ocl:
$ svn ci doc deployment -m"Fix part of bug #546: Deployer programs can not
specify component path for plugin search
> Adds the "Include" directive.
> "
Sending deployment/DeploymentComponent.cpp
Sending deployment/tests/deployment.cpf
Sending doc/xml/orocos-deployment.xml
Transmitting file data ...
Committed revision 29282.

I'm not sure if there is use leaving this report open. I'm still unsure about a
good 'PATH' solution.

[Bug 546] Deployer programs can not specify component path for p

For more infomation about this bug, visit

--- Comment #5 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-05-13 22:36:08 ---
Created an attachment (id=288)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=288)
Add "Include" property, similar to import, but for xml files.

type="string">deployment-include.cpf

This is supposed to work, I've tested it with a small example. Semantics: If an
included xml file (or the same file) redefines a component's properties, the
last-seen values are used. It works pretty much the same like an #include ""
statement in C. The include file path is relative to the current directory. So
if you include "../../d.xml" which in turns includes "c.xml", it will look for
"c.xml" in the current directory. This may not be what you want...

I had to change some inner workings to have the 'logical' behaviour right. The
patch also fixes an issue with the 'loaded' flag being improperly used at some
places.

[Bug 546] Deployer programs can not specify component path for p

For more infomation about this bug, visit

--- Comment #4 from S Roderick <kiwi [dot] net [..] ...> 2008-05-13 17:43:25 ---
(In reply to comment #3)
> (In reply to comment #2)
> The deployer does not use .pc files... it just scans directories, possibly
> recursively (depends on your glibc version :-( ), when it sees an import
> statement.

Our glibc does do recursive scanning, hence the confusion when I saw .pc files
being scanned (and dropped).

> > Is this "bug" then just due to extraneous error messages?
>
> The behaviour is wrong in many subtle ways. I don't think we need an extra XML
> file. I'm also looking for the simplest way to get things done, preferably at
> one file/place. This is what should happen:

The extra XML file seems mostly unnecessary to me too, at least as far as
specifying a component path. This is the equivalent of the implicit import
statement that is build into the deployer, which goes looking for plugins
automatically at startup.

> First, plugins should be loaded before components. You can do this using an
> import statement. It should be possible to specify multiple plugin and
> component paths. Import statements already do this. Lastly (feature warning!),
> it should be possible to include an xml file 'into' another xml file. So my
> better application-lxrt.xml version would be:
>
>

>
> /opt/lib/rtt/lxrt/plugins

>
>

>
> /opt/lib/mycomps-lxrt/libmycomp-lxrt

>
>

>
> application-architecture.xml

>

>
> 1 and 2 are already implemented and are already the solution to your bug
> report: just add an early import statement for the plugins. Number 3 is
> optional, but allows better maintenance of xml files for large/multi-os
> applications.

We are using 1 to load the plugins explicitly first, followed by 2 to get all
the OCL lib's.

I would _really_ like to have 3. We already have a need for this, and it is on
my list of things to look at. Is this a big deal to implement?

> The disadvantage of import statements is that they use absolute paths.
> At first, I though it would be better to allow to specify multiple 'component'
> and 'plugin' paths (just like $PATH). Such a PATH solution may resolve that to
> relative import paths. I'm not sure if a PATH is such an important feature, or
> just another option which confuses users. (questions like: what's the
> difference between 'Path' and 'Import' ?)

Absolute paths can certainly be a problem, but it's nonetheless a good initial
solution. And perhaps it is simply, "good enough"?
S

[Bug 546] Deployer programs can not specify component path for p

For more infomation about this bug, visit

Peter Soetens

<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |peter [dot] soetens [..] ...

--- Comment #3 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-05-12 22:40:23 ---
(In reply to comment #2)
> Turns out it is loading plugins, just much later on in the process. Initial
> warnings still indicate it doesn't find any plugins in the standard directory
> (which can't be overridden with the deployer), but some alternate method later
> on appears to be using pkgconfig files to load plugins.

The deployer does not use .pc files... it just scans directories, possibly
recursively (depends on your glibc version :-( ), when it sees an import
statement.

>
> Is this "bug" then just due to extraneous error messages?

The behaviour is wrong in many subtle ways. I don't think we need an extra XML
file. I'm also looking for the simplest way to get things done, preferably at
one file/place. This is what should happen:
First, plugins should be loaded before components. You can do this using an
import statement. It should be possible to specify multiple plugin and
component paths. Import statements already do this. Lastly (feature warning!),
it should be possible to include an xml file 'into' another xml file. So my
better application-lxrt.xml version would be:


/opt/lib/rtt/lxrt/plugins


/opt/lib/mycomps-lxrt/libmycomp-lxrt


application-architecture.xml

1 and 2 are already implemented and are already the solution to your bug
report: just add an early import statement for the plugins. Number 3 is
optional, but allows better maintenance of xml files for large/multi-os
applications.

The disadvantage of import statements is that they use absolute paths.
At first, I though it would be better to allow to specify multiple 'component'
and 'plugin' paths (just like $PATH). Such a PATH solution may resolve that to
relative import paths. I'm not sure if a PATH is such an important feature, or
just another option which confuses users. (questions like: what's the
difference between 'Path' and 'Import' ?)

Any remarks ?

Ruben Smits's picture

[Bug 546] Deployer programs can not specify component path for p

On Monday May 12 2008 22:40:22 Peter Soetens wrote:
> For more infomation about this bug, visit
>
>
> Peter Soetens

<peter [dot] soetens [..] ...> changed:
>
> What |Removed |Added
> --------------------------------------------------------------------------
> CC| |peter [dot] soetens [..] ...
>
>
>
> --- Comment #3 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-05-12
> 22:40:23 --- (In reply to comment #2)
>
> > Turns out it is loading plugins, just much later on in the process.
> > Initial warnings still indicate it doesn't find any plugins in the
> > standard directory (which can't be overridden with the deployer), but
> > some alternate method later on appears to be using pkgconfig files to
> > load plugins.
>
> The deployer does not use .pc files... it just scans directories, possibly
> recursively (depends on your glibc version :-( ), when it sees an import
> statement.
>
> > Is this "bug" then just due to extraneous error messages?
>
> The behaviour is wrong in many subtle ways. I don't think we need an extra
> XML file. I'm also looking for the simplest way to get things done,
> preferably at one file/place. This is what should happen:
> First, plugins should be loaded before components. You can do this using an
> import statement. It should be possible to specify multiple plugin and
> component paths. Import statements already do this. Lastly (feature
> warning!), it should be possible to include an xml file 'into' another xml
> file. So my better application-lxrt.xml version would be:
>
>

>
> /opt/lib/rtt/lxrt/plugins

>
>

>
> /opt/lib/mycomps-lxrt/libmycomp-lxrt

>
>

>
> application-architecture.xml

>

>
> 1 and 2 are already implemented and are already the solution to your bug
> report: just add an early import statement for the plugins. Number 3 is
> optional, but allows better maintenance of xml files for large/multi-os
> applications.
>
> The disadvantage of import statements is that they use absolute paths.
> At first, I though it would be better to allow to specify multiple
> 'component' and 'plugin' paths (just like $PATH). Such a PATH solution may
> resolve that to relative import paths. I'm not sure if a PATH is such an
> important feature, or just another option which confuses users. (questions
> like: what's the difference between 'Path' and 'Import' ?)
>
> Any remarks ?

Can't we add execution arguments for the deployers properties? There only tree
props:

ComponentPath , AutoUnload, Target

and i think only the first one is important for starting up (the third one is
obsolete, i think? Since every target has it's own deployer executable)

Ruben

[Bug 546] Deployer programs can not specify component path for p

On Tuesday 13 May 2008 08:39:49 Ruben Smits wrote:
> > Any remarks ?
>
> Can't we add execution arguments for the deployers properties? There only
> tree props:
>
> ComponentPath , AutoUnload, Target
>
> and i think only the first one is important for starting up (the third one
> is obsolete, i think? Since every target has it's own deployer executable)

What do you mean with 'execution arguments'? Do you mean command line
arguments like --with-path="/opt/mylib" ?

Peter

Ruben Smits's picture

[Bug 546] Deployer programs can not specify component path for p

On Tuesday May 13 2008 22:43:37 Peter Soetens wrote:
> On Tuesday 13 May 2008 08:39:49 Ruben Smits wrote:
> > > Any remarks ?
> >
> > Can't we add execution arguments for the deployers properties? There only
> > tree props:
> >
> > ComponentPath , AutoUnload, Target
> >
> > and i think only the first one is important for starting up (the third
> > one is obsolete, i think? Since every target has it's own deployer
> > executable)
>
> What do you mean with 'execution arguments'? Do you mean command line
> arguments like --with-path="/opt/mylib" ?

Yes, now the deployer already has one for the loglevel, maybe adding one for
the plugin-path is not so hard.

Ruben

[Bug 546] Deployer programs can not specify component path for p

For more infomation about this bug, visit

--- Comment #2 from S Roderick <kiwi [dot] net [..] ...> 2008-05-12 18:15:30 ---
Turns out it is loading plugins, just much later on in the process. Initial
warnings still indicate it doesn't find any plugins in the standard directory
(which can't be overridden with the deployer), but some alternate method later
on appears to be using pkgconfig files to load plugins.

Is this "bug" then just due to extraneous error messages?

[Bug 546] Deployer programs can not specify component path for p

For more infomation about this bug, visit

--- Comment #1 from S Roderick <kiwi [dot] net [..] ...> 2008-05-12 18:14:28 ---
Created an attachment (id=287)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=287)
Log file

Errors start at line 17, while the kdltk package is later accepted around line
48.

Not sure why time runs backward - this is running in a virtual machine, which
_might_ be the cause?