date:20161121

Re: [osgi-dev] component factory and configuration

2016-11-21 Thread Scott Lewis


On 11/21/2016 8:11 AM, BJ Hargrave wrote:




If you want to create a specific number of services each configured by 
a factory configuration instance, then prototype scopes services are 
orthogonal to your needs.


If not prototype scope services...for service instances configured by 
factory configuration instances..then what?


Scott


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] [configadmin] targeting ManagedServices or Components

2016-11-21 Thread Balázs Zsoldos

Hi,

I have another thought based on the configadmin spec. if you have still
some energy to read my mails :)

In *104.3.2 Targeted Pid*s

The target PID scopes the applicability of the PID to a limited set of
> target bundles.
> The syntax of a target pid is: target-pid ::= PID ( '|' symbolic-name (
> '|' version ( '|' location )? )? )?


My question is: Why do we target the bundle?

Using Require-Bundle at bundle wirings is "deprecated" and there is a
reason for that.

Before reading the following, please note: I am not proposing to change the
syntax of PIDs in an incompatible way. I am writing these examples simply
to have a similarity with the current spec.

Why do not we target with OSGi filters?

An example to target a bundle:

MYPID|(bundle.symbolicName=myBundle)

Well, targeting bundles are not that interesting. I would never use that.
But targeting components or managed services that have multiple versions in
the OSGi container can be much more interesting. The selected Managed
Service would be based on its service properties.

If one uses ConfigurationListener instead of ManagedService to implement a
component framework, he/she can decide what the OSGi filter should be
matched against.

An example to be sure that the compatible version of the component will
pick up the configuration :

MYPID|(&(version>=2.1)!(version>=3))

Kind regards,
*Balázs*
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Universal purpose of Configuration Admin new functions

2016-11-21 Thread Balázs Zsoldos

Hi Raymond (and others),

I meant chapter 5.1 of RFC-227
.
I will try to write down the flow I went through after I read the spec, so
you might be able to tell me where I was wrong.

When I first saw this chapter, I got really happy. I felt that finally, one
does not need workarounds to achieve the use-cases that I wrote about in my
last mail. However, I soon realized that deploying those configurations are
not 100% possible. It is not possible as I cannot deploy existing
configurations.

Imagine the following steps:

   - I create some factory configurations with webconsole user interface.
   The new configuration will be created with the existing
   createFactoryConfiguration(factoryPid)
   

   function
   - I save the configurations into my source code controller. Well, that
   is Felix ConfigAdmin specific step :). Luckily Felix ConfigAdmin stores the
   configs on the file system in the way that the configurations are
   comparable by any diff tool (sorted and array values on new line).
   Therefore storing them in git or SVN works pretty well
   - Now if I want to apply new configuration (that was uploaded to source
   control) without server restart, I will not be able to with the new
   functions in ConfigurationAdmin, as the factory configurations were created
   with the old function (that has a different syntax concerning to the Pid)


Must note that diffing configs are not only useful if you want to check
differences on source codes, but also if you want to check differences
between two servers where one works and other does not.

The question in short: If I have existing configuration, can I somehow
deploy it to a server with the new functions?

I asked this question on the felix mailing
 list
and based on the answer, it will not be possible.

So I started to think. I tried put myself into the shoes of the ones who
wrote the RFC. I come up with new requirements always based on my
experiences. There are always aspects that I miss as I do not meet them at
work. I tried to find out, what is the experience and motivation behind the
new functions. I visited a couple of methods how people on the world use
ConfigurationAdmin with external tools and plugins. I found that I would
have written a very similar RFC if I used Felix FileInstall to deploy
configurations. Why?

If I use Felix FileInstall to create my configs

   - I will have all my configs in a ConfigAdmin independent format in the
   source code control and I edit these files by hand
   - I will never go to the webconsole and create factory configurations
   via the UI, so I will not have configurations that I cannot deploy to other
   servers
   - I can always delete all configurations from the folder where the
   configAdmin bundle stores them, as I can recreate them from the format that
   used by FileInstall. I will not feel the issue if I cannot re-create
   configurations created by the old createFactoryConfiguration... function
   - FileInstall has files with the following name format: *factory-pid*.
   What if I just change the colon to some special character like hashmark?
   Why not dot? Because Felix ConfigAdmin implementation already uses that
   character.

As I said, if I used Felix FileInstall in the last years, I would come to
the same conclusion and wrote the same RFC. The writers might had a
different motivation and experience, but in that case I would be really
interested in it.

