On 28.08.2009, at 13:31, Joel Schuster wrote:
Thanks for all your help!
After taking a look at the FileInstall bundle's code and then the
osgi spec I came to the same conclusions for the most part. The
other alternative is to allow for the naming convention of the cfg
file itself reference a sub-object, in my case there's a handler
that the filter is associated with.
Ex: com.example.services.MyService.RequiresHandler.cfg
Internally it still could be a properties file:
id=<id of filter>
filter=<(name=something)>
I would assume that this scheme would also work with other handlers
like the Event handler.
I don't think this would work directly though the ConfigAdmin's api,
but I'm still coming up-to-speed on the osgi spec. And it would seem
that this would be an iPojo specific type of FileInstall.
Yep, but thanks to Guillaume's work, it will be soon possible to
extend file install with custom deployer. So, such kind of feature
will be easily added without any issue, and without impacting neither
the config admin (of course) nor file instance (the core).
In the mean time, there's no pure iPojo/FileInstall savvy way of
doing what I want. Rather, I'm going to have to @Require something
out of the iPojo arch, @Property a custom string I want in a custom
filter and then use it to look up an instance myself during
@Validate. But, because of the beauty of osgi this shouldn't be too
hard.
What you can do is get the architecture of the instance, introspect it
to get the service dependency and then call setFilter.
Regards,
Clement
Thanks again!
- Joel
-----Original Message-----
From: Clement Escoffier [mailto:[email protected]]
Sent: Friday, August 28, 2009 2:28 AM
To: [email protected]
Subject: Re: requires.filter & cfg file for FileInstaller
On 28.08.2009, at 10:20, Guillaume Nodet wrote:
Not sure to follow ... What is the relationship between reading the
properties file as an xml and the config admin not supporting
dictionaries
(wdym btw ?)
In fact Joel's issue was to configure service dependency filters
thanks to .cfg file (iPOJO related question).
However, to achieve this, the iPOJO instance configuration (or
reconfiguration) must contains a dictionary <dependency-id, new
filter>.
So, supporting XML files is definitely an improvement for File
Install, but anyway it will not solve Joel's issue :-(
Regards,
Clement
On Fri, Aug 28, 2009 at 10:10, Clement Escoffier <
[email protected]> wrote:
Hi,
It's an interesting feature, and I just open a jira about that (
https://cwiki.apache.org/jira/browse/FELIX-1537), but it will not
solve
the issue.
AFAIK, the configuration admin does not support dictionaries (at
least in
the R4).
Regards,
Clement
On 28.08.2009, at 09:20, Guillaume Nodet wrote:
There is already a syntax for xml based properties file defined in
the
jvm.
So we don't have to parse anything, it's just about detecting that
the
file
is in xml somehow and use loadXml instead of load on the
Properties object
iirc.
I guess the easiest solution is to try text based and in case of
failure,
try with xml ...
I plan to apply a very big patch on fileinstall on monday, so we
should
wait
a bit and do that on top of the work i've done.
Could you please raise a JIRA issue for that ?
On Thu, Aug 27, 2009 at 20:19, Clement Escoffier <
[email protected]> wrote:
On 27.08.2009, at 20:16, Joel Schuster wrote:
It seems that it would be nice if FileInstall bundle would allow
the
'.cfg' files to also be xml similar to the iPojo based
configurations.
I'm sure it is possible if we define a syntax.
Describing list, array and dictionaries should be possible.
I saw that Guillaume Nodet has done a lot of work recently on
Fileinstall,
may be already done.
Regards,
Clement
- Joel
-----Original Message-----
From: Clement Escoffier [mailto:[email protected]]
Sent: Thursday, August 27, 2009 11:26 AM
To: [email protected]
Subject: Re: requires.filter & cfg file for FileInstaller
Hi,
I'm not sure if it is possible, but my knowledge of file install
is
quite limited.
It requires the ability to describe a dictionary. It that
possible ?
Regards,
Clement
On 27.08.2009, at 17:59, Joel Schuster wrote:
Is it possible to override the requires.filter in a cfg file for
instance configuration using FileInstaller?
I see: http://felix.apache.org/site/ipojo-reference-card.html
Where the instance configuration in xml can be used:
<instance name="FOO1" component="FOO"/> <!-- Use the default
'filter' value -->
<instance name="FOO2" component="FOO">
<property name="requires.filters">
<property name="id1" value="(foo.property=BAR)"/>
</property>
</instance>
But I don't know how to do this with a cfg file. I'd like to be
able
to change the filter on a @Requires dynamically in a cfg file
against a dynamically configured @ServiceProperty also
configured in
a cfg file.
________________________________
Joel Schuster
Senior Software Engineer
NAVSYS Corporation
14960 Woodcarver Road, Colorado Springs, CO 80921
719-481-4877
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
