|Registered:||Apr 06, 2006|
|Given in last 30 days||0|
|Received in last 30 days||0|
|Last 30 days:||0|
Stuart McCulloch wrote:Augusto Sellhorn wrote:Thanks!
Interesting, we're using version 2.0.1 and I wasn't aware of that feature. Probably not turning it on I guess ... (perhaps I have to tell it where the xml files are???)
It should be enabled by default and scan Spring-DM/Blueprint files that end up under META-INF/spring, META-INF/blueprint, or OSGI-INF/blueprint in the final bundle. I think there were some additional improvements in 2.1.0 but if you're still having trouble then send a message to the Apache Felix dev list http://felix.apache.org/site/mailinglists.html as we have several developers that use this feature in their projects (and know more about it than me :).
Richard S. Hall wrote:Raghavan Muthu wrote:
Raghavan Muthu wrote:
3. Would there be any issues with scalability of my Java application? If so how do I address them?
Depends on what sort of scalability. There isn't too much overhead associated with OSGi at execution time, so it should be an issue there. The biggest issue probably relates to the number of modules in a system, but I think most OSGi frameworks could easily handle 100s if not 1000s of modules without too much difficulty.
Currently I use Felix, Karaf, and Camel to manage a system that processes millions of files of data a day. In that real-world application, I found it necessary to break out the major functional pieces of the system and run them in seperate OSGi instances, communicating via JMS. While the issues of scalability were created by our java code, breaking the pieces into seperate VM's works well to handle scalability issues. Oh, and we're running ~170 bundles in each OSGi instance.
Again, Felix + Karaf + Camel (2.5.0+) is a great way to go for back-end processing applications.
Richard S. Hall wrote:Augusto Sellhorn wrote:Richard S. Hall wrote:
The simplest approach is to create one big self-contained bundle, but it depends on your situation.
You mean embedded jars in the bundle? We ended up having to do that after bnd wrapping all dependencies wouldn't work in all cases.
Yes or just expanding them into the bundle, you don't necessarily need to embed the classes in their original JAR files.
Pradeep bhatt wrote:Thanks. I was concerned whether osgi api import is required for modularity.