I feel that RFCs are only meaningful if experience and motivation is shared
behind the content. I am missing this at the moment. Only functional
requirements are written, that a spec should be able to do that. But it is
not written there, why, so it is hard to decide if something might be
missing. I would be very thankful if the people who write the RFCs would
sacrifice their time not only to write RFC but also some pages about
the use-cases they want to solve.

My motivation is the following (just to see it as a short example):

   - I like building a component graph on a running OSGi container. I see
   rapidly the result of changing some config. I can build a component tree
   from top to down and see how it looks like.
   - To build component graph live, I use webconsole and therefore the
   ConfigurationAdmin.createFactoryConfiguration function is used for factory
   configs.
   - I want to export the configurations that I created on the live living
   OSGi container and reuse it in unit tests, dev, test or production servers.
   At the moment, I simply copy the folder where Felix ConfigAdmin stores the
   configs to the source control
   - In the future, I would like to implement some Eclipse plugin
   extensions that live updates the running OSGi container with the

Re: [osgi-dev] Universal purpose of Configuration Admin new functions

2016-11-21 Thread Raymond Auge

Furthermore, it's quite rare (I've never seen it) in my limited experience
than an OSGi spec is directly influenced by a particular implementation in
a way that "since this impl does it... so should the spec". I assure you
_at least_ BJ would lose his mind if we tried to do this.

Sincerely,
- Ray

On Mon, Nov 21, 2016 at 2:26 PM, Raymond Auge 
wrote:

> Would you mind referring to the section you are referring to specifically
> by number and paragraph number just so we can better orient ourselves? We
> don't read these every day so we often forget what's there.
>
> :)
>
> Sincerely,
> - Ray
>
> On Mon, Nov 21, 2016 at 2:21 PM, Balázs Zsoldos  > wrote:
>
>> Hi,
>>
>> I read about the new features of ConfigurationAdmin that will be applied
>> in the new OSGi release. After checking the new functions, I feel that I
>> might miss the point.
>>
>> What I feel that the new functions have no other purpose but satisfying
>> some of the requirements of Apache Felix FileInstall.
>>
>> It is possible to create factory config instances, but it is not possible
>> to do it with any kind of pid. That somehow does not make sense to me. Why
>> not all of them just some of them?
>>
>> Why is the special character the hashmark? Is it because Felix
>> ConfigAdmin uses a dot at the moment? What about other implementations of
>> the specifications? Or the new versions of specifications are written based
>> on the current implementation specific details? Even if almost everybody
>> uses the Felix implementation.
>>
>> I think that a universal solution would help much more projects, not only
>> Config Admin. By an universal solution, I mean: Possibility to deploy
>> configurations with pre-defined pids. This could be a help for FileInstall,
>> too.
>>
>> With a universal solution, use-cases could be solved without workaround
>> like:
>>
>>-  Deployment of configurations from source-control at development
>>time: Imagine that we use an IDE that supports starting OSGi containers,
>>keep the config with the sources and update configuration without
>>restarting the OSGi container
>>- Deployment of configuration to several computers in a clustered
>>environment
>>
>>
>> What do you think? Am I missing the point?
>>
>> *Balázs **Zsoldos*
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Universal purpose of Configuration Admin new functions

2016-11-21 Thread Raymond Auge

Would you mind referring to the section you are referring to specifically
by number and paragraph number just so we can better orient ourselves? We
don't read these every day so we often forget what's there.

:)

Sincerely,
- Ray

On Mon, Nov 21, 2016 at 2:21 PM, Balázs Zsoldos 
wrote:

> Hi,
>
> I read about the new features of ConfigurationAdmin that will be applied
> in the new OSGi release. After checking the new functions, I feel that I
> might miss the point.
>
> What I feel that the new functions have no other purpose but satisfying
> some of the requirements of Apache Felix FileInstall.
>
> It is possible to create factory config instances, but it is not possible
> to do it with any kind of pid. That somehow does not make sense to me. Why
> not all of them just some of them?
>
> Why is the special character the hashmark? Is it because Felix ConfigAdmin
> uses a dot at the moment? What about other implementations of the
> specifications? Or the new versions of specifications are written based on
> the current implementation specific details? Even if almost everybody uses
> the Felix implementation.
>
> I think that a universal solution would help much more projects, not only
> Config Admin. By an universal solution, I mean: Possibility to deploy
> configurations with pre-defined pids. This could be a help for FileInstall,
> too.
>
> With a universal solution, use-cases could be solved without workaround
> like:
>
>-  Deployment of configurations from source-control at development
>time: Imagine that we use an IDE that supports starting OSGi containers,
>keep the config with the sources and update configuration without
>restarting the OSGi container
>- Deployment of configuration to several computers in a clustered
>environment
>
>
> What do you think? Am I missing the point?
>
> *Balázs **Zsoldos*
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Universal purpose of Configuration Admin new functions

