Re: [DISCUSS] rename maven-bundle-plugin to bnd-maven-plugin
On 28 Feb 2013, at 07:05, fbalicchia wrote: I think it is the best choice to follow the naming convention. What I do not understand is why plugins can't be hosted by Apache The Apache Maven team prefer to keep the maven-NNN-plugin naming for plugins developed and maintained by them (ie. those with groupId org.apache.maven.plugins) whereas Maven plugins developed by other Apache (or non-Apache) projects are encouraged to use NNN-maven-plugin naming. The idea is to help avoid confusion about which plugins are directly supported by Apache Maven team and which are supported elsewhere: http://www.mail-archive.com/users@maven.apache.org/msg128850.html While renaming the plugin would be a courtesy to the Apache Maven team, it is not mandatory if it would cause problems for downstream users - hence this discussion thread. HTH -- Cheers, Stuart Thanks Regards --Filippo 2013/2/27 Stuart McCulloch mccu...@gmail.com Hi folks, Now that we've got a 2.x version of bndlib in Maven Central (http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C2.0.0.20130123-133441%7Cjar - same level as shipped in bndtools 2) I'm looking to sort out a new release of the maven-bundle-plugin, once I've gone through and triaged the pending issues in JIRA. I also figure that now might be the best time to fix the plugin name according to Maven guidelines: http://maven.apache.org/guides/development/guide-plugin-documentation.html - apparently the name maven-NNN-plugin is supposed to be reserved for plugins hosted by Apache Maven, while plugins hosted elsewhere should use names like NNN-maven-plugin. So along with the upgrade to bndlib 2.x, I'm proposing to change the plugin name to: bnd-maven-plugin which both respects the Maven plugin naming convention, and recognises the bnd code which is actually doing most of the work. WDYT? -- Cheers, Stuart - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: [DISCUSS] rename maven-bundle-plugin to bnd-maven-plugin
It's not completely related to the naming discussion, but more about the relation-ship with maven itself. Is it possible (in a more a less near future) to have bundle type recognized by default by maven ? --G 2013/2/28 Stuart McCulloch mccu...@gmail.com On 28 Feb 2013, at 07:05, fbalicchia wrote: I think it is the best choice to follow the naming convention. What I do not understand is why plugins can't be hosted by Apache The Apache Maven team prefer to keep the maven-NNN-plugin naming for plugins developed and maintained by them (ie. those with groupId org.apache.maven.plugins) whereas Maven plugins developed by other Apache (or non-Apache) projects are encouraged to use NNN-maven-plugin naming. The idea is to help avoid confusion about which plugins are directly supported by Apache Maven team and which are supported elsewhere: http://www.mail-archive.com/users@maven.apache.org/msg128850.html While renaming the plugin would be a courtesy to the Apache Maven team, it is not mandatory if it would cause problems for downstream users - hence this discussion thread. HTH -- Cheers, Stuart Thanks Regards --Filippo 2013/2/27 Stuart McCulloch mccu...@gmail.com Hi folks, Now that we've got a 2.x version of bndlib in Maven Central ( http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C2.0.0.20130123-133441%7Cjar- same level as shipped in bndtools 2) I'm looking to sort out a new release of the maven-bundle-plugin, once I've gone through and triaged the pending issues in JIRA. I also figure that now might be the best time to fix the plugin name according to Maven guidelines: http://maven.apache.org/guides/development/guide-plugin-documentation.html- apparently the name maven-NNN-plugin is supposed to be reserved for plugins hosted by Apache Maven, while plugins hosted elsewhere should use names like NNN-maven-plugin. So along with the upgrade to bndlib 2.x, I'm proposing to change the plugin name to: bnd-maven-plugin which both respects the Maven plugin naming convention, and recognises the bnd code which is actually doing most of the work. WDYT? -- Cheers, Stuart - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: [DISCUSS] rename maven-bundle-plugin to bnd-maven-plugin
On Feb 28, 2013, at 13:43 , Stuart McCulloch mccu...@gmail.com wrote: On 28 Feb 2013, at 07:05, fbalicchia wrote: I think it is the best choice to follow the naming convention. What I do not understand is why plugins can't be hosted by Apache The Apache Maven team prefer to keep the maven-NNN-plugin naming for plugins developed and maintained by them (ie. those with groupId org.apache.maven.plugins) whereas Maven plugins developed by other Apache (or non-Apache) projects are encouraged to use NNN-maven-plugin naming. The idea is to help avoid confusion about which plugins are directly supported by Apache Maven team and which are supported elsewhere: http://www.mail-archive.com/users@maven.apache.org/msg128850.html While renaming the plugin would be a courtesy to the Apache Maven team, it is not mandatory if it would cause problems for downstream users - hence this discussion thread. I would say, our users come first. Renaming the plugin causes them problems for no reason (to them) so let's not do that. Instead, we could also solve this by donating the plugin to the Apache Maven project. Greetings, Marcel - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: [DISCUSS] rename maven-bundle-plugin to bnd-maven-plugin
On 28 Feb 2013, at 12:57, Guillaume Sauthier (OW2/GMail) wrote: It's not completely related to the naming discussion, but more about the relation-ship with maven itself. Is it possible (in a more a less near future) to have bundle type recognized by default by maven ? --G That's an interesting idea - as Marcel mentioned perhaps we could consider donating the maven-bundle-plugin to the Apache Maven project, which would then make it easier (though not a done deal) to add 'bundle' as a core packaging type. This would still involve a change in plugin coordinates (groupId org.apache.felix - org.apache.maven.plugins) but we could look into adding a relocation in the pom.xml to assist users and if we were able to get the 'bundle' packaging recognized by default then migration would mostly involve removing elements from the pom.xml I'll start a new thread to discuss the contribution idea - just a reminder that nothing has been decided at this point, I want to get wide enough feedback before starting a vote thread. 2013/2/28 Stuart McCulloch mccu...@gmail.com On 28 Feb 2013, at 07:05, fbalicchia wrote: I think it is the best choice to follow the naming convention. What I do not understand is why plugins can't be hosted by Apache The Apache Maven team prefer to keep the maven-NNN-plugin naming for plugins developed and maintained by them (ie. those with groupId org.apache.maven.plugins) whereas Maven plugins developed by other Apache (or non-Apache) projects are encouraged to use NNN-maven-plugin naming. The idea is to help avoid confusion about which plugins are directly supported by Apache Maven team and which are supported elsewhere: http://www.mail-archive.com/users@maven.apache.org/msg128850.html While renaming the plugin would be a courtesy to the Apache Maven team, it is not mandatory if it would cause problems for downstream users - hence this discussion thread. HTH -- Cheers, Stuart Thanks Regards --Filippo 2013/2/27 Stuart McCulloch mccu...@gmail.com Hi folks, Now that we've got a 2.x version of bndlib in Maven Central ( http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C2.0.0.20130123-133441%7Cjar- same level as shipped in bndtools 2) I'm looking to sort out a new release of the maven-bundle-plugin, once I've gone through and triaged the pending issues in JIRA. I also figure that now might be the best time to fix the plugin name according to Maven guidelines: http://maven.apache.org/guides/development/guide-plugin-documentation.html- apparently the name maven-NNN-plugin is supposed to be reserved for plugins hosted by Apache Maven, while plugins hosted elsewhere should use names like NNN-maven-plugin. So along with the upgrade to bndlib 2.x, I'm proposing to change the plugin name to: bnd-maven-plugin which both respects the Maven plugin naming convention, and recognises the bnd code which is actually doing most of the work. WDYT? -- Cheers, Stuart - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
[DISCUSS] contribute maven-bundle-plugin to Apache Maven
During the [DISCUSS] rename maven-bundle-plugin to bnd-maven-plugin thread Marcel and Guillaume came up with counter-suggestions involving contributing the maven-bundle-plugin to Apache Maven. This idea has certain advantages - the plugin name would not be an issue (assuming the Maven team were ok with 'bundle'==OSGi, as there are other interpretations of 'bundle' such as resource bundles) and there's then a chance we could get the 'bundle' packaging type recognized by default by Maven (though this wouldn't necessarily be a done deal). It would also mean that people wouldn't need to specify a groupId when adding the plugin to their pom.xml and you could use the short form of the plugin name from the command-line. The disadvantages are this would still involve a change of plugin coordinates (org.apache.felix - org.apache.maven.plugins) and any changes or improvements would have to go through the Apache Maven project. There's also a question of whether the Apache Maven team would accept the contribution... WDYT? -- Cheers, Stuart On 28 Feb 2013, at 13:03, Marcel Offermans wrote: On Feb 28, 2013, at 13:43 , Stuart McCulloch mccu...@gmail.com wrote: On 28 Feb 2013, at 07:05, fbalicchia wrote: I think it is the best choice to follow the naming convention. What I do not understand is why plugins can't be hosted by Apache The Apache Maven team prefer to keep the maven-NNN-plugin naming for plugins developed and maintained by them (ie. those with groupId org.apache.maven.plugins) whereas Maven plugins developed by other Apache (or non-Apache) projects are encouraged to use NNN-maven-plugin naming. The idea is to help avoid confusion about which plugins are directly supported by Apache Maven team and which are supported elsewhere: http://www.mail-archive.com/users@maven.apache.org/msg128850.html While renaming the plugin would be a courtesy to the Apache Maven team, it is not mandatory if it would cause problems for downstream users - hence this discussion thread. I would say, our users come first. Renaming the plugin causes them problems for no reason (to them) so let's not do that. Instead, we could also solve this by donating the plugin to the Apache Maven project. Greetings, Marcel - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Question about accessing component dosgi
Am 27.02.2013 23:25, schrieb Dhiego Abrantes de Oliveira Martins:
Christian,
I follow these steps:
1- Implements AdderService (using @WebService) (interface)
2- Implements AdderServiceImpl (using @WebService) (Provider)
3- deploy item 1 and 2 in a container OSGi 1.
4- Create a *importer bundle* that contains a configuration file to show to
CXF-DOSGi where locale the AdderService using an endpoint.
5- Deploy item 4 to use the WEBSERVICE exported by item3 as a local
bundle.
So, when I try to deploy, I get this warning:
Fev 27, 2013 1:09:58 AM
org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook$DiscoveryCallback
serviceChanged
INFO: Notified - AVAILABLE:
[org.apache.felix.ipojo.remote.adder.AdderService] endpoint id:
5e8f5f57-03d6-44bd-bcaf-f0eeadb5c433
Fev 27, 2013 1:09:58 AM org.apache.cxf.dosgi.dsw.hooks.AbstractClientHook
proxifyMatchingInterface
WARNING: No class can be found for
org.apache.felix.ipojo.remote.adder.AdderService
Did you deploy the AdderService interface on the container where you
want to import the service?
Can you put your project on github or similar. Then I can take a look.
Honestly I personally have not yet used importer bundles. Instead I use
the zookeeper based discovery which is easier to use.
There basically you only need to reference the service in blueprint on
the client side and need no other config per service.
The question is: Its possible use DOSGi with WebServices (REST/SOAP)?
I mean: We can implement a bundle as a webservice and export it by dosgi ?
This is absolutely possible. I have an integration test in place that
works this way.
Christian
Abs,
__
*Dhiego** **Abrantes** de Oliveira Martins*
*Computer Science, M.Sc. Candidate at UFPE*
www.dhiegoabrantes.com
+55 83 .1081
***Any fool can write code that a computer can understand. Good programmers
write code that humans can understand*. (Martin Fowler)
2013/2/27 Christian Schneider ch...@die-schneider.net
You have two options here:
1) Introduce the @Webservice annotation on the interface. CXF-DOSGi will
then automatically use JAXWS/JAXB to export the service. Importing the
service using DOSGi should also work.
If it does not work then this is a bug. Can you give more informations
abbout the problem and eventually open an issue at the CXF-DOSGi jira?
2) Do not change the interface. In this case DOSGi will use the Simple
frontend with the Aegis binding. So you have to change your CXF code to
access the service outside of OSGi use the same frontend and databinding.
Christian
Am 27.02.2013 04:55, schrieb Dhiego Abrantes de Oliveira Martins:
Hi,
I'm exporting a dosgi component as a webservice and I like do access him.
I'm using iPOJO.
*Interface:*
public interface AdderService{
String add();
}
*Provider:*
public class AdderServiceImpl implements AdderService{
public String add(){
return dhiego;
}
}
*Provider metadata.xml*
ipojo
xmlns:xsi=http://www.w3.org/**2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=org.**apache.felix.ipojo
http://felix.apache.org/ipojo/**schemas/CURRENT/core.xsdhttp://felix.apache.org/ipojo/schemas/CURRENT/core.xsd
xmlns=org.apache.felix.ipojo**
instance
component=org.apache.felix.**ipojo.remote.adder.impl.**
AdderServiceImpl
property name=service.exported.**interfaces value=* /
property name=osgi.remote.**configuration.type
value=pojo/
property name=service.exported.**configs value=
org.apache.cxf.ws
/
property name=org.apache.cxf.ws.**address value=
http://localhost:9090/adder; /
/instance
/ipojo
So, I dont want to use dependence injection. Given some architectural
restrictions, I have to call the services as follow:
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.getInInterceptors().**add(new LoggingInInterceptor());
factory.getOutInterceptors().**add(new LoggingOutInterceptor());
factory.setServiceClass(**AdderService.class);
factory.setAddress(http://**localhost:9090/adderhttp://localhost:9090/adder
);
AdderService client = (AdderService) factory.create();
* String a = client.add();*
System.out.println(a);
When the *bold* line is executed, I get this error:
Exception in thread main javax.xml.ws.**WebServiceException: Could
not
find wsdl:binding operation info for web method add.
at org.apache.cxf.jaxws.**JaxWsClientProxy.invoke(**
JaxWsClientProxy.java:112)
at $Proxy30.add(Unknown Source)
at Main.main(Main.java:22)
The cause basically is the AdderService wasn't annotated with @WebService.
If we use the @WebService in interface AdderService, the problem will be
solved. However, the service won't be recongnized when we try to import it
in another container to use it as a distributed osgi component.
Anyone can help me?
Best regards!
__
*Dhiego** **Abrantes*
--
Christian Schneider
http://www.liquid-reality.de
Open Source
Permission to translate your page at http://felix.apache.org/
Dear Sir, I am writing to inquire regarding your web page about Apache Felix Framework Usage Documentation where I have found a lot of useful information. My name is Anja and I'm currently studying at the Faculty of Computer Science in Belgrade. Here is the URL of your article: http://felix.apache.org/site/apache-felix-framework-usage-documentation.html I would like to share it with the people from Former Yugoslav Republics: Serbia, Montenegro, Croatia, Slovenia, Macedonia, Bosnia and Herzegovina. I would be grateful if you could allow me to translate your writing into Serbo-Croatian language, that is used in all Former Yugoslav Republics and to post it on my website. Hopefully, it will help our people to gather some additional knowledge about computing. I hope to hear from you soon. Regards, Anja Skrba an...@webhostinggeeks.com http://science.webhostinggeeks.com/ Tel: +381 62 300604 - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: PAX Logging configuration
Hi I fear you would have to contact the PAX people general (at) ops4j (dot) org. Regards Felix Am 28.02.2013 um 20:56 schrieb lessonz: I have an app wherein I'm deploying the Felix framework and loading in my own bundles and dependency bundles. One of the dependencies I'd like to use is PAX Logging. I get it to deploy just fine, but I can't seem to figure out how to configure the logger. http://team.ops4j.org/wiki/display/paxlogging/How+to+use+Pax+Logging seems to indicate I need to modify the service's internal configuration and build my own custom PAX Logging bundle. Separately, I've seen reference to the ability to specify a logback configuration file, but I'd prefer to use the default log4j logger. Any help would be greatly appreciated. -- Felix Meschberger | Principal Scientist | Adobe - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: PAX Logging configuration
Thanks Felix. On Thu, Feb 28, 2013 at 1:02 PM, Felix Meschberger fmesc...@adobe.comwrote: Hi I fear you would have to contact the PAX people general (at) ops4j (dot) org. Regards Felix Am 28.02.2013 um 20:56 schrieb lessonz: I have an app wherein I'm deploying the Felix framework and loading in my own bundles and dependency bundles. One of the dependencies I'd like to use is PAX Logging. I get it to deploy just fine, but I can't seem to figure out how to configure the logger. http://team.ops4j.org/wiki/display/paxlogging/How+to+use+Pax+Loggingseems to indicate I need to modify the service's internal configuration and build my own custom PAX Logging bundle. Separately, I've seen reference to the ability to specify a logback configuration file, but I'd prefer to use the default log4j logger. Any help would be greatly appreciated. -- Felix Meschberger | Principal Scientist | Adobe - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Question about accessing component dosgi
My code is equals to basic example in ipojo page:
http://felix.apache.org/site/apache-felix-ipojo-dosgi.html
By default, ipojo dosgi is zookeeper based, right?
The only change was @WebService annotation added in AdderService and
AdderServiceProvider.
One more question: A simple bundle can be a Service and a WebService at the
same time?
I mean: Does make sense implements a bundle that behaves as WebService to
export it to another container, but I can use it as a local service?
Can you share with us your test example?
I'm think I'm confused about WebService as a bundle and distributed bundles.
Best regards!
__
*Dhiego** **Abrantes*
2013/2/28 Christian Schneider ch...@die-schneider.net
Am 27.02.2013 23:25, schrieb Dhiego Abrantes de Oliveira Martins:
Christian,
I follow these steps:
1- Implements AdderService (using @WebService) (interface)
2- Implements AdderServiceImpl (using @WebService) (Provider)
3- deploy item 1 and 2 in a container OSGi 1.
4- Create a *importer bundle* that contains a configuration file to show
to
CXF-DOSGi where locale the AdderService using an endpoint.
5- Deploy item 4 to use the WEBSERVICE exported by item3 as a local
bundle.
So, when I try to deploy, I get this warning:
Fev 27, 2013 1:09:58 AM
org.apache.cxf.dosgi.dsw.**hooks.AbstractClientHook$**DiscoveryCallback
serviceChanged
INFO: Notified - AVAILABLE:
[org.apache.felix.ipojo.**remote.adder.AdderService] endpoint id:
5e8f5f57-03d6-44bd-bcaf-**f0eeadb5c433
Fev 27, 2013 1:09:58 AM org.apache.cxf.dosgi.dsw.**
hooks.AbstractClientHook
proxifyMatchingInterface
WARNING: No class can be found for
org.apache.felix.ipojo.remote.**adder.AdderService
Did you deploy the AdderService interface on the container where you want
to import the service?
Can you put your project on github or similar. Then I can take a look.
Honestly I personally have not yet used importer bundles. Instead I use
the zookeeper based discovery which is easier to use.
There basically you only need to reference the service in blueprint on the
client side and need no other config per service.
The question is: Its possible use DOSGi with WebServices (REST/SOAP)?
I mean: We can implement a bundle as a webservice and export it by dosgi ?
This is absolutely possible. I have an integration test in place that
works this way.
Christian
Abs,
__
*Dhiego** **Abrantes** de Oliveira Martins*
*Computer Science, M.Sc. Candidate at UFPE*
www.dhiegoabrantes.com
+55 83 .1081
***Any fool can write code that a computer can understand. Good
programmers
write code that humans can understand*. (Martin Fowler)
2013/2/27 Christian Schneider ch...@die-schneider.net
You have two options here:
1) Introduce the @Webservice annotation on the interface. CXF-DOSGi will
then automatically use JAXWS/JAXB to export the service. Importing the
service using DOSGi should also work.
If it does not work then this is a bug. Can you give more informations
abbout the problem and eventually open an issue at the CXF-DOSGi jira?
2) Do not change the interface. In this case DOSGi will use the Simple
frontend with the Aegis binding. So you have to change your CXF code to
access the service outside of OSGi use the same frontend and databinding.
Christian
Am 27.02.2013 04:55, schrieb Dhiego Abrantes de Oliveira Martins:
Hi,
I'm exporting a dosgi component as a webservice and I like do access
him.
I'm using iPOJO.
*Interface:*
public interface AdderService{
String add();
}
*Provider:*
public class AdderServiceImpl implements AdderService{
public String add(){
return dhiego;
}
}
*Provider metadata.xml*
ipojo
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instancehttp://www.w3.org/**2001/XMLSchema-instance
http:**//www.w3.org/2001/XMLSchema-**instancehttp://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=org.apache.felix.ipojo
http://felix.apache.org/ipojo/schemas/CURRENT/core.xsdhttp://felix.apache.org/ipojo/**schemas/CURRENT/core.xsd
htt**p://felix.apache.org/ipojo/**schemas/CURRENT/core.xsdhttp://felix.apache.org/ipojo/schemas/CURRENT/core.xsd
xmlns=org.apache.felix.ipojo
instance
component=org.apache.felix.ipojo.remote.adder.impl.**
AdderServiceImpl
property name=service.exported.interfaces value=*
/
property name=osgi.remote.configuration.type
value=pojo/
property name=service.exported.configs value=
org.apache.cxf.ws
/
property name=org.apache.cxf.ws.address value=
http://localhost:9090/adder; /
/instance
/ipojo
So, I dont want to use dependence injection. Given some architectural
restrictions, I have to call the services as follow:
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.getInInterceptors().add(new LoggingInInterceptor());
Re: Permission to translate your page at http://felix.apache.org/
Anja I'm only a committer not the project lead, but I really can't see anyone complaining if you help spread the knowledge by translating into your local language, as long as the content is kept faithful after the translation. Apache is all about open source - so in fact, I suspect the licenses we all work under pretty much permit it anyway, but it's always good to ask! Good luck! -- Rob On 28/02/2013 8:36 PM, Anja Skrba wrote: Dear Sir, I am writing to inquire regarding your web page about Apache Felix Framework Usage Documentation where I have found a lot of useful information. My name is Anja and I'm currently studying at the Faculty of Computer Science in Belgrade. Here is the URL of your article: http://felix.apache.org/site/apache-felix-framework-usage-documentation.html I would like to share it with the people from Former Yugoslav Republics: Serbia, Montenegro, Croatia, Slovenia, Macedonia, Bosnia and Herzegovina. I would be grateful if you could allow me to translate your writing into Serbo-Croatian language, that is used in all Former Yugoslav Republics and to post it on my website. Hopefully, it will help our people to gather some additional knowledge about computing. I hope to hear from you soon. Regards, Anja Skrba an...@webhostinggeeks.com http://science.webhostinggeeks.com/ Tel: +381 62 300604 - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ascert - Taking systems to the edge r...@ascert.com +27 21 300 2028 ext 5119 www.ascert.com - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Permission to translate your page at http://felix.apache.org/
I agree and would just ask for a link back to the original page. BTW: you might want to refer to the new page http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.html Regards Felix Am 01.03.2013 um 05:42 schrieb Rob Walker: Anja I'm only a committer not the project lead, but I really can't see anyone complaining if you help spread the knowledge by translating into your local language, as long as the content is kept faithful after the translation. Apache is all about open source - so in fact, I suspect the licenses we all work under pretty much permit it anyway, but it's always good to ask! Good luck! -- Rob On 28/02/2013 8:36 PM, Anja Skrba wrote: Dear Sir, I am writing to inquire regarding your web page about Apache Felix Framework Usage Documentation where I have found a lot of useful information. My name is Anja and I'm currently studying at the Faculty of Computer Science in Belgrade. Here is the URL of your article: http://felix.apache.org/site/apache-felix-framework-usage-documentation.html I would like to share it with the people from Former Yugoslav Republics: Serbia, Montenegro, Croatia, Slovenia, Macedonia, Bosnia and Herzegovina. I would be grateful if you could allow me to translate your writing into Serbo-Croatian language, that is used in all Former Yugoslav Republics and to post it on my website. Hopefully, it will help our people to gather some additional knowledge about computing. I hope to hear from you soon. Regards, Anja Skrba an...@webhostinggeeks.com http://science.webhostinggeeks.com/ Tel: +381 62 300604 - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ascert - Taking systems to the edge r...@ascert.com +27 21 300 2028 ext 5119 www.ascert.com - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Felix Meschberger | Principal Scientist | Adobe - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Question about accessing component dosgi
Hi Dhiego, the ipojo example does not use zookeeper based discovery. It uses a static remote_services.xml file. In case of zookeeper discovery this file would not be necessary. So what you could try is run the ipojo example on Karaf like in my tutorial http://liquid-reality.de/display/liquid/2013/02/13/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi . On the server side you just install the example on the first container. On the client side you leave out the remote_services file. I wonder if that makes a difference. In any case I will also try to get the ipojo example working. I did not yet test it. About @WebService and OSGi service. DOSGi allows to export plain OSGi services as webservices in this case it uses the CXF Simple front end and the Aegis data binding. When you add the @WebService annotation to the interface then it uses the JAX-WS frontend and the JAXB databinding by default. So yes you can have one service impl act as an OSGi service and a web service. You only have to make sure your service design is suitable for remote communication. For example you can have very fine grained OSGi service calls as there is almost no additional overhead compared to a java method call. If your service is intended for remote use it should be more coarse grained. Christian On 01.03.2013 00:47, Dhiego Abrantes de Oliveira Martins wrote: My code is equals to basic example in ipojo page: http://felix.apache.org/site/apache-felix-ipojo-dosgi.html By default, ipojo dosgi is zookeeper based, right? The only change was @WebService annotation added in AdderService and AdderServiceProvider. One more question: A simple bundle can be a Service and a WebService at the same time? I mean: Does make sense implements a bundle that behaves as WebService to export it to another container, but I can use it as a local service? Can you share with us your test example? I'm think I'm confused about WebService as a bundle and distributed bundles. Best regards! __ *Dhiego** **Abrantes* -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
