Re: ipojo @ServiceProperty field cannot be configured by FileInstall?
On Tue, Jul 19, 2011 at 3:40 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, On 16.07.2011, at 16:02, jie yan wrote: I configured some ipojo components by FileInstall, as following: 1) install ConfigAdmin, FileInstall; 2) set the managedservice attribute, @Component(managedservice=com-pid); 3) create com-pid.cfg file inside /load directory In this way, I successfully configured some components except one javax.servlet.Filter implementation. The only difference I found out is, the field of Filter component to be configured is @ServiceProperty, while the fields of other components all is @Property. Is it the real reason? No, that should not matter. Did you try to add 'immediate=true' to your @Component ? I tried, but failed again. Now, component defination is by annotation, instance creation is by meta.xml, and component configuration is by FileInstall *.cfg. Maybe it's because of the complex order of instance creation, configuration and update? I'll debug into felix more deeply. Regards, drhades Regards, Clement Regards, drhades
Re: ipojo @ServiceProperty field cannot be configured by FileInstall?
That's it! Thank Clement. Regards, drhades On Tue, Jul 19, 2011 at 6:40 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, Oh I see, I misunderstood your previous mail. So, as you're using ManagedService (and not ManagedServiceFactory), use: @Property @ServiceProperty private String myProp; Regards, Clement On 19.07.2011, at 11:38, jie yan wrote: On Tue, Jul 19, 2011 at 3:40 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, On 16.07.2011, at 16:02, jie yan wrote: I configured some ipojo components by FileInstall, as following: 1) install ConfigAdmin, FileInstall; 2) set the managedservice attribute, @Component(managedservice=com-pid); 3) create com-pid.cfg file inside /load directory In this way, I successfully configured some components except one javax.servlet.Filter implementation. The only difference I found out is, the field of Filter component to be configured is @ServiceProperty, while the fields of other components all is @Property. Is it the real reason? No, that should not matter. Did you try to add 'immediate=true' to your @Component ? I tried, but failed again. Now, component defination is by annotation, instance creation is by meta.xml, and component configuration is by FileInstall *.cfg. Maybe it's because of the complex order of instance creation, configuration and update? I'll debug into felix more deeply. Regards, drhades Regards, Clement Regards, drhades
ipojo @ServiceProperty field cannot be configured by FileInstall?
I configured some ipojo components by FileInstall, as following: 1) install ConfigAdmin, FileInstall; 2) set the managedservice attribute, @Component(managedservice=com-pid); 3) create com-pid.cfg file inside /load directory In this way, I successfully configured some components except one javax.servlet.Filter implementation. The only difference I found out is, the field of Filter component to be configured is @ServiceProperty, while the fields of other components all is @Property. Is it the real reason? Regards, drhades
Re: iPOJO vs SCR vs Blueprint
+1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone like myself is seeing this question occur regularly on this mailing list. It's a valid question that perhaps we can dedicate a wiki/web page to with the pros and cons. I myself have many questions and can't really tell which is best for our needs at directory but I do know that I have to sit down and do the research. However our situation is much more unique since we back configuration information needed to wire the server inside a LDIF/LDAP based backing store. Lots to think about for us. Excuse the digression on our specific issues but regarding having a page dedicated to the pros and cons of each option at felix could benefit many of our users. Best, Alex
Re: iPOJO vs SCR vs Blueprint
On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham n...@apache.org wrote: Alasdair Nottingham On 25 May 2011, at 22:16, Richard S. Hall he...@ungoverned.org wrote: On 5/25/11 16:26, Alasdair Nottingham wrote: Hi, This is good I might link to it, or pinch it for the aries webpage too if that is ok. When doing that thought I would put some changes into the blueprint column. The Aries blueprint implementation provides some value add that would change some of the No's into Yes's. Sure. One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-) Of course if you were an expert you would know how much better it is than anything else ;) let the religious flame war begin, or not. In fact, casual users wish for an almighty expert who knows all solutions in-depth and exposes them to all. If there's no such expert, the second best method is, experts of different solutions advertise themself and compare with each other. Maybe that can be called religious flame war, but it's valuable. What we really need in open community is simple and perfect product in technology, but not many repeat manufacturing wheels like some outside companies. Regards, drhades - richard Thanks Alasdair On 25 May 2011 15:29, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 9:19, Richard S. Hall wrote: We actually have a table in our book (OSGi in Action) that tries to compare the features...perhaps I could re-create that table on a web page... Ok, I added the table to the iPOJO FAQ on wiki: https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F It's not perfect, but it is better than nothing. It should eventually propagate to our static pages. Clement, please double check the iPOJO features, since you've added features since the book has been published. - richard On 5/25/11 5:26, jie yan wrote: +1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone like myself is seeing this question occur regularly on this mailing list. It's a valid question that perhaps we can dedicate a wiki/web page to with the pros and cons. I myself have many questions and can't really tell which is best for our needs at directory but I do know that I have to sit down and do the research. However our situation is much more unique since we back configuration information needed to wire the server inside a LDIF/LDAP based backing store. Lots to think about for us. Excuse the digression on our specific issues but regarding having a page dedicated to the pros and cons of each option at felix could benefit many of our users. Best, Alex
Re: iPOJO vs SCR vs Blueprint
On Thu, May 26, 2011 at 10:38 AM, Richard S. Hall he...@ungoverned.orgwrote: On 05/25/2011 09:23 PM, jie yan wrote: Maybe that can be called religious flame war, but it's valuable. What we really need in open community is simple and perfect product in technology, but not many repeat manufacturing wheels like some outside companies. When implementing any software there are design trade-offs as well as different focuses and goals. So, even though the wheel may look like a reinvention, it is not generally the exact same wheel, only similar. While it would be great if we could always agree on a single design and set of trade-offs, the likelihood of that is slim. I agree with that. The current problem maybe that, we cannot easily see enough information about the trade-offs of each design and comparisons of them. We can also dive into the application and implementation of each solution, to find out the better one, to love and support one of them, or even to reinvent a better one based on existing design. While that's quite high cost, if there are no enough comparative information about design trade-offs that can be easily accessed. Regards, drhades - richard Regards, drhades - richard Thanks Alasdair On 25 May 2011 15:29, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 9:19, Richard S. Hall wrote: We actually have a table in our book (OSGi in Action) that tries to compare the features...perhaps I could re-create that table on a web page... Ok, I added the table to the iPOJO FAQ on wiki: https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F It's not perfect, but it is better than nothing. It should eventually propagate to our static pages. Clement, please double check the iPOJO features, since you've added features since the book has been published. - richard On 5/25/11 5:26, jie yan wrote: +1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone like myself is seeing this question occur regularly on this mailing list. It's a valid question that perhaps we can dedicate a wiki/web page to with the pros and cons. I myself have many questions and can't really tell which is best for our needs at directory but I do know that I have to sit down and do the research. However our situation is much more unique since we back configuration information needed to wire the server inside a LDIF/LDAP based backing store. Lots to think about for us. Excuse the digression on our specific issues but regarding having a page dedicated to the pros and cons of each option at felix could benefit many of our users. Best, Alex
Re: [jira] [Created] (FELIX-2967) file-based log service wanted
Thank Felix.
Sling Commons Log bundle is simple and fairly usable.
Just need to throw the Jar into ${FELIX}/bundle directory, and specify some
logging configuration in config.properties.
Regards,
drhades
On Mon, May 23, 2011 at 6:09 PM, Felix Meschberger fmesc...@adobe.comwrote:
Hi,
You might also want to look into the Sling Commons Log bundle [1]: This
is a single bundle solution providing OSGi LogService, SLF4J, Log4J, and
commons logging APIs writing to files by default and configurable
through Configuration Admin (and with framework properties for basic
setup).
Regards
Felix
[1] http://sling.apache.org/site/logging.html
Am Montag, den 23.05.2011, 04:00 +0100 schrieb drhades (JIRA):
file-based log service wanted
-
Key: FELIX-2967
URL: https://issues.apache.org/jira/browse/FELIX-2967
Project: Felix
Issue Type: New Feature
Components: Log Service
Reporter: drhades
Log information is critical during debugging and maintenance.
Now, the log service sub-project only provides memory-based
implementation.
And, the pax or other log implementations are quite difficult to be
installed and used.
Do people here have a plan to improve the current log service to support
file-logging?
Really looking forward.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira
iPOJO vs SCR vs Blueprint
I wonder what is the difference between these three component runtime. Is there the best one which can take over the others, then we could focus attention on just one solution? Regards, drhades
Re: new feature request: iPOJO component-flow-composition
On Mon, May 23, 2011 at 1:14 PM, Clement Escoffier clement.escoff...@gmail.com wrote: On 23.05.11 04:48, jie yan yanjie.ch...@gmail.com wrote: Thank Clement. Cilia is quite close to what I want. Another question about iPOJO is, how to specify the @Requires service when there are multi-implementation? That may be another subject. If the injected field is an array or a collection, iPOJO automatically inject all providers. On @Bind method, you can specify aggregate=true. Sorry, I didn't express clearly. What I wondered is, for example: Component-A requires service MyService; While there are two implementations in the framework, MyServiceImpl-1 and MyServiceImpl-2; Is it possible to specify which implementation to be used in Component-A? The triggering scene is: I have two web bundle, WB-1 serving /w1,and WB-2 serving /w2; WB-1 and WB-2 have their own HttpContext implementations, that dispatch the requests into different directory; These two HttpContext implementation have similar logic, but different mapping directory; So, I try to create two HttpContext service instance with different property, and specify the required instance in WB-1 and WB-2; Is it reasonable? Regards, drhades Regards, Clement Regards, drhades On Thu, May 19, 2011 at 3:13 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, On 18.05.11 13:47, jie yan yanjie.ch...@gmail.com wrote: I enjoyed iPOJO very much, although just using it for 2 weeks. iPOJO provides a charming component runtime. Is it convenient to extend iPOJO to support component-flow-composition? The imaginary flow-composition is data-driven, without loop flow-control. Just think SPSS clementine, or Weka knowledge-flow. So, iPOJO provides an event-admin handler for asynchronous communications, but it's not really what you're looking for. You should have a look at Cilia (http://wikiadele.imag.fr/index.php/Cilia) which provides, on the top of iPOJO, something close to what you want. Regards, Clement Looking forward to some guidance. Best regards, drhades
Re: new feature request: iPOJO component-flow-composition
Thank Clement very much. Regards, drhades On Mon, May 23, 2011 at 8:05 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, On 23.05.11 09:16, jie yan yanjie.ch...@gmail.com wrote: On Mon, May 23, 2011 at 1:14 PM, Clement Escoffier clement.escoff...@gmail.com wrote: On 23.05.11 04:48, jie yan yanjie.ch...@gmail.com wrote: Thank Clement. Cilia is quite close to what I want. Another question about iPOJO is, how to specify the @Requires service when there are multi-implementation? That may be another subject. If the injected field is an array or a collection, iPOJO automatically inject all providers. On @Bind method, you can specify aggregate=true. Sorry, I didn't express clearly. What I wondered is, for example: Component-A requires service MyService; While there are two implementations in the framework, MyServiceImpl-1 and MyServiceImpl-2; Is it possible to specify which implementation to be used in Component-A? The triggering scene is: I have two web bundle, WB-1 serving /w1,and WB-2 serving /w2; WB-1 and WB-2 have their own HttpContext implementations, that dispatch the requests into different directory; These two HttpContext implementation have similar logic, but different mapping directory; So, I try to create two HttpContext service instance with different property, and specify the required instance in WB-1 and WB-2; Is it reasonable? You have the 'from' attribute allowing to select the instance providing the service you want: @Requires(from=instance-name) You just need to specify the instance name when creating your instance: @Instance(name=instance-name) Regards, Clement Regards, drhades Regards, Clement Regards, drhades On Thu, May 19, 2011 at 3:13 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, On 18.05.11 13:47, jie yan yanjie.ch...@gmail.com wrote: I enjoyed iPOJO very much, although just using it for 2 weeks. iPOJO provides a charming component runtime. Is it convenient to extend iPOJO to support component-flow-composition? The imaginary flow-composition is data-driven, without loop flow-control. Just think SPSS clementine, or Weka knowledge-flow. So, iPOJO provides an event-admin handler for asynchronous communications, but it's not really what you're looking for. You should have a look at Cilia (http://wikiadele.imag.fr/index.php/Cilia) which provides, on the top of iPOJO, something close to what you want. Regards, Clement Looking forward to some guidance. Best regards, drhades
How to find JDBC Driver class in a bundle?
With the help of some engineers in Karaf forum, I've wrapped an Oracle
driver bundle.
But I can't find the suitable way to create a JDBC driver in my Oracle
client bundle.
Attempt 1:
1) Import-Packageoracle.jdbc/Import-Package
2) Class.forName(oracle.jdbc.OracleDriver);
Failed.
Attempt 2:
1) Import-Packageoracle.jdbc/Import-Package
2) static{
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
}
Failed.
How could I do?
Regards,
drhades
Re: new feature request: iPOJO component-flow-composition
Thank Clement. Cilia is quite close to what I want. Another question about iPOJO is, how to specify the @Requires service when there are multi-implementation? That may be another subject. Regards, drhades On Thu, May 19, 2011 at 3:13 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, On 18.05.11 13:47, jie yan yanjie.ch...@gmail.com wrote: I enjoyed iPOJO very much, although just using it for 2 weeks. iPOJO provides a charming component runtime. Is it convenient to extend iPOJO to support component-flow-composition? The imaginary flow-composition is data-driven, without loop flow-control. Just think SPSS clementine, or Weka knowledge-flow. So, iPOJO provides an event-admin handler for asynchronous communications, but it's not really what you're looking for. You should have a look at Cilia (http://wikiadele.imag.fr/index.php/Cilia) which provides, on the top of iPOJO, something close to what you want. Regards, Clement Looking forward to some guidance. Best regards, drhades
new feature request: iPOJO component-flow-composition
I enjoyed iPOJO very much, although just using it for 2 weeks. iPOJO provides a charming component runtime. Is it convenient to extend iPOJO to support component-flow-composition? The imaginary flow-composition is data-driven, without loop flow-control. Just think SPSS clementine, or Weka knowledge-flow. Looking forward to some guidance. Best regards, drhades