2016-11-21 Thread Balázs Zsoldos

Hi,

I read about the new features of ConfigurationAdmin that will be applied in
the new OSGi release. After checking the new functions, I feel that I might
miss the point.

What I feel that the new functions have no other purpose but satisfying
some of the requirements of Apache Felix FileInstall.

It is possible to create factory config instances, but it is not possible
to do it with any kind of pid. That somehow does not make sense to me. Why
not all of them just some of them?

Why is the special character the hashmark? Is it because Felix ConfigAdmin
uses a dot at the moment? What about other implementations of the
specifications? Or the new versions of specifications are written based on
the current implementation specific details? Even if almost everybody uses
the Felix implementation.

I think that a universal solution would help much more projects, not only
Config Admin. By an universal solution, I mean: Possibility to deploy
configurations with pre-defined pids. This could be a help for FileInstall,
too.

With a universal solution, use-cases could be solved without workaround
like:

   -  Deployment of configurations from source-control at development time:
   Imagine that we use an IDE that supports starting OSGi containers, keep the
   config with the sources and update configuration without restarting the
   OSGi container
   - Deployment of configuration to several computers in a clustered
   environment


What do you think? Am I missing the point?

*Balázs **Zsoldos*
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGi factory pids and configuration admin

2016-11-21 Thread Benson Margulies

p.s. Thank you, those emails rescued me from the confused state I
landed in reading the fileinstall code.

On Mon, Nov 21, 2016 at 2:09 PM, Benson Margulies  wrote:
> I am really only concerned with fileinstall as a model/example of what
> I am trying to do. Let me try again and nearly eliminate all evidence
> of it from my question.
>
> Step 1: Code in CXF does:
>
> Properties servProps = new Properties();
> servProps.put(Constants.SERVICE_PID, FACTORY_PID);
> reg = context.registerService(ManagedServiceFactory.class.getName(),
>this, servProps);
>
> That FACTORY_PID is org.apache.cxf.http.jetty.
>
> Step 2:
>
> I call createFactoryConfiguration on "org.apache.cxf.http.jetty" with
> some properties.
>
> Step 3:
>
> I decide that I have changed my mind, and I want to adjust one of the values.
>
> So I think I need to do what Mr. Ward had explained and use a property
> to identify my particular configuration.
>
> I think that the 'magic property' in the fileinstall case is probably
> the property they use for their file name, and that's why I missed it,
> but I don't need to deal with that.
>
>
>
>
>
> On Mon, Nov 21, 2016 at 1:49 PM, BJ Hargrave  wrote:
>> I think you need to ask this in a felix list since you are asking about how
>> felix fileinstall works.
>>
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com
>>
>>
>>
>> - Original message -
>> From: Benson Margulies 
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> To: OSGi Developer Mail List 
>> Cc:
>> Subject: [osgi-dev] OSGi factory pids and configuration admin
>> Date: Mon, Nov 21, 2016 1:34 PM
>>
>> Given a factory pid of a.b.c, and a pid of q, I am a little
>> disoriented about how to manage some properties.
>>
>> Felix fileinstall parses a.b.c-q as 'pid = a.b.c', factoryPid = 'q'.
>> It calls createFactoryConfiguration for 'a.b.c', and ignores the q.
>>
>> The 'updated' method on the service is called on a pid like
>> 'a.b.c.UNIQUE-STRING'.
>>
>> Do I need to add something to the properties so that the pid remains
>> 'a.b.c-q'?
>>
>> As it is, I'm failing to use a second call to configuration admin to
>> update one of the properties.
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGi factory pids and configuration admin

2016-11-21 Thread Timothy Ward

Hi,

I think that you also have a bit of a misunderstanding about what a factory pid 
is.

> Given a factory pid of a.b.c, and a pid of q, I am a little
> disoriented about how to manage some properties

This doesn’t really make sense, you can have a factory pid of a.b.c, but the 
pid for a factory configuration isn’t user configurable.

