HI,

Am 16.09.2012 um 21:12 schrieb Andrei Pozolotin:

> Felix:
> 
> Thank you for your attention to this;
> 
> Please let me know if you agree there is really such a problem:
> https://www.osgi.org/bugzilla/show_bug.cgi?id=151

I happen to not agree.
> 
> ##########################
> 0) there seems to be an ongoing confusion re: "what are the appropriate
> patterns to create and manage component factories inside declarative services
> paradigm?"
> 
> http://stackoverflow.com/search?q=osgi+component+factory
> http://njbartlett.name/2010/07/19/factory-components-in-ds.html
> http://floriansblog.wordpress.com/category/osgi-3/
Debate per se is good. What you take always depends on what you need. You don't 
take ComponentFactory when in reality you just need a regular unconfigured 
plain old service. Just like you don't take pills against headaches when in 
reality you broke your arm (though the pill against headaches may reduce your 
pains).

> 
> 1) there seems to be only 2 approaches advocated:
> http://wiki.osgi.org/wiki/Declarative_Services#Component_Factories
> * ConfigurationAdmin - Driven
> * ComponentFactory - Driven
I think the single most important differentiator is actually the usage pattern:

(1) If you primarily intend system administrators to craete instances through 
configuration, you'd go for the Configuration Admin driven approach. We do that 
in the Apache Sling logging bundle: You create factory configuration instances 
to configure log levels for different log categories (in SLF4J speak).

(2) If you primarily intend to programmatically create (and configure) and 
dispose off instances you'd go for ComponentFactory. Here the application 
programmer has a much higher influence and responsibility in properly managing 
and using the instances.

Also note, that after a system restart the Configuration based instances are 
recreated while the ComponentFactory instances have to be recreated 
programmatically.

The single common thing is that both ways have a single identifying property: 
The component name for the first case and the component factory name for the 
second case. That's all you have to refer to the "factory" view of the world.

> 
> 2) both approaches are incomplete, since creation of underlying factories is
> hidden form the end user by SCR run time but at the same time they do not
> provide a unified and adequate "factory manager" facilities to actually 
> access,
> control, and customize these underlying factories and instance creation in a
> type-safe manner.
Yes, both explicitly relieve the developer from implementing a factory because 
the DS implementation does that on behalf of the developer. This is our service.

If you don't want to leverage that service, you are free to not use it. If you 
want to have full control and are ready to implement a lot of boiler plate 
code, there is no one in the world stopping your from doing it.

> 
> 3) the purpose of this bug is to discuss declarative services enhancements
> https://www.osgi.org/bugzilla/show_bug.cgi?id=147
> either in form of guidelines or actual new DS/SCR components/services.

Yes, but lets repeat: Tell me what your problem is and why you think your 
extension is the only way to solve your problem. 

Regards
Felix

> ##########################
> 
> because 
>     "support custom ComponentFactory properties"
>     https://issues.apache.org/jira/browse/FELIX-3667
> 
> is merely an attempt to approach
>     "declarative services component factories patterns guidelines and/or 
> implementations"
>     https://www.osgi.org/bugzilla/show_bug.cgi?id=151
> 
> 
> Andrei
> -------- Original Message --------
> Subject: Re: [osgi-dev] custom properties for a DS / ComponentFactory? (was : 
> 112.2.4 Factory Component: "The service properties of the Component Factory 
> service must not include the component properties")
> From: Felix Meschberger <[email protected]>
> To: OSGi Developer Mail List <[email protected]>
> Date: Sun 16 Sep 2012 06:45:16 AM CDT
>> Hi Andrei,
>> 
>> Thank you very much for your sustained interest in DS.
>> 
>> I have been following this discussion from far away (I am not a very active 
>> member of the bndtools list) and am now faced with your Felix request [1].
>> 
>> Let me repeat, what Peter and BJ already said: Please tell us what problem 
>> you want to solve and why you think your enhancements are the only useful 
>> way to solve your problem.
>> 
>> You might want to start like this:
>> 
>> -----------------------
>> I have this problem: .... <description of the problem> ....
>> 
>> I think ComponentFactory can help me solve that problem like this: 
>> ...<explanation of your solution>...
>> 
>> But to fully solve my problem, I am missing ...<your proposal here>....
>> -----------------------
>> 
>> If you cannot come up with a concrete problem to which your ComponentFactory 
>> extension proposal is the only solution, we all have a hard time supporting 
>> your request. I am really sorry.
>> 
>> Regards
>> Felix
>> 
>> [1] https://issues.apache.org/jira/browse/FELIX-3667
>> Am 13.09.2012 um 17:43 schrieb Andrei Pozolotin:
>> 
>>> Hello;
>>> 
>>> I am curious to see if anyone else sees a value in custom properties for a 
>>> DS / ComponentFactory?
>>> 
>>> original question:
>>> 
>>> 112.2.4 Factory Component: "The service properties of the Component Factory 
>>> service must not include the component properties"
>>> 
>>> https://groups.google.com/d/msg/bndtools-users/iYAjRU2p03I/d9PF9rmTNFsJ
>>> 
>>> thanks.
>>> 
>>> Andrei.
>>> 
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> [email protected]
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> 
>> 
>> 
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
> 
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to