Re: Spring-DM web and pax web extender bundle processing order in 2.2.7
That's a quite big problem and I'm not really aware of any way to control the extender execution order. The reason is that each extender can work synchronously or asynchronously and there's no coordination between them, there's not even a way to specify such a thing. I can only see two ways out: * enhance the extenders to better cooperate, but this would require enhancing all the extenders and defining some metadata to control such an order (given anyone can write an extender, this would be better if we had a spec for that) * do the synchronization on your own, i.e. you can detect using a spring bean when the spring app will be processed and from a servlet when the web app stuff will be kicked, then make sure one is waiting for the other. The last option is the easiest one to achieve obviously, but will be really tied to the extenders your using and how they behave, as if both are started synchronously, you won't really have any way to do some synchronization here, but iirc that's not the case here. On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta rocketra...@gmail.com wrote: I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now the Spring DM web extender and pax web extender's no longer run in the correct order. The Spring-DM extender needs to process the bundle *before* the PaxWeb extender, since until the app context is created by Spring-DM it is a non-functional web bundle. If Pax Web attempts to process it first, there is an error about the Spring context not existing when the servlet tries to initialize. A manual refresh of the bundle is required to fix the problem. One difference I can see between 2.2.4 and 2.2.7 is that the start level of the pax bundles is different. In Karaf 2.2.4, the pax bundles started at the default start level which was 60, but in 2.2.7 the war feature specifies they start at the same level as the Spring-DM bundles, which is 30. I don't know if that is the underlying problem though. Is there a way to control the order of the extender execution? If not, what is the best work-around? Regards, Raman -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Spring-DM web and pax web extender bundle processing order in 2.2.7
Hi I just can second Guillaume here, there is only one more thing that crosses my mind. Pax Web needs to support Injecting OSGi Services into the Servlets, see also [1]. But as usual this kind of stuff is needed much earlier then implemented :) regards, [1] - http://team.ops4j.org/browse/PAXWEB-367 2012/6/25 Guillaume Nodet gno...@gmail.com: That's a quite big problem and I'm not really aware of any way to control the extender execution order. The reason is that each extender can work synchronously or asynchronously and there's no coordination between them, there's not even a way to specify such a thing. I can only see two ways out: * enhance the extenders to better cooperate, but this would require enhancing all the extenders and defining some metadata to control such an order (given anyone can write an extender, this would be better if we had a spec for that) * do the synchronization on your own, i.e. you can detect using a spring bean when the spring app will be processed and from a servlet when the web app stuff will be kicked, then make sure one is waiting for the other. The last option is the easiest one to achieve obviously, but will be really tied to the extenders your using and how they behave, as if both are started synchronously, you won't really have any way to do some synchronization here, but iirc that's not the case here. On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta rocketra...@gmail.com wrote: I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now the Spring DM web extender and pax web extender's no longer run in the correct order. The Spring-DM extender needs to process the bundle *before* the PaxWeb extender, since until the app context is created by Spring-DM it is a non-functional web bundle. If Pax Web attempts to process it first, there is an error about the Spring context not existing when the servlet tries to initialize. A manual refresh of the bundle is required to fix the problem. One difference I can see between 2.2.4 and 2.2.7 is that the start level of the pax bundles is different. In Karaf 2.2.4, the pax bundles started at the default start level which was 60, but in 2.2.7 the war feature specifies they start at the same level as the Spring-DM bundles, which is 30. I don't know if that is the underlying problem though. Is there a way to control the order of the extender execution? If not, what is the best work-around? Regards, Raman -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: Installing Hadoop bundle in Apache Felix Gogo shell
Deploying hadoop in OSGi is not a simple task, and wether you use Gogo or not isn't really the problem. Gogo just enables you to install bundles using a command instead of using the osgi api, but as I said, the problem isn't really here. So Hadoop isn't OSGi ready at all. I worked on it a few weeks ago, so you can try to build Fuse Fabric locally https://github.com/fusesource/fuse/tree/master/fabric/fabric-hadoop and try to deploy the hadoop feature (or all the bundles listed manually) https://github.com/fusesource/fuse/blob/master/fabric/fuse-fabric/src/main/resources/fabric-features.xml#L368 On Mon, Jun 25, 2012 at 10:25 AM, somya singhal 28somyasing...@gmail.com wrote: Hello I have recently learned to successfully deploy bundles with the help of Apache Felix Gogo command shell.Now i am trying to install a Hadoop bundle with the help of Apache Felix Gogo command shell.I have tried searching web pages to get clear steps for installing the same but i am unable to find.Can anyone please help me to know the correct steps for installing the Hadoop bundle with the help of Apache Felix Gogo command shell? With Regards Somya Singhal -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Spring-DM web and pax web extender bundle processing order in 2.2.7
Thanks Guillaume and Achim... I will investigate the manual synchronization route. Does Pax-web initialize each servlet synchronously? If so, I can create a dummy servlet that initializes before the main servlet that can wait for the initialization of the Spring context. I also found this post by Peter Krien's responding to a similar query from someone on the Felix mailing list, and suggesting a similar solution: http://mail-archives.apache.org/mod_mbox/felix-users/201004.mbox/%3cf5b8b3e9-5602-4caf-9d4f-904fb947b...@aqute.biz%3E In Krien's solution, rather than manually detecting when a Spring bean has been initialized, I believe he his suggesting exposes the servlet itself as a service from the Spring context. When this service is available, the dummy servlet being initialized by the web extender sees it and proceeds (I guess this would depend on Pax-Web processing the dummy servlet first and synchronously). If that approach works, that would be some functionality that Pax-Web could use to manage this issue with requiring changes in other extenders. A manifest header could control whether Pax-Web waits for some service to be available before proceeding with the servlet initialization. This would skip the need to manually create the dummy servlet. Regards, Raman On 06/25/2012 04:12 AM, Achim Nierbeck wrote: Hi I just can second Guillaume here, there is only one more thing that crosses my mind. Pax Web needs to support Injecting OSGi Services into the Servlets, see also [1]. But as usual this kind of stuff is needed much earlier then implemented :) regards, [1] - http://team.ops4j.org/browse/PAXWEB-367 2012/6/25 Guillaume Nodet gno...@gmail.com: That's a quite big problem and I'm not really aware of any way to control the extender execution order. The reason is that each extender can work synchronously or asynchronously and there's no coordination between them, there's not even a way to specify such a thing. I can only see two ways out: * enhance the extenders to better cooperate, but this would require enhancing all the extenders and defining some metadata to control such an order (given anyone can write an extender, this would be better if we had a spec for that) * do the synchronization on your own, i.e. you can detect using a spring bean when the spring app will be processed and from a servlet when the web app stuff will be kicked, then make sure one is waiting for the other. The last option is the easiest one to achieve obviously, but will be really tied to the extenders your using and how they behave, as if both are started synchronously, you won't really have any way to do some synchronization here, but iirc that's not the case here. On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta rocketra...@gmail.com wrote: I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now the Spring DM web extender and pax web extender's no longer run in the correct order. The Spring-DM extender needs to process the bundle *before* the PaxWeb extender, since until the app context is created by Spring-DM it is a non-functional web bundle. If Pax Web attempts to process it first, there is an error about the Spring context not existing when the servlet tries to initialize. A manual refresh of the bundle is required to fix the problem. One difference I can see between 2.2.4 and 2.2.7 is that the start level of the pax bundles is different. In Karaf 2.2.4, the pax bundles started at the default start level which was 60, but in 2.2.7 the war feature specifies they start at the same level as the Spring-DM bundles, which is 30. I don't know if that is the underlying problem though. Is there a way to control the order of the extender execution? If not, what is the best work-around? Regards, Raman -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Spring-DM web and pax web extender bundle processing order in 2.2.7
I think Peter's solution is a nice one, as spring (and blueprint) has the ability to wait until all services are satisfied before actually creating the full spring app. That would only work if you need it that way though (i.e. spring app started after the web app). On Mon, Jun 25, 2012 at 4:14 PM, Raman Gupta rocketra...@gmail.com wrote: Thanks Guillaume and Achim... I will investigate the manual synchronization route. Does Pax-web initialize each servlet synchronously? If so, I can create a dummy servlet that initializes before the main servlet that can wait for the initialization of the Spring context. I also found this post by Peter Krien's responding to a similar query from someone on the Felix mailing list, and suggesting a similar solution: http://mail-archives.apache.org/mod_mbox/felix-users/201004.mbox/%3cf5b8b3e9-5602-4caf-9d4f-904fb947b...@aqute.biz%3E In Krien's solution, rather than manually detecting when a Spring bean has been initialized, I believe he his suggesting exposes the servlet itself as a service from the Spring context. When this service is available, the dummy servlet being initialized by the web extender sees it and proceeds (I guess this would depend on Pax-Web processing the dummy servlet first and synchronously). If that approach works, that would be some functionality that Pax-Web could use to manage this issue with requiring changes in other extenders. A manifest header could control whether Pax-Web waits for some service to be available before proceeding with the servlet initialization. This would skip the need to manually create the dummy servlet. Regards, Raman On 06/25/2012 04:12 AM, Achim Nierbeck wrote: Hi I just can second Guillaume here, there is only one more thing that crosses my mind. Pax Web needs to support Injecting OSGi Services into the Servlets, see also [1]. But as usual this kind of stuff is needed much earlier then implemented :) regards, [1] - http://team.ops4j.org/browse/PAXWEB-367 2012/6/25 Guillaume Nodet gno...@gmail.com: That's a quite big problem and I'm not really aware of any way to control the extender execution order. The reason is that each extender can work synchronously or asynchronously and there's no coordination between them, there's not even a way to specify such a thing. I can only see two ways out: * enhance the extenders to better cooperate, but this would require enhancing all the extenders and defining some metadata to control such an order (given anyone can write an extender, this would be better if we had a spec for that) * do the synchronization on your own, i.e. you can detect using a spring bean when the spring app will be processed and from a servlet when the web app stuff will be kicked, then make sure one is waiting for the other. The last option is the easiest one to achieve obviously, but will be really tied to the extenders your using and how they behave, as if both are started synchronously, you won't really have any way to do some synchronization here, but iirc that's not the case here. On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta rocketra...@gmail.com wrote: I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now the Spring DM web extender and pax web extender's no longer run in the correct order. The Spring-DM extender needs to process the bundle *before* the PaxWeb extender, since until the app context is created by Spring-DM it is a non-functional web bundle. If Pax Web attempts to process it first, there is an error about the Spring context not existing when the servlet tries to initialize. A manual refresh of the bundle is required to fix the problem. One difference I can see between 2.2.4 and 2.2.7 is that the start level of the pax bundles is different. In Karaf 2.2.4, the pax bundles started at the default start level which was 60, but in 2.2.7 the war feature specifies they start at the same level as the Spring-DM bundles, which is 30. I don't know if that is the underlying problem though. Is there a way to control the order of the extender execution? If not, what is the best work-around? Regards, Raman -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Best way to test blueprint-based applications with Karaf?
Hi there, I've started to work on a blueprint-based application, and basically the subject already says what I'm looking for :-) I googled around a little bit and found the following two blogposts that seem interesting: http://iocanel.blogspot.de/2012/01/advanced-integration-testing-with-pax.html http://gnodet.blogspot.de/2012/01/unit-testing-camel-blueprint-routes.html The library provided by Guillaume looks like a possible solution, but I'd like to ask if there is anything that I overlooked in my search and that might be helpful when testing blueprint contexts Any other suggestions or hints regarding the topic are highly welcome as well. Best regards Jerry
Re: Best way to test blueprint-based applications with Karaf?
Hi Gerald, I suggest sticking to testing with pax-exam or even better using paxexam-karaf. I have the following reasons for this :) If you want to use blueprint jpa or something like this, I experienced trouble with pojoSR not being capable of providing some needed functionality for the jpa part of blueprint. It uses some internal OSGi method which resolves to a null-pointer exception. So this is not really capable for doing intense tests right now. (if I find some time I might add some patches :) ) But it's good enough to test some basic blueprint wiring stuff. pax-exam is far better in usage since it really starts a container though this might increase the timing on the test. Though this can be some troublesome to get all required bundles working together this way. It needs some trial and error to have the right set of bundles available :) Though right now I also face an issue with this setup and blueprint:jpa. A rather strange Classcast excpetion. Somehow the javax.persistence Classes used by blueprint-jpa while instanciating the Entity objects is not the same when trying to find the corresponding meta-data. Somehow the Entity class used in both cases are not the same (classloader issue :( ) Now finally if you use paxexam-karaf you have all the required bundles at hand and if you use jpa it magically seems to work right away (no idea what the difference is right now, still investigating :) ) And of course if you are gonna use specialties in setup etc. this test-framework gives you just the right amount of power to get along :) Hope this helps some :) regards, Achim 2012/6/25 Gerald Preissler gpreiss...@talend.com: Hi there, I've started to work on a blueprint-based application, and basically the subject already says what I'm looking for :-) I googled around a little bit and found the following two blogposts that seem interesting: http://iocanel.blogspot.de/2012/01/advanced-integration-testing-with-pax.html http://gnodet.blogspot.de/2012/01/unit-testing-camel-blueprint-routes.html The library provided by Guillaume looks like a possible solution, but I'd like to ask if there is anything that I overlooked in my search and that might be helpful when testing blueprint contexts Any other suggestions or hints regarding the topic are highly welcome as well. Best regards Jerry -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Eventadmin as deploy seems to restart framework
Hi folks, I seem to have a strange issue with Karaf 2.2.7. I know eventadmin can be installed as a feature (or as a boot feature), but if I deploy org.apache.felix.eventadmin-1.2.14.jar into the deploy folder, I get a strange restart behaviour. Karaf seems to: - Come up to the point I get a console prompt - Immediately stop all bundles - Immediately restart all bundles, and I get a new console banner and prompt. The log at level INFO seems to show, for instance Service MBeans being registered, then deregistered, then registered again. This may be a known restriction or caveat, but I couldn't find any other cases of this even after googling. I'm using a freshly-untarred Karaf 2.2.7 on OSX with Java 7 (1.7.0_04), and the only thing in the deploy directory is eventadmin, (Felix EA 1.2.14). If anyone can shed any light on this I'd be grateful; we're trying to come up with a bundle set which doesn't rely on features, so we'd like to deploy eventadmin too. If this seems to be unknown, naturally I'll open a bug for it. Many thanks everyone, -John
Re: Spring-DM web and pax web extender bundle processing order in 2.2.7
I'm looking at the second solution below (manual synchronization). The Spring side is easy -- I can create a bean in the context with an init-method attribute that therefore knows when the Spring context has been created. On the servlet side I have created a common servlet called ExtenderOrderingServlet and set it to load first using the load-on-startup parameter. The only place I've found that I can do the wait is in the constructor of ExtenderOrderingServlet, since the order in which the init() method is called does not appear to respect the load-on-startup parameter: init() is called on the other servlets despite the wait in ExtenderOrderingServlet. Doing this in the constructor sucks though since I cannot provide any contextual information to the servlet regarding the name of the context to wait for, which means I have to create one of these waiter servlets for *each* web bundle instead of using a common one. Regards, Raman On 06/25/2012 03:21 AM, Guillaume Nodet wrote: That's a quite big problem and I'm not really aware of any way to control the extender execution order. The reason is that each extender can work synchronously or asynchronously and there's no coordination between them, there's not even a way to specify such a thing. I can only see two ways out: * enhance the extenders to better cooperate, but this would require enhancing all the extenders and defining some metadata to control such an order (given anyone can write an extender, this would be better if we had a spec for that) * do the synchronization on your own, i.e. you can detect using a spring bean when the spring app will be processed and from a servlet when the web app stuff will be kicked, then make sure one is waiting for the other. The last option is the easiest one to achieve obviously, but will be really tied to the extenders your using and how they behave, as if both are started synchronously, you won't really have any way to do some synchronization here, but iirc that's not the case here. On Mon, Jun 25, 2012 at 6:21 AM, Raman Gupta rocketra...@gmail.com wrote: I just upgraded to Karaf 2.2.7 from Karaf 2.2.4 and noticed that now the Spring DM web extender and pax web extender's no longer run in the correct order. The Spring-DM extender needs to process the bundle *before* the PaxWeb extender, since until the app context is created by Spring-DM it is a non-functional web bundle. If Pax Web attempts to process it first, there is an error about the Spring context not existing when the servlet tries to initialize. A manual refresh of the bundle is required to fix the problem. One difference I can see between 2.2.4 and 2.2.7 is that the start level of the pax bundles is different. In Karaf 2.2.4, the pax bundles started at the default start level which was 60, but in 2.2.7 the war feature specifies they start at the same level as the Spring-DM bundles, which is 30. I don't know if that is the underlying problem though. Is there a way to control the order of the extender execution? If not, what is the best work-around? Regards, Raman
how to bind jaxrs:server to default http service
Hi all,
Is it possible to bind a jaxrs:server definition in a blueprint file to the
default karaf http service?
e.g. whenever I do something like the example below, it fails due to a port
conflict with the default service.
jaxrs:server id=myREST address=/${archiveRestPath}
jaxrs:serviceBeans
ref component-id=mybean/
/jaxrs:serviceBeans
/jaxrs:server
If so, is it possible to even further extend the default service with
providers and interceptors?
Thanks,
-- Rick
adding dependency as a system package
I am getting this error Caused by: java.lang.NoClassDefFoundError: org/apache/thrift/transport/TTransportException Caused by: java.lang.ClassNotFoundException: org.apache.thrift.transport.TTransportException not found by me.prettyprint.hector [193] I have provided all the required dependencies, but for some reason , there is one '*libthrift*' that can not be found by the server during runtime. I am not sure if what I attempted below is right and please correct me if there is a right way. in the config.properties file , I added org.osgi.framework.system.packages.extra=libthrift-0.6.1; version=0.6.1 also I copied the jar in apache-karaf-2.2.7/lib folder this did not help, but I am not sure what is the right way to make karaf aware of libthrift. I also tried to install it as a bundle, but it did not help. What I am trying to accomplish is to add org.apache.thrift / libthrift to this list on System.getProperty(java.class.path) /home/ramesh/Documents/osgiFramework/apache-karaf-2.2.7/lib/karaf-jaas-boot.jar:/home/ramesh/Documents/osgiFramework/apache-karaf-2.2.7/lib/karaf.jar Any help would be appreciated regards, Ramesh
[ANN] Apache Karaf 2.2.8 Released!
The Karaf team is pleased to announce the release of Karaf version 2.2.8. Apache Karaf is a small OSGi distribution which provides a ready to use container for server side applications. This release of Apache Karaf is based off of the 2.2.x series branch, representing an update to Apache Karaf 2.2.7. It contains bug fixes identified in the prior release, and introduces improvements including; A command that can not be loaded no longer breaks the whole completion, removing a KAR now uninstalls the shipped features, and SSH keystore is now compatible with IBM JDK. Several dependences were also updated, bringing ServiceMix Specs to version 2.0, pax-logging to 1.6.7, Jansi to 1.9, JLine to 2.7, Felix Utils to 1.2.0, Felix FileInstall to 3.2.4, and sshd to 0.7.0. http://karaf.apache.org/ This release is available from http://karaf.apache.org/index/community/download.html#Karaf2.2.8 and Maven: dependency groupIdorg.apache.karaf/groupId artifactIdapache-karaf/artifactId version2.2.8/version /dependency Release Notes: There are 28 resolved issues included in this release, as such we've documented them on the 2.2.8 release notes page: http://karaf.apache.org/index/community/download/karaf-2.2.8-release.html For those interested in a detailed look at the dependencies in Karaf 2.2.8 you may review the Karaf 2.2.x dependencies table: http://karaf.apache.org/index/documentation/karaf-dependencies/karaf-deps-2.2.x.html Enjoy!
Re: adding dependency as a system package
On 06/25/2012 05:11 PM, David Jencks wrote: On Jun 25, 2012, at 5:16 PM, ramesh chandra wrote: I am getting this error Caused by: java.lang.NoClassDefFoundError: org/apache/thrift/transport/TTransportException Caused by: java.lang.ClassNotFoundException: org.apache.thrift.transport.TTransportException not found by me.prettyprint.hector [193] I have provided all the required dependencies, but for some reason , there is one '*libthrift*' that can not be found by the server during runtime. I am not sure if what I attempted below is right and please correct me if there is a right way. in the config.properties file , I added org.osgi.framework.system.packages.extra=libthrift-0.6.1; version=0.6.1 also I copied the jar in apache-karaf-2.2.7/lib folder this did not help, but I am not sure what is the right way to make karaf aware of libthrift. I also tried to install it as a bundle, but it did not help. What I am trying to accomplish is to add org.apache.thrift / libthrift to this list on System.getProperty(java.class.path) um, why? does hector code do some bizarre classloading ritual rather than new TTransportException(...)? Since you are having so much trouble, I'd advise you to construct a bundle that includes both the hector code and the thrift code. There are lots of examples of repackaging-to-bundles maven projects in geronimo/bundles and servicemix. You can also study bnd documentation and examples to see how to use Private-Package and/or Include-Resource headers to get bnd to include packages from the thrift bundle. You might also show us the manifests from your attempts to wrap these bundles. thanks david jencks /home/ramesh/Documents/osgiFramework/apache-karaf-2.2.7/lib/karaf-jaas-boot.jar:/home/ramesh/Documents/osgiFramework/apache-karaf-2.2.7/lib/karaf.jar Any help would be appreciated regards, Ramesh Thanks David You are right. For now, I am trying to wrap and install as bundle all the dependencies in Hector as it is the only way to not see that error I guess :) But soon I will try to create a common bundle will all dependencies resolved. regards, Ramesh