> Felix fileinstall parses a.b.c-q as 'pid = a.b.c', factoryPid = 'q'.
> It calls createFactoryConfiguration for ‘a.b.c', and ignores the q.

File install doesn’t parse quite like that. File Install looks for files called 
xxx.cfg. If xxx contains a ‘-‘ character then the configuration is a factory 
configuration, and is split into the section before the ‘-‘ and after the ‘-‘. 
The section before is the factory pid, the section after is used by File 
Install as an identifier (literally inserted as a value in the configuration).

> The 'updated' method on the service is called on a pid like
> 'a.b.c.UNIQUE-STRING'.
> 
> Do I need to add something to the properties so that the pid remains 
> 'a.b.c-q'?

No, this is not possible. Configuration Admin decides on the pid, not you.

> As it is, I'm failing to use a second call to configuration admin to
> update one of the properties.

I’m assuming that you can’t (or don’t want to) update the file on disk, so 
instead you should be listing the configurations, filtering for the one that 
you want.

configAdmin.listConfigurations(“(&(service.factoryPid=factoryPid)(some.key=some.value))”);

You can then update the configuration from there. You can ask the File Install 
guys for their magic property name if you want, or you can use some other known 
property.

Regards,

Tim

> On 21 Nov 2016, at 18:34, Benson Margulies  wrote:
> 
> Given a factory pid of a.b.c, and a pid of q, I am a little
> disoriented about how to manage some properties.
> 
> Felix fileinstall parses a.b.c-q as 'pid = a.b.c', factoryPid = 'q'.
> It calls createFactoryConfiguration for 'a.b.c', and ignores the q.
> 
> The 'updated' method on the service is called on a pid like
> 'a.b.c.UNIQUE-STRING'.
> 
> Do I need to add something to the properties so that the pid remains 
> 'a.b.c-q'?
> 
> As it is, I'm failing to use a second call to configuration admin to
> update one of the properties.
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGi factory pids and configuration admin

2016-11-21 Thread BJ Hargrave

I think you need to ask this in a felix list since you are asking about how felix fileinstall works.
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Benson Margulies Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: [osgi-dev] OSGi factory pids and configuration adminDate: Mon, Nov 21, 2016 1:34 PM 
Given a factory pid of a.b.c, and a pid of q, I am a littledisoriented about how to manage some properties.Felix fileinstall parses a.b.c-q as 'pid = a.b.c', factoryPid = 'q'.It calls createFactoryConfiguration for 'a.b.c', and ignores the q.The 'updated' method on the service is called on a pid like'a.b.c.UNIQUE-STRING'.Do I need to add something to the properties so that the pid remains 'a.b.c-q'?As it is, I'm failing to use a second call to configuration admin toupdate one of the properties.___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] OSGi factory pids and configuration admin

2016-11-21 Thread Benson Margulies

Given a factory pid of a.b.c, and a pid of q, I am a little
disoriented about how to manage some properties.

Felix fileinstall parses a.b.c-q as 'pid = a.b.c', factoryPid = 'q'.
It calls createFactoryConfiguration for 'a.b.c', and ignores the q.

The 'updated' method on the service is called on a pid like
'a.b.c.UNIQUE-STRING'.

Do I need to add something to the properties so that the pid remains 'a.b.c-q'?

As it is, I'm failing to use a second call to configuration admin to
update one of the properties.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] component factory and configuration

2016-11-21 Thread BJ Hargrave

There is a life cycle mismatch here. For a prototype scope service, a new instance is created for each consumer of the service. So there are potentially an infinite number of service instances.
 
For factory configurations, there are a finite number of configuration instances because someone has to set them and they are set in advance of the prototype service instance creation.
 
So there is no way to match a prototype scope service instance with any specific factory configuration instance.
 
Prototype scope services are for the use case of managing resources on behalf of the service consumer such that for each instance, some resources are allocated which must be deallocated when then service instance is released. The notion of prototype scoped services was created in support  of EJB and CDI beans (see RFC 195 for some background).
 
