[sip-comm-dev] ConfigurationService reference


#1

Hi guys,

I need a reference to the ConfigurationService in a bundle. It's a
pretty common objective so it's an easy copy-and-paste job.

Because of the copy-and-paste part I started thinking why I have to
actually do it.

With OSGi at the center of the architecture, it's a relatively
straight line of thinking why.

But pretty much every bundle of ours which uses ConfigurationService,
caches the reference and doesn't track changes to the
ConfigurationService registrations. Effectively, the dynamic
characteristic provided by OSGi with respect to service availability
is reduced to the first time that the bundle needs the
ConfigurationService reference. And I can totally understand how
difficult it is for a bundle which needs a configuration property
value or two to implement the whole tracking of the changes in the
ConfigurationService references should there be such, then the
property changes, etc.

Then how realistic is the scenario of us having bundles which operate
on different ConfigurationService instances?

As I'm seeing the bundles today, they can pretty much live with a
single ConfigurationServiceUtils#getConfigurationService(), for
example, defined in the package of the ConfigurationService interface
and never again bother with BundleContext, ServiceReference,
BundleContext#getService(ServiceReference), etc. And not that I was
thinking about it at the moment the question popped up for me but now
I don't think the 21 #getConfigurationService() methods do us any
practical good, I rather see them as waste.

Best regards,
Lubo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey Lubo,

Lubomir Marinov wrote:

Hi guys,

I need a reference to the ConfigurationService in a bundle. It's a
pretty common objective so it's an easy copy-and-paste job.

Because of the copy-and-paste part I started thinking why I have to
actually do it.

With OSGi at the center of the architecture, it's a relatively
straight line of thinking why.

But pretty much every bundle of ours which uses ConfigurationService,
caches the reference and doesn't track changes to the
ConfigurationService registrations. Effectively, the dynamic
characteristic provided by OSGi with respect to service availability
is reduced to the first time that the bundle needs the
ConfigurationService reference. And I can totally understand how
difficult it is for a bundle which needs a configuration property
value or two to implement the whole tracking of the changes in the
ConfigurationService references should there be such, then the
property changes, etc.

True. Our current use of OSGi dynamics, especially in the case of the
ConfigurationService. The right way to do this would be through the use
of a dependency management mechanism such as iPOJO for example. We
currently have that scheduled for 1.1 under issue number #388

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=388

Then how realistic is the scenario of us having bundles which operate
on different ConfigurationService instances?

I can see a few scenarios where tracking the state of the
ConfigurationService is important. Application bootstrap and runtime
installation of bundles that depend on the ConfigurationService are two
such examples. In either of these cases we need the service to be
started (i.e. we need the parsing of the configuration file to be
complete) before we try to read properties and this is easily handled
with dependency management.

I believe we could easily come up with even more scenarios when we start
thinking about versioning and bundle upgrades which we don't support yet
but have on the roadmap.

Until we get there however (i.e. until we implement proper dependency
management), we could probably work on implementing a
SipCommAbstractActivator class that access methods for foundation
services such as the configuration, file access and the UI.

This would at least help remove the 21 getConfigurationService() methods
that your correctly see as waste at this point.

How does this sound?

Emil

···

As I'm seeing the bundles today, they can pretty much live with a
single ConfigurationServiceUtils#getConfigurationService(), for
example, defined in the package of the ConfigurationService interface
and never again bother with BundleContext, ServiceReference,
BundleContext#getService(ServiceReference), etc. And not that I was
thinking about it at the moment the question popped up for me but now
I don't think the 21 #getConfigurationService() methods do us any
practical good, I rather see them as waste.

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil,

Thank you for the detailed answer!

Since we have issue #388 scheduled for 1.1, I have the feeling that
the need for SipCommAbstractActivator for the purposes of removing the
21 #getConfigurationService() definitions is much lesser. Anyway,
eliminating duplication is definitely a practice I support so I
personally want to see it happen though with low priority. Please let
me know if you think I should create a new issue for the introduction
and the use of this new class.

Best regards,
Lubomir

P.S. Only marginally related to my initial view of the problem before
your answer but very funny anyway:

···

On Sun, Aug 9, 2009 at 8:10 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey Lubo,

Lubomir Marinov wrote:

Hi guys,

I need a reference to the ConfigurationService in a bundle. It's a
pretty common objective so it's an easy copy-and-paste job.

