Re: Karaf and Transaction Control Service Specification
Hi Alex, yes it is possible to use tx-control with Karaf, we have been using it on v4.0.5 in our production system for about 18 months with no issues. One of the main reasons we use tx-control is that is it 'backed' by a standard. Rightly or wrongly we also didn't have confidence in Aries JPA Template at the time we were considering transaction managment solutions to manage our transactions in a production environment (perhaps this was misguided) but we were concerned that there were few integrated tests for that project where as there are over 2000 lines of test code for tx-control which demonstrate sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins, commit, rollback depending upon exception type and much more. I think the enRoute project has some examples https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and the tx-control test code is worth looking at. Tim -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: JPA (Hibernate) with Apache Karaf 4.2
Hi Alex, while I recognise this does not answer your question I thought it might help being that you stated you are new OSGi and you asked "as there are better practices for persistence in OSGi?" Are you aware of the broader OSGi landscape regarding Declarative Services/Bluerprint/POJO/Everit components/CDI + other. If you come to a point where you are about to embark upon a significant piece of work it may pay to do some reading on this. Not a great analogy but it would be a bit like starting with an example based on JEE not knowing that the Spring framework existed. You may latter have then wished you had known about the Spring framework to make a more strategic decision as to what framework you wanted to base your application. The example you are working with is based upon Aries Blueprint, the are other examples based upon DS e.g the enRoute example https://enroute.osgi.org/tutorial/032-tutorial_microservice-jpa.html, each has it's pros and cons. The following is worth a read http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-td4045845.html Regards, Tim Jones -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Multiple bundles dependencies injection (pax-cdi or blueprint)
This is a bit long winded but as you are new to OSGi before you make your next step ... As you have probably realised by now there are a few ways of achieving your goal, it can be difficult trying to distill the information on the Web and come up with the 'best' way to wire up services between bundles. Even in this one thread three different ways have been mentioned, Pax-CDI, Blueprint (of which there are 2 flavours) and Declarative Services, there are others not mentioned. Unfortunately you are unlikely to get a general consensus as to the best way forward and even that may depend on what you are ultimately trying to achieve. But some of the things that you may want to take into consideration before opting for a particular technology is whether it is widely used, backed by a specification e.g. OSGi Alliance, has there been any recent enhancements to the specification, are there any new specifications that may effect your decision, does the technology offer the life cycle dynamics that OSGi can provide. Take CDI for example, as mentioned above there is already an implementation, Pax-CDI, the OSGi Alliance has also a published https://github.com/osgi/design/blob/master/rfcs/rfc0193/rfc-0193-CDI-Integration.pdf, how will this effect the Pax-CDI project? Is there another implementation on its way? Take Aries Blueprint, it is widely used but from my understanding the Blueprint specification has not been touched for 5 years or so since it was first released in OSGi 4.2. Take Declarative Services as another example, this technology is widely used, has recent specification enhancements, is enthusiastically promoted by the founder of the enroute project (http://enroute.osgi.org/), promoted by the bndtools community, but at the moment takes a bit more work to integrate with other technologies such as CXF, Camel than say Aries Blueprint, although I think there is good work going on in these projects to make it easier. Another consideration is although it may be seemingly possible to do something in a certain way, can you have a high level of confidence that the library has extensive tests to support it. As an example, my company recently engaged Paremus to write the the tx-control project which underpins the transaction management of our system, there are over 3500 lines of test code in that project. I think you would agree that for something as fundamental as transactional management of persistence you really want a high level of confidence that it does work and wont be easily inadvertently broken in later releases (obviously unashamedly trying to convince you of the merits of tx-control :) Hope this helps, Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Multiple-bundles-dependencies-injection-pax-cdi-or-blueprint-tp4049756p4049776.html Sent from the Karaf - User mailing list archive at Nabble.com.
SpringMVC V4 + Karaf
Hi, I am looking for a solution for integrating a war based upon SpringMVC V4+ with Karaf/Jetty. Currently we have a working web app based upon SpringMVC/Security/Mobile V3 that uses SpringDM running on Karaf 2.3.2. We would like to continue with Spring but upgrade to version 4. I was wondering if perhaps Achim with your pax-web experience or others had any thoughts on the following approach. By instructing the maven-bundle-plugin to use instead of then the blueprint-spring-extender (https://github.com/apache/aries/tree/trunk/blueprint/blueprint-spring-extender, thanks Guillaume) would be used to process the Spring namespaced config file e.g org.apache.felix maven-bundle-plugin WEB-INF/track-trace-servlet.xml This much I have done and I can log the Spring beans in the application context and the osgi services to the Karaf console. However the Spring DispatcherServlet still needs to be registered and I thought that this could perhaps be achieved by programmatically implementing Springs WebApplicationInitializer (http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/WebApplicationInitializer.html). Assuming that the servlet container was able to find the class implementing the WebApplicationInitializer would this be sufficient? If so, any pointers on how to coax the servlet container to scan and find the customised WebApplicationInitializer? Thanks, Tim -- View this message in context: http://karaf.922171.n3.nabble.com/SpringMVC-V4-Karaf-tp4047917.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: What to use with Karaf : blueprint or Spring
Have a read of http://karaf.922171.n3.nabble.com/Spring-vs-Blueprint-td4035374.html I assume you mean SpringDM as opposed to using the Spring libraries alone. Support for SpringDM has been discontinued and of the box SpringDM only supports up to but not including Spring V4. There is some recent work on using Spring name spaces within Blueprint see http://mail-archives.apache.org/mod_mbox/aries-dev/201511.mbox/%3ccaa66tppfyb33d7m234ddeugxa6dj5jv24m09vv7u77dbjlo...@mail.gmail.com%3E so it may be possible to use Spring V4 libraries within Blueprint. I am not familar enough with Blueprint to answer if it is as 'powerful' as Spring but I am sure my son would be able to tell you which Super Hero would win. Although Blueprint would probably provide the path of least resistance if you are intending migrating from SpringDM, there are other alternatives such as Declarative Services which is worth giving serious consideration. Tim -- View this message in context: http://karaf.922171.n3.nabble.com/What-to-use-with-Karaf-blueprint-or-Spring-tp4047359p4047376.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Does bundle uninstall release the memory?
Hi Srikanth, in my experience it will depend on the bundle. Although we use SpringDM and found permgen issues with CGLIB, for the same reason any bundle could be susceptable to permgen leaks. Some more details here - http://karaf.922171.n3.nabble.com/A-few-observations-about-permgen-class-loader-leaks-td4028707.html. Tracking down what is causing the leak isn't usually too hard, follow something like https://cdivilly.wordpress.com/2012/04/23/permgen-memory-leak/, but fixing it may be more difficult if it is due to a third party library. Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Does-bundle-uninstall-release-the-memory-tp4046447p4046457.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Blueprint or DS or what to use?
I realise rereading my post that it may have been a little ambiguous as to which direction we have taken => we have decided that Declarative Services will be the best solution for us long term. -- View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045922.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Blueprint or DS or what to use?
Andreas you are crossing or about to cross a bridge we are crossing at the moment. We also have a SpringDM based application. It is 3+ years in production and so a change as large as moving away from SpringDM is very disruptive. For the most part we considered only Aries Blueprint vs DS. However as you can see from this post there are other alternatives, some fairly recent such as support for Spring namespaces in Aries Blueprint. For us the most significant points to consider were 1) Will there still be good support in 5-10 years (having been burnt once we don't want face the same issue again) 2) Where is the general OSGi community heading? Blueprint/DS/other. The first sentence of Tim Ward's post is something we thought significant. Something that has concerned me over the last couple of years is sometimes an alternative is suggested by needs some jiggery pokery to make it work, it doesn't have wide support, little documentation, often has bugs which led to a churn of releases. While it may be a cool, clever solution we aren't going to bet our production system on cool and clever only. 3) We are by and large glue coders and don't have the ability nor want to spend the time/resource building our own custom solutions, this is where I think Spring has suited us well until now. We tried to identify what offerings were available for the bits we needed e.g. JPA, JDBC, transactional control, Camel JMS, CXF. It is an opinion only, but from what I could see Blueprint offered the broadest support (see Christian's ecosystems-compared http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider). The big one for us was lack of JPA/JDBC/transactional control for DS, while there were some solutions we wanted something with a 'spec behind it'. This is currently been worked on at the moment (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a significant piece of work that will make DS a much more attractive proposition in the enterprise/applications space. Admittedly there is a risk in being new adopter however we think the risk is worth it in this case. Camel has a recent DS offering camel-scr (although I think there are some issues with it). Hopefully in time more libraries will offer DS support out of the box. 4) We are not yet sure we will be able to fully realise the pros of the service dynamics that DS offers vs Blueprint as although one of our goals is to be able to 'hot swap' bundles into a running system this may be harder to achieve than we had hoped. We currently do some limited hot swapping with our SpringDM system. 5) Perhaps counter intuitively of less importance to us was the actual ease of transition, Blueprint would almost certainly be easier to migrate to from SpringDM but we think that this is a one off cost that will be outweighed in the long term. Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Enable Load Time Weaving with karaf 4.x
Not sure if you are asking how to weave in general or just in Karaf 4 but if you are interested in the current state of play of weaving and OSGi have a read of https://mail.osgi.org/pipermail/osgi-dev/2016-February/thread.html (subject: Monitor method calls for a bundle?) Chetan Mehrotra's response references a URL that might be useful. We are on Karaf 2.3.1/Felix/SpringDM and use weaving hooks + Javassist primarily for aiding in database auditing, so definitely possible in Karaf 2.3. -- View this message in context: http://karaf.922171.n3.nabble.com/Enable-Load-Time-Weaving-with-karaf-4-x-tp4045454p4045515.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Problem with Karaf 4.0.3 and Postgres db
Not sure why you have to use \ as we (running on Linux + hibernate/4.3.6.Final) use the following osgi.jdbc.driver.name=PostgreSQL JDBC Driver-pool-xa url=jdbc:postgresql://localhost:5432/ databaseName= serverName=localhost portNumber=5432 user= password= dataSourceName= However I did notice you are using PostgreSQL 9.4 JDBC4.1 (build 1200), we struck this bug https://github.com/pgjdbc/pgjdbc/pull/257 -- View this message in context: http://karaf.922171.n3.nabble.com/Problem-with-Karaf-4-0-3-and-Postgres-db-tp4044862p4044882.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Updating an existing bundle on Karaf
Have you tried refreshing bundles B,C and D? http://karaf.apache.org/manual/latest-2.3.x/commands/osgi-refresh.html -- View this message in context: http://karaf.922171.n3.nabble.com/Updating-an-existing-bundle-on-Karaf-tp4036634p4036643.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring vs Blueprint
In other words are you saying that Spring DM will use the same class loader for all bundles as opposed to a different class loader for each bundle? -- View this message in context: http://karaf.922171.n3.nabble.com/Spring-vs-Blueprint-tp4035374p4035584.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring vs Blueprint
Richard, these links don't explain the differences between Spring DM and Blueprint but may help make up your mind, although note that since some of the statements were made things may have changed. In summary it doesn't appear clear (to me at least) where Spring-OSGI is heading, certainly some concerns over support for Spring 4 and OSGI. Our application is based on Spring DM (decision made a few years ago) however given the landscape as it is today I doubt whether we would have made the same decision. -- Peter Kriens pro Declarative services - DS is much better in working with services than Blueprint/Spring DM since they tend to to want to hide the dynamicity http://stackoverflow.com/questions/10008786/osgi-blueprint-vs-spring-dm -- Spring and OSGI http://karaf.922171.n3.nabble.com/OSGI-and-Spring-td4033211.html#a4033254 -- Spring and OSGI http://karaf.922171.n3.nabble.com/Re-The-future-of-the-Spring-with-Fabric8-td4033455.html -- We should also make clear that Spring DM is dead. And that in general Spring on OSGi is not a good idea https://github.com/fabric8io/fabric8/issues/1634 -- Spring stops creating OSGI bundles http://stackoverflow.com/questions/21181154/where-can-i-find-spring-4-osgi-bundles http://www.eclipse.org/forums/index.php/t/513222/ -- Spring 4 + Gemini incompatibility https://www.eclipse.org/forums/index.php/t/642416/ -- I would be really careful with Gemini blueprint. Springsource seems to have completely abondoned OSGi. -- So I fear that Gemini blueprint will go the same way as spring dm which is not maintained at all http://stackoverflow.com/questions/20993870/most-suitable-osgi-platform/21013910#21013910 -- I somehow doubt that gemini blueprint is still active. See git.eclipse.org/c/gemini.blueprint/… -- Not sure how active aries blueprint is. http://stackoverflow.com/questions/22381205/osgi-declarative-services-and-spring -- View this message in context: http://karaf.922171.n3.nabble.com/Spring-vs-Blueprint-tp4035374p4035389.html Sent from the Karaf - User mailing list archive at Nabble.com.
Confusion with installing and refreshing bundles
After reading http://karaf.922171.n3.nabble.com/bundle-refresh-td4032433.html I am confused with Freeman's answer you do need refresh bundleA, this will cause all bundles depending on bundleA refresh(re-resolved) also. Can someone please clarify the expected behaviour as we are not seeing the osgi:refresh command refresh dependent bundles as described e.g given Bundle A version 1.2.0 Bundle B version 1.2.0 where bundle B references services in A (i.e. B dependent upon A) If I install and start a new Bundle A version 1.2.1 then refreshing Bundle A does not seem to rewire the dependent bundle B (logging the OsgiApplicationEvents via a OsgiBundleApplicationContextListener also shows no dependent bundles being refreshed). But if I refresh bundle B then the later version 1.2.1 of bundle A is now referenced from B. -- View this message in context: http://karaf.922171.n3.nabble.com/Confusion-with-installing-and-refreshing-bundles-tp4035197.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: bundle:refresh
Can you please clarify the expected behaviour as we are not seeing the osgi:refresh command refresh dependent bundles as you described e.g given Bundle A version 1.2.0 Bundle B version 1.2.0 where bundle B references services in A (i.e. B dependent upon A) If I install and start a new Bundle A version 1.2.1 then refreshing Bundle A does not seem to rewire the dependent bundle B. But if I refresh bundle B then the later version 1.2.1 of bundle A is now referenced from B. Logging the OsgiApplicationEvents via a OsgiBundleApplicationContextListener also shows no dependent bundles being refreshed. -- View this message in context: http://karaf.922171.n3.nabble.com/bundle-refresh-tp4032433p4035106.html Sent from the Karaf - User mailing list archive at Nabble.com.
Weaving hook called multiple times, is this the expected behavior?
--- | Bundle A || Bundle D | | || | | AbstractBaseClassToBeWoven || MyWeavingHook | | ^ (woven once) || (weaves into classes | | | || in Bundle A ) | | | |--- | AbstractClassToBeWoven | | ^ ^ (woven twice) | ---|---| / \ / \ / \ / \ / \ / \ --|--- --| | Bundle B | || | Bundle C | | | || || | FirstSubClassOfWovenClass || SecondSubClassOfWovenClass | | || | -- --- Hi, I am trying to implement a weaving hook. I am able to successfully weave into the class AbstractBaseClassToBeWoven but when I try to weave into the sub class AbstractClassToBeWoven the overidden method weave(WovenClass wovenClass) in MyWeavingHook is usually* invoked twice by two different Blueprint Extender threads causing issues e.g. when trying to add a new method it complains about the method already being present. If however I weave into the super class AbstractBaseClassToBeWoven, the overidden method weave(WovenClass wovenClass) in MyWeavingHook is only invoked once. Is this the expected behaviour? If so, what is the best way of weaving into the AbstractClassToBeWoven class ie. weaving into a class where multiple classes in different bundles extend that same class? Note - 1) if I do not install Bundle C then method weave(WovenClass wovenClass) is only invoked once 2) *occassionally when weaving into AbstractClassToBeWoven the method weave(WovenClass wovenClass) is only invoked once I have set up a two Felix/Karaf Pax Exam test cases, one blueprint, and one Spring DM and both have the same behaviour. (also posted to Felix User forum a couple of weeks ago but no replies http://apache-felix.18485.x6.nabble.com/Weaving-hook-called-multiple-times-is-this-the-expected-behavior-td5009331.html) Thanks, Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Weaving-hook-called-multiple-times-is-this-the-expected-behavior-tp4034834.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Scheduler status?
Brandon, before you go to far down the track it might be best to access what capabilities you need for your scheduler. For example Quartz offers the ability to - trigger jobs (via simple/cron triggers) at a certain time of day (to the millisecond) on certain days of the week on certain days of the month on certain days of the year not on certain days listed within a registered Calendar (such as business holidays) repeated a specific number of times repeated until a specific time/date repeated indefinitely repeated with a delay interval - persistent job store to survive server crashes - associate listeners to job start/stop events etc - the behaviour of miss fire events (e.g. server down when a job is scheduled to run) can be altered -- View this message in context: http://karaf.922171.n3.nabble.com/Scheduler-status-tp4034750p4034783.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGI and Spring
Says me trying to absolve myself of all responsibility- I should have probably said arguments that have been presented to me range from 'There are probably many arguments against using Spring ranging from Spring oriented technologies have a very unmodular streak in them' ... I personally don't know enough about the internals of Spring or OSGI to comment one way or the other but I can tell you that the person who made the comment is widely regarded as an expert in OSGI so probably has sound reason for making such a comment. Although having said that I have been involved with a Spring-dm/Felix/Karaf project for a while and think we have been reasonably well served by Spring-dm up until now. I think the context of the comment was probably made looking from the perspective of an OSGI purest. I am also keen to see a good Spring-OSGI integration story both from a selfish motivation in that we have significant investment in Spring-dm but also more importantly I think it will help the uptake of OSGI given the current size of the Spring user base. -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033648.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGI and Spring
I am adding a few URLs as I think it is will be of interest to others who are looking for direction re the future of Spring and OSGI -- Somehow I wonder how well future spring versions will behave in OSGi. I think we should start to at least warn our users that continued use of spring in OSGi is an increasing risk. http://karaf.922171.n3.nabble.com/Spring-OSGi-bundles-no-longer-being-released-td4031212.html -- Are we really going to let die the Spring integration with OSGi? http://karaf.922171.n3.nabble.com/Re-The-future-of-the-Spring-with-Fabric8-td4033455.html -- We should also make clear that Spring DM is dead. And that in general Spring on OSGi is not a good idea https://github.com/fabric8io/fabric8/issues/1634 -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033485.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGI and Spring
So to summarise, if Gemini was to become no longer viable, then as it stands at the moment, post Spring 3, it will not be possible to use the Spring namespace in Karaf without re-packaging the spring-dm bundles or altering the manifest for the version range as mentioned by Achim (http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tt4033093.html#a4033176)? -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033252.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGI and Spring
Thanks Charlie, I wasn't aware of the deltaspike-jpa @Transactional annotation. Though I am a bit concerned reading posts such as https://groups.google.com/forum/#!topic/ops4j/-yNNwvz5yNY that it is still a bit early to adopt as an alternative. I don't see how you can continue using spring-security with the Blueprint beans wiring mechanism as I thought it would require a Spring application context e.g. for a method annotated with @PreAuthorize would this not require a Spring application context to work? So given that 'Blueprint does not aim to replace the entire Spring framework, only the bean wiring stuff' then what is the migration path for a Spring dependent application post Spring 3 as Spring-dm out of the box only supports [2.5.6,4)? -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033227.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGI and Spring
I am not sure that will help as even though the JDK doesn't have permgen the leaks are classloader leaks e.g. a class loaded by the class loader can't be collected due to some thing having a reference to it, this class has a reference to the class loader which in turn means all other classes loaded by the class loader can't be collected. Summed up here http://www.infoq.com/news/2013/03/java-8-permgen-metaspace 'In the end, classloader leaks can still occur as before'. The main culprit we have found is CGLIB which is widely used by Spring. -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033232.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGI and Spring
I have been trying to follow a few posts on Gemini blueprint and Karaf and was aware it is on the road map and it looks promising. I am a bit concerned (perhaps unfairly) about the future level of testing of Gemini blueprint with Karaf as up until now I thought Karaf was very much Aries based. Is support for Gemini blueprint on Karaf going to receive as much attention as Aries? -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033233.html Sent from the Karaf - User mailing list archive at Nabble.com.
OSGI and Spring
I am interested to hear views on where OSGI and Spring is heading. I realise this is a fairly broad topic but I think is worth discussing. I have noticed that a lot of answers on this forum and others suggest not using Spring but instead Blueprint or Declarative Services, particularly if starting from scratch. There are probably many arguments against using Spring ranging from 'Spring oriented technologies have a very unmodular streak in them' through to less active participation by SpringSource after ceasing work on their own OSGI container. However Spring has been adopted by many projects throughout the world, particularly in applications development. I have struggled to find good migration guides helping move a project from Spring to OSGI without Spring. For example there have been a few guides http://www.oracle.com/technetwork/articles/java/springtojavaee-522240.html to move from Spring to JEE. Is anyone aware of similar guides for migrating to OSGI. Take the project I currently work on as an example which uses Karaf/Felix + Spring + Camel + other. Spring is used amongst other things to anotate transactions, anotate classes (Component, Service, Repository, ManagedResource etc), autowire beans, reduce JDBC complexity (JdbcTemplate etc), define Camel routes, Spring security, Spring MVC, define transaction managers and data sources. This list is probably typical of many Spring applications. While some of these things have similar Blueprint/DS counter parts I would be interested in hearing how others have approached migrating away from Spring e.g. alternatives to anotating transactions? -- View this message in context: http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
I am not sure if I am helping here but the spring-dm feature depends on spring [2.5.6,4) as seen below root features:info spring-dm Description of spring-dm 1.2.1 feature Feature has no configuration Feature has no configuration files Feature depends on: spring [2.5.6,4) so I think uninstalling Spring 3.2.4.RELEASE is going to cause you problems. This is also a concern to us as we have significant investment in Spring + (camel +other) and we don't have a clear migration path post Spring 3. I can also testify to a fair amount of frustration in getting a particular version of Spring to run. Our approach was to redefine (override) the default Spring features and their versions in a custom features file. -- View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033171.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring AOP example in Karaf
Krzysztof, I asked a similar question on the Felix user forum a few months ago and got this reply http://apache-felix.18485.x6.nabble.com/Options-currently-available-for-weaving-in-Felix-td5004386.html. So doesn't look like there was in July. Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Spring-AOP-example-in-Karaf-tp4030442p4030448.html Sent from the Karaf - User mailing list archive at Nabble.com.
Multiple restarts - effect on heap and Perm Gen memory
Hi, I have read a few posts about the subject e.g. http://karaf.922171.n3.nabble.com/Ability-to-self-restart-karaf-WAS-Infamous-permgen-leak-td3589167.html#a3591080. Is it correct that stopping and starting a bundle multiple times will ultimately lead to a PermGen out of memory error (except perhaps when using a JRockit JVM) and that there is no avoiding this? I have set up a test (using the org.apache.sshd packages) that repeatedly stops and starts one of our bundles. About 20 restarts results in a PermGen out of memory error but also what seems surprising is that the heap memory usage, in particular the 'PS Old Gen' keeps increasing. Using JVisualM and comparing the classes before and after 10 restarts and then a garbage collection (invoked by clicking on 'Perform GC' JVisualM) the application classes (classes coded by us) seem to be behaving as I would expect as evidenced by the example below of two classes i.e. the old proxy has been deallocated (-1) and the new allocated (+1) Class name - allocated objects Bytes Objects Allocated uniworks.livestock.compiler.CompileKill.CompileAdviceLine 0B0 uniworks.livestock.compiler.CompileKill.CompileAdviceLine$$EnhancerByCGLIB$$286bdd54 +64 B +1 uniworks.livestock.compiler.CompileKill.CompileAdviceLine$$EnhancerByCGLIB$$4f6d4fc8 -64 B-1 uniworks.livestock.compiler.CompileKill.ProcessCarcases 0B0 uniworks.livestock.compiler.CompileKill.ProcessCarcases$$EnhancerByCGLIB$$c049ad79 +56 B +1 uniworks.livestock.compiler.CompileKill.ProcessCarcases$$EnhancerByCGLIB$$e74b1fed -56 B -1 However many (there are many more than the 4 classes below) of the 3rd party library classes seem to have increasing objects allocated as evidenced below. 5 x restarts (+ GC) Class name - allocated objects Bytes Objects Allocated org.springframework.osgi.service.importer.support.internal.aop.ImportedOsgiServiceProxyAdvice +1,408 B +44 org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource$DefaultCacheKey +3,559,872 B+148,328 org.apache.activemq.command.ActiveMQQueue +39,840 B +996 org.apache.activemq.command.SessionId +55,480 B+1,387 10 x restarts (+ GC) Class name - allocated objects Bytes Objects Allocated org.springframework.osgi.service.importer.support.internal.aop.ImportedOsgiServiceProxyAdvice +3,168 B +99 org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource$DefaultCacheKey +8,008,968 B+333,707 org.apache.activemq.command.ActiveMQQueue +44,280 B+1,107 org.apache.activemq.command.SessionId +114,160 B+2,854 a) Are the results above what is expected or is there an issue with our code/3rd party libraries holding on to references when it shouldn't? For us the primary driver for choosing OSGI was actually a business driver and was the promise of 'hot deployment' (although as a developer I recognise other technical benefits of choosing an enabler for a modular architecture). How far can we go with hot deployment? b) It looks as though there will always be an upper bound of the number of times a bundle can be stopped and started due to the class meta data being added into the Perm Gen space? c) Even if the Perm Gen issue was solved it looks as though there are issues with objects unable to be GCed, if these are caused by 3rd party libraries there is probably little we can do to fix this so again there will be an upper bound to the number of bundle retarts before a server restart is necessary? -- View this message in context: http://karaf.922171.n3.nabble.com/Multiple-restarts-effect-on-heap-and-Perm-Gen-memory-tp4028550.html Sent from the Karaf - User mailing list archive at Nabble.com.
Advice on the best method/practice for taking advantage of using Karaf to install bug fixes into a production environment
Hi, I am looking for advice on the best method/practice for taking advantage of using Karaf to install bug fixes into a production environment. The scenario we face is a dozen or so sites running Karaf with what is essentially a customised product. These sites are spread across the country but are connected via a network (which in some cases is fairly slow) and communicate with each other. OSGI/Karaf was chosen so as to provide the possibility of 'hot deploying' bug fixes while trying cause minimal disruption to a system that controls/monitors PLCs, label readers + other on a food processing floor. Currently the deliverable is a large zip file containing a directory structure that includes a slightly bastardised copy of the Karaf directories/files (doesn't include the bin directory + the 3rd party and application bundles have been added below the osgi/system directory). Karaf is started programmatically via org.apache.karaf.main.Main.main(). The bundles required are defined in a features file. Currently a change requires the zip file to be FTPed to the sites, unzipped, the Karaf server shut down, symbolic links changed to point to the new installation and the server restarted from a custom shell script which in turn runs a class that invokes org.apache.karaf.main.Main.main(). Obviously this process has many downsides and certainly wont address minimising disruption to the food processing plants. Given that a bundle may have a bug what processes/practices are others using to getting their modified bundle into a production environment? For example we could a) FTP the bundle to the site and use the Karaf console to install and update/refresh the necessary bundle b) Set up a repository server (we use Nexus) at each site that mirrors our one and refresh that then use the Karaf console to install and update/refresh the necessary bundle c) Would the sub project Karaf Cave help here? What is the best way of keeping track of what bundles are actually running at each site? For example given that each site could potentially be running different versions of the same bundle would you rely on say dumping out all the bundle headers to say essentially 'these are the versions of the bundles that are currently running at this site'? Since we rely on the features file essentially 'defining' what our application is comprised of, how do we coordinate this with the newly installed bundle? Should the features file at the site be updated to reflect the new version of the bundle? Any other advice, things to consider would be most welcome. thanks, Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Advice-on-the-best-method-practice-for-taking-advantage-of-using-Karaf-to-install-bug-fixes-into-a-pt-tp4028520.html Sent from the Karaf - User mailing list archive at Nabble.com.
Guidance on integrated testing solutions
Hello, firstly apologies upfront if any of my terminology is incorrect, I am newbie to OSGI and struggling with the concepts. I am working on a project that uses Karaf with Felix to provide OSGI based services that service a Swing GUI client. The services have been developed over the past 3 years or so but don't have any automated integration tests. My goal is to be able to run integration tests within a continuous integration tool such as Jenkins. I am looking for guidance on possible integration test solutions. I have tried to implement a test using Pax Exam and had a brief look at SpringDM but I am having difficulty provisioning the required bundles. The project consists of about a dozen maven modules which build OSGI bundles. There are some custom configuration properties files with properties such as org.osgi.framework.system.packages.extra and org.osgi.framework.system.packages, also an XML file specifying the features. I am not sure that I fully understand but it seems to me that in order to get Pax Exam to test these bundles I must necessarily specify all of bundles that the bundle in question to test requires e.g. given a bundle called 'broker' using maven coordinates I would have do something like the following . . . mavenBundle().groupId( org.springframework ).artifactId( spring-beans ) mavenBundle().groupId( org.springframework ).artifactId( spring-tx ) mavenBundle().groupId( uniworks ).artifactId( broker ) I have seen cases with someone has written a method to try and read files from a directory to try and reduce the manual work but these solutions seem a poor fit for our requirements as the project depends on 100+ external libraries most of which are OSGIsed, and some not, which are specified in the org.osgi.framework.system.packages.extra property. The analogy I would like to describe is integration testing with the Spring framework (AbstractTransactionalSpringContextTests or similar) where often the configuration application context files used in production can be reused verbatim (with a few changes, say different database) when running the tests. This to me seems to provide a huge advantage over having to restate and constantly maintain the 'configuration' needed to test the classes. I started to look at http://felix.apache.org/site/apache-felix-ipojo-junit4osgi-maven.html which if I understand correctly should allow tests to be run against the bundles as they are currently configured. So provided the OSGI bundles can be started before the maven integration-test phase, say in the pre-integration-test phase, then the tests should be able to be implemented without having to specifically specify all the required bundles and config files needed to start the dozen or so bundles to perform the integration test. Note that I am not interested (at least at the moment) in testing a bundle in isolation so the 'running' system as whole (connects to database(s), legacy COBOL server(s)) is required to complete a test. Please, I do not want to get into a philosophical debate on testing in general i.e. whether you have a opinion on testing systems in their entirety or more finely grained. Am I on the right track with iPOJO? Are there better/other alternatives? Thanks, Tim -- View this message in context: http://karaf.922171.n3.nabble.com/Guidance-on-integrated-testing-solutions-tp4025742.html Sent from the Karaf - User mailing list archive at Nabble.com.