If you want to create a specific number of services each configured by a factory configuration instance, then prototype scopes services are orthogonal to your needs.
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Scott Lewis Sent by: osgi-dev-boun...@mail.osgi.orgTo: osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] component factory and configurationDate: Mon, Nov 21, 2016 10:33 AM 
On 11/21/2016 12:50 AM, Timothy Ward wrote:
Any thoughts/comments about method for getting a distinct configuration associated with every service instance? 
This is fine for my use case WRT creating service instances on demand via the FooConsumer.   However, I would like to be able to have a distinct/new configuration associated with each new FooImpl, rather than a single FooConfig instance assigned to all of them.   Is this possible using the PROTOTYPE pattern, or is it necessary to use the ComponentFactory in the manner Tim describes to accomplish this:The way that this is done is to pass the configuration using the newInstance method. Effectively your pattern would be to register a ConfigurationListener or ManagedServiceFactory, passing the configuration Dictionary to the Component Factory for each Factory Configuration. 

___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] component factory and configuration

2016-11-21 Thread Timothy Ward

As I tried to explain earlier (but insufficiently well) there are two parallel 
things that you need to do:

First, and most importantly, use factory configurations to get your “many 
configurations behaviour”. This is how you get a separate configuration 
associated with each service instance for a single DS component. Each factory 
configuration maps to a separately registered service. When you want the 
service with the given configuration you get it from the service registry. You 
can inject all of these services into some other component using a multiple 
cardinality reference.

Second - to get the lifecycle you want you should register your configurable 
component with PROTOTYPE scope. This way a client can use ServiceObjects to get 
its own instance on demand. As you have seen, multiple requests to the same 
ServiceObjects will give you multiple instances with the same configuration. In 
the use case you have described you want to be injected with *all* of the 
Service Objects and to get one of each of them from each registered service.

I hope this helps,

Tim

> On 21 Nov 2016, at 15:32, Scott Lewis  wrote:
> 
> On 11/21/2016 12:50 AM, Timothy Ward wrote:
>> 
> 
> Any thoughts/comments about method for getting a distinct configuration 
> associated with every service instance?
> 
 This is fine for my use case WRT creating service instances on demand via 
 the FooConsumer.   However, I would like to be able to have a distinct/new 
 configuration associated with each new FooImpl, rather than a single 
 FooConfig instance assigned to all of them.   Is this possible using the 
 PROTOTYPE pattern, or is it necessary to use the ComponentFactory in the 
 manner Tim describes to accomplish this:

 The way that this is done is to pass the configuration using the 
 newInstance method. Effectively your pattern would be to register a 
 ConfigurationListener or ManagedServiceFactory, passing the configuration 
 Dictionary to the Component Factory for each Factory Configuration.
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] component factory and configuration

2016-11-21 Thread Scott Lewis


On 11/21/2016 12:50 AM, Timothy Ward wrote:




Any thoughts/comments about method for getting a distinct configuration 
associated with every service instance?



This is fine for my use case WRT creating service instances
on demand via the FooConsumer.   However, I would like to be
able to have a distinct/new configuration associated with
each new FooImpl, rather than a single FooConfig instance
assigned to all of them.  Is this possible using the
PROTOTYPE pattern, or is it necessary to use the
ComponentFactory in the manner Tim describes to accomplish this:

The way that this is done is to pass the configuration using
the newInstance method. Effectively your pattern would be to
register a ConfigurationListener or ManagedServiceFactory,
passing the configuration Dictionary to the Component
Factory for each Factory Configuration.




___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] component factory and configuration

2016-11-21 Thread Timothy Ward

Hi Ray,

So a component property type is unable to override any super type methods (i.e. 
the Java compiler blocks this).

You therefore can’t define any of the following methods:
annotationType
getClass
hashCode
clone
toString
notify
notifyAll
wait
Unfortunately the DS spec is silent about what these methods should do. I think 
there needs to be a spec clarification saying that these methods must behave as 
defined by Object/Annotation. Note that this would be a breaking behaviour 
change for Felix SCR as currently the result of calling toString is access to 
the “toString” configuration property. Technically the change is also breaking 
for the spec, but I think we can get away with it because the component 
property type can’t directly define toString().

Another option is just to set a toString property in your component properties. 
That will make sure that your configuration always returns a String for 
toString, although you shouldn’t rely on the value as the toString behaviour 
might change!

Tim