Because of the copy-and-paste part I started thinking why I have to
actually do it.

With OSGi at the center of the architecture, it's a relatively
straight line of thinking why.

But pretty much every bundle of ours which uses ConfigurationService,
caches the reference and doesn't track changes to the
ConfigurationService registrations. Effectively, the dynamic
characteristic provided by OSGi with respect to service availability
is reduced to the first time that the bundle needs the
ConfigurationService reference. And I can totally understand how
difficult it is for a bundle which needs a configuration property
value or two to implement the whole tracking of the changes in the
ConfigurationService references should there be such, then the
property changes, etc.

True. Our current use of OSGi dynamics, especially in the case of the
ConfigurationService. The right way to do this would be through the use
of a dependency management mechanism such as iPOJO for example. We
currently have that scheduled for 1.1 under issue number #388

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=388

Then how realistic is the scenario of us having bundles which operate
on different ConfigurationService instances?

I can see a few scenarios where tracking the state of the
ConfigurationService is important. Application bootstrap and runtime
installation of bundles that depend on the ConfigurationService are two
such examples. In either of these cases we need the service to be
started (i.e. we need the parsing of the configuration file to be
complete) before we try to read properties and this is easily handled
with dependency management.

I believe we could easily come up with even more scenarios when we start
thinking about versioning and bundle upgrades which we don't support yet
but have on the roadmap.

Until we get there however (i.e. until we implement proper dependency
management), we could probably work on implementing a
SipCommAbstractActivator class that access methods for foundation
services such as the configuration, file access and the UI.

This would at least help remove the 21 getConfigurationService() methods
that your correctly see as waste at this point.

How does this sound?

Emil

As I'm seeing the bundles today, they can pretty much live with a
single ConfigurationServiceUtils#getConfigurationService(), for
example, defined in the package of the ConfigurationService interface
and never again bother with BundleContext, ServiceReference,
BundleContext#getService(ServiceReference), etc. And not that I was
thinking about it at the moment the question popped up for me but now
I don't think the 21 #getConfigurationService() methods do us any
practical good, I rather see them as waste.

Best regards,
Lubo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Lubomir Marinov wrote:

Hi Emil,

Thank you for the detailed answer!

Since we have issue #388 scheduled for 1.1,

We might have to change this since, given the efforts that I am
currently aware of, I don't think #388 would be work upon before the end
of the year.

I have the feeling that
the need for SipCommAbstractActivator for the purposes of removing the
21 #getConfigurationService() definitions is much lesser. Anyway,
eliminating duplication is definitely a practice I support so I
personally want to see it happen though with low priority. Please let
me know if you think I should create a new issue for the introduction
and the use of this new class.

Yes please. Then, if you are interested in implementing this before
December you can schedule it for 1.1, otherwise 1.2 would be fine.

Cheers
Emil

···

Best regards,
Lubomir

P.S. Only marginally related to my initial view of the problem before
your answer but very funny anyway:
http://imgs.xkcd.com/comics/supported_features.png

On Sun, Aug 9, 2009 at 8:10 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey Lubo,

Lubomir Marinov wrote:

Hi guys,

I need a reference to the ConfigurationService in a bundle. It's a
pretty common objective so it's an easy copy-and-paste job.

Because of the copy-and-paste part I started thinking why I have to
actually do it.

With OSGi at the center of the architecture, it's a relatively
straight line of thinking why.

But pretty much every bundle of ours which uses ConfigurationService,
caches the reference and doesn't track changes to the
ConfigurationService registrations. Effectively, the dynamic
characteristic provided by OSGi with respect to service availability
is reduced to the first time that the bundle needs the
ConfigurationService reference. And I can totally understand how
difficult it is for a bundle which needs a configuration property
value or two to implement the whole tracking of the changes in the
ConfigurationService references should there be such, then the
property changes, etc.

True. Our current use of OSGi dynamics, especially in the case of the
ConfigurationService. The right way to do this would be through the use
of a dependency management mechanism such as iPOJO for example. We
currently have that scheduled for 1.1 under issue number #388

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=388

Then how realistic is the scenario of us having bundles which operate
on different ConfigurationService instances?

I can see a few scenarios where tracking the state of the
ConfigurationService is important. Application bootstrap and runtime
installation of bundles that depend on the ConfigurationService are two
such examples. In either of these cases we need the service to be
started (i.e. we need the parsing of the configuration file to be
complete) before we try to read properties and this is easily handled
with dependency management.

