Diwakar, Yeah, there are definitely a few rough edges around working with OSGi, but there are also quite a few nice things about. In general, if you're building Camel routes or doing things like you mention with the bean component, you should not have any problems though - things usually get a bit messier when you start doing JDBC or if you are using external libraries that make assumptions about how the classpath is structured. One of the nice things about OSGi is the fact that, if you do things right, you can upgrade/update almost any bundle without introducing downtime to the rest of the system, which is something that would be a lot harder to do with the JAR files you have in the /lib folder of a ServiceMix 3 installation.
I don't expect us to go back to the JBI classloader hierarchy or deployment model. It's not only the container itself, but also a lot of the JBI components we have are a significant overlap in the corresponding Camel components, so there's quite a bit of overhead in developing/maintaining those versus assembling a container with Karaf/CXF/Camel/... and the deployment model for JBI is also quite a bit more involved than simply creating an XML file or a bundle as you would on ServiceMix 4 these days. That being said, there's currently a discussion going on on the dev list as well about how/when to stop working on ServiceMix 3 - feel free to chime in at http://servicemix.396122.n5.nabble.com/DISCUSS-ServiceMix-3-x-EOL-td5713318.html Because of the problems some people are experiencing with OSGi, we have been discussing alternatives for ServiceMix 5 (e.g. a Tomcat-based solution that would allow you to deploy WARs instead) - once we have the ServiceMix 3.x EOL strategy ironed out, we probably want to revisit the future roadmap again and once again, you're definitely welcome to add suggestions for future development (or help our implementing them, obviously ;) ) Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Thu, May 24, 2012 at 8:29 AM, diwakar <[email protected]> wrote: > Hi, > > Few notes on OSGi: > - OSGi is not preferred by all > - Servicemix 5 may support non OSGi based deployment > - Mule is not interested in OSGi http://blogs.mulesoft.org/osgi-no-thanks/ > - Spring is moving away from OSGi > “Rod Johnson (founder of the Spring Framework) during his key notes speech > saying that OSGi was his worse mistake in 8 years” in > > http://forum.springsource.org/showthread.php?106852-What-s-the-future-of-OSGi-and-Spring-DM > - Google trend of OSGi is like JBI > http://www.google.com/trends/?q=osgi and > http://www.google.com/trends/?q=jbi > > Servicemix 3.4: > - Service Unit class loader ensures that each SU can load its own version > of > the JAR > - No need for OSGi-fied 3pp jars > - Shared jars can be put into the shared library or the smx/lib folder > - Service Assembly can be stopped/started like OSGi bundles > - Servicemix-bean component can be used with simple bean as follows: > import javax.annotation.PostConstruct; > import javax.annotation.PreDestroy; > public class Test { > @PostConstruct > public void start() { > System.out.println("Start Method > invoked***************************************"); > } > @PreDestroy > public void stop(){ > System.out.println("Destruct Called > ***********************************"); > } > } > - Start() is called when the SA starts (the object is created) > - Stop() is called when the SA stops (the object is destroyed) > > Sample SU/SA is attached. Please let me know your > comment. > > With Best Regards, > Diwakar > http://servicemix.396122.n5.nabble.com/file/n5713347/src-genDirect.zip > src-genDirect.zip > > -- > View this message in context: > http://servicemix.396122.n5.nabble.com/Is-Servicemix-3-4-still-a-good-container-for-applications-tp5713347.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. >