> On 21 Nov 2016, at 02:40, Raymond Auge  wrote:
> 
> You're right Tim, it's not a bug per say and that's why I never called it 
> that. But it sure is damned annoying. And frankly I don't have a really good 
> solution either. 
> 
> However it seems the only truly logical thing the proxy could do is blacklist 
> any of the Object non-arg methods. To be honest, I think that wouldn't be a 
> bad thing... if someone really uses any of these "properties" I'd question 
> their motives:
> 
> getClass
> hashCode
> clone
> toString
> notify
> notifyAll
> wait
> 
> They could get a better result with any kind of prefix.
> 
> - Ray
> 
> On Sun, Nov 20, 2016 at 6:56 PM, Tim Ward  > wrote:
> I'm not sure how you would fix this. Isn't toString a valid (and unset) 
> property of a configuration?
> 
> Sounds like a working, albeit non-obviously so, implementation to me.
> 
> Regards,
> 
> Tim
> 
> Sent from my iPhone
> 
> On 20 Nov 2016, at 23:43, Raymond Auge  > wrote:
> 
>> Scott, the null is a tricky side effect of the config proxy's toString 
>> method. It's not your code. The object is indeed not null, but putting it in 
>> a string triggers this naughty output which I admit has caused me headaches 
>> a few times. Someone should really fix it.
>> 
>> - Ray
>> 
>> 
>> On Nov 20, 2016 2:27 PM, "Scott Lewis" > > wrote:
>> I've created these two components:
>> 
>> #1 FooImpl of IFoo service
>> 
>> @ObjectClassDefinition(name = "Foo Configuration")
>> @interface FooConfig {
>>   String message() default "Hi There";
>> }
>> @Designate(ocd = FooConfig.class, factory=true)
>> @Component(scope=ServiceScope.PROTOTYPE,configurationPolicy=ConfigurationPolicy.REQUIRE)
>> public class FooImpl implements IFoo {
>> 
>> private FooConfig config;
>> 
>> @Override
>> public String getMessage() {
>> return config.message();
>> }
>> 
>> @Activate
>> void activate(FooConfig config) throws Exception {
>> System.out.println("activate instance="+this+" with config="+config);
>> this.config = config;
>> }
>> 
>> @Deactivate
>> void deactivate() {
>> System.out.println("deactivate instance="+this);
>> }
>> 
>> @Modified
>> void modified(FooConfig config) {
>> System.out.println("modified instance="+this+" with new 
>> config="+config);
>> }
>> }
>> 
>> 
>> // #2 The FooConsumer that creates the prototype instances
>> 
>> @Component(immediate=true)
>> public class FooConsumer {
>> 
>> private ComponentServiceObjects f;
>> 
>> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
>> void setFooFactory(ComponentServiceObjects fact) {
>> this.f = fact;
>> }
>> 
>> void unsetFooFactory(ComponentServiceObjects fact) {
>> this.f = null;
>> }
>> 
>> private IFoo[] foos;
>> 
>> @Activate
>> void activate() {
>> System.out.println("activate FooConsumer="+f);
>> foos = new IFoo[5];
>> for(int i=0; i < 5; i++) {
>> foos[i] = f.getService();
>> System.out.println("foos["+i+"].getMessage() returns: 
>> "+foos[i].getMessage());
>> }
>> }
>> 
>> @Deactivate
>> void deactivate() {
>> for(int i=0; i < 5; i++) {
>> f.ungetService(foos[i]);
>> }
>> }
>> }
>> 
>> When the two bundles (IFoo API bundle and bundle containing above 2 
>> components) are installed and started on Karaf 4.0.5 no output is produced, 
>> since there is no configuration created and the consumer ref to the 
>> ComponentServiceFactory is set to REQUIRE. When I go to the webconsole and 
>> create a Foo Configuration the following output is produced:
>> 
>> karaf@root()> activate FooConsumer=ComponentServiceObjectsImpl 
>> [instances=[], se
>>

Re: [osgi-dev] component factory and configuration

[osgi-dev] [configadmin] targeting ManagedServices or Components

Re: [osgi-dev] Universal purpose of Configuration Admin new functions

Re: [osgi-dev] Universal purpose of Configuration Admin new functions

Re: [osgi-dev] Universal purpose of Configuration Admin new functions

[osgi-dev] Universal purpose of Configuration Admin new functions

Re: [osgi-dev] OSGi factory pids and configuration admin

Re: [osgi-dev] OSGi factory pids and configuration admin

Re: [osgi-dev] OSGi factory pids and configuration admin

[osgi-dev] OSGi factory pids and configuration admin

Re: [osgi-dev] component factory and configuration

Re: [osgi-dev] component factory and configuration

Re: [osgi-dev] component factory and configuration

Re: [osgi-dev] component factory and configuration

14 matches

Site Navigation

Mail list logo

Footer information