I believe we could easily come up with even more scenarios when we start
thinking about versioning and bundle upgrades which we don't support yet
but have on the roadmap.

Until we get there however (i.e. until we implement proper dependency
management), we could probably work on implementing a
SipCommAbstractActivator class that access methods for foundation
services such as the configuration, file access and the UI.

This would at least help remove the 21 getConfigurationService() methods
that your correctly see as waste at this point.

How does this sound?

Emil

As I'm seeing the bundles today, they can pretty much live with a
single ConfigurationServiceUtils#getConfigurationService(), for
example, defined in the package of the ConfigurationService interface
and never again bother with BundleContext, ServiceReference,
BundleContext#getService(ServiceReference), etc. And not that I was
thinking about it at the moment the question popped up for me but now
I don't think the 21 #getConfigurationService() methods do us any
practical good, I rather see them as waste.

Best regards,
Lubo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Just to conclude this thread for now, I've created issue #714
(https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=714) to
schedule the related development and track its progress.

Regards,
Lubomir

···

On Thu, Aug 13, 2009 at 11:22 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Lubomir Marinov wrote:

Hi Emil,

Thank you for the detailed answer!

Since we have issue #388 scheduled for 1.1,

We might have to change this since, given the efforts that I am
currently aware of, I don't think #388 would be work upon before the end
of the year.

I have the feeling that
the need for SipCommAbstractActivator for the purposes of removing the
21 #getConfigurationService() definitions is much lesser. Anyway,
eliminating duplication is definitely a practice I support so I
personally want to see it happen though with low priority. Please let
me know if you think I should create a new issue for the introduction
and the use of this new class.

Yes please. Then, if you are interested in implementing this before
December you can schedule it for 1.1, otherwise 1.2 would be fine.

Cheers
Emil

Best regards,
Lubomir

P.S. Only marginally related to my initial view of the problem before
your answer but very funny anyway:
http://imgs.xkcd.com/comics/supported_features.png

On Sun, Aug 9, 2009 at 8:10 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey Lubo,

Lubomir Marinov wrote:

Hi guys,

I need a reference to the ConfigurationService in a bundle. It's a
pretty common objective so it's an easy copy-and-paste job.

Because of the copy-and-paste part I started thinking why I have to
actually do it.

With OSGi at the center of the architecture, it's a relatively
straight line of thinking why.

But pretty much every bundle of ours which uses ConfigurationService,
caches the reference and doesn't track changes to the
ConfigurationService registrations. Effectively, the dynamic
characteristic provided by OSGi with respect to service availability
is reduced to the first time that the bundle needs the
ConfigurationService reference. And I can totally understand how
difficult it is for a bundle which needs a configuration property
value or two to implement the whole tracking of the changes in the
ConfigurationService references should there be such, then the
property changes, etc.

True. Our current use of OSGi dynamics, especially in the case of the
ConfigurationService. The right way to do this would be through the use
of a dependency management mechanism such as iPOJO for example. We
currently have that scheduled for 1.1 under issue number #388

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=388

Then how realistic is the scenario of us having bundles which operate
on different ConfigurationService instances?

I can see a few scenarios where tracking the state of the
ConfigurationService is important. Application bootstrap and runtime
installation of bundles that depend on the ConfigurationService are two
such examples. In either of these cases we need the service to be
started (i.e. we need the parsing of the configuration file to be
complete) before we try to read properties and this is easily handled
with dependency management.

I believe we could easily come up with even more scenarios when we start
thinking about versioning and bundle upgrades which we don't support yet
but have on the roadmap.

Until we get there however (i.e. until we implement proper dependency
management), we could probably work on implementing a
SipCommAbstractActivator class that access methods for foundation
services such as the configuration, file access and the UI.

This would at least help remove the 21 getConfigurationService() methods
that your correctly see as waste at this point.

How does this sound?

Emil

As I'm seeing the bundles today, they can pretty much live with a
single ConfigurationServiceUtils#getConfigurationService(), for
example, defined in the package of the ConfigurationService interface
and never again bother with BundleContext, ServiceReference,
BundleContext#getService(ServiceReference), etc. And not that I was
thinking about it at the moment the question popped up for me but now
I don't think the 21 #getConfigurationService() methods do us any
practical good, I rather see them as waste.

Best regards,
Lubo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net