aspose file tools*
The moose likes Other Application Frameworks and the fly likes OSGi ain't the only way to modularize your apps Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "OSGi ain Watch "OSGi ain New topic
Author

OSGi ain't the only way to modularize your apps

Sai Hegde
security forum advocate
Ranch Hand

Joined: Oct 26, 2010
Posts: 200
    
    1

You could use IOC enforcement during your build process.
So, why OSGi then???
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
Sai Hegde wrote:You could use IOC enforcement during your build process.
So, why OSGi then???


That is just a programming practice, you get no enforcement. But using IoC is definitely a good practice too.
Joachim Rohde
Ranch Hand

Joined: Nov 27, 2006
Posts: 423

As you've mentioned implicitly you need to rebuild your application. With OSGi you can change - in theory - dependencies during runtime. See also: http://www.osgi.org/About/WhyOSGi
Sai Hegde
security forum advocate
Ranch Hand

Joined: Oct 26, 2010
Posts: 200
    
    1

Nice.
Greg Funston
Ranch Hand

Joined: Feb 09, 2011
Posts: 81

Thanks for the link. OSGi looks like an excellent technology.

Cheers,
Greg Funston SCJP
Stuart McCulloch
author
Greenhorn

Joined: Feb 14, 2011
Posts: 21
Sai Hegde wrote:You could use IOC enforcement during your build process. So, why OSGi then???

Actually I personally believe the best way to use OSGi is with IoC, then you can get the advantages of OSGi but you're not tied to the framework
Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
Stuart McCulloch wrote:
Sai Hegde wrote:You could use IOC enforcement during your build process. So, why OSGi then???

Actually I personally believe the best way to use OSGi is with IoC, then you can get the advantages of OSGi but you're not tied to the framework


Yes. I use OSGi with Spring. My modules have most of the time, at the code level no dependencies to OSGi (via activators) or even Spring. So I like this approach as these are pretty framework independent POJOs.

I do my OSGi service registration at the Spring level, and bean creation in Spring too.

This also eliminates the needs for Activators in many cases, you can create a Spring bean and mark what method to call at startup.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Yes. I use OSGi with Spring. My modules have most of the time, at the code level no dependencies to OSGi (via activators) or even Spring. So I like this approach as these are pretty framework independent POJOs.


ummh I thought ogsi was a runtime thing meaning no imports in my class.


Groovy
Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
Pradeep bhatt wrote:
Yes. I use OSGi with Spring. My modules have most of the time, at the code level no dependencies to OSGi (via activators) or even Spring. So I like this approach as these are pretty framework independent POJOs.


ummh I thought ogsi was a runtime thing meaning no imports in my class.


Not sure what you mean.

But if you use an Activator, and also want to mess around with BundleContext to register a service, you need to import some OSGi specific classes.
Stuart McCulloch
author
Greenhorn

Joined: Feb 14, 2011
Posts: 21
Pradeep bhatt wrote:
Yes. I use OSGi with Spring. My modules have most of the time, at the code level no dependencies to OSGi (via activators) or even Spring. So I like this approach as these are pretty framework independent POJOs.

ummh I thought ogsi was a runtime thing meaning no imports in my class.

Depending on what parts of OSGi you want to use, and whether you use other abstractions on top of OSGi you may (or may not) need to import OSGi packages. You don't have to add any imports to take advantage of the modularity layer.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanks. I was concerned whether osgi api import is required for modularity.
Mike Van
Ranch Hand

Joined: Apr 06, 2006
Posts: 83
Pradeep bhatt wrote:Thanks. I was concerned whether osgi api import is required for modularity.


Pradeep,

Most of the heavy lifting with OSGi is found in the META-INF/MANIFEST.MF file. Using Maven and the maven-bundle-plugin, this file will be largely created for you without a lot of extra work on your part. When we (OSGi folks) talk about "importing" a class or package inside of an OSGi bundle, what we're usually referring to is the Import-Package directive within the MANIFEST.MF file, not the actual import statements in your code. I can go in more detail about this (using Karaf and Felix) if you'd like.

Think of OSGi modularity like this. A bundle deployed inside of OSGi only knows about the class files, spring, aries, jaxb, etc files that it contains. If your bundle needs to use the functionality provide by another bundle, this needs to be identified in your MANIFEST.MF file. For example, if you have a service that makes JMS available to your OSGi container, and you have a bundle that needs to use JMS, you would grab a reference to that service via Aries or SpringDM, and use IOC to inject the service into your bundle. On a side note, I've found that using Camel along with OSGi is pure win, as it contains camel components for JMS and like services out-of-the-box. All you have to do is set it up in SpringDM or Aries, and BLAMMO, its available to all of your camel routes.

Hope that helps clear things up.


Mike Van
If at first you don't succeed, try, try again. Unless you really suck at it. Then, you might just want to try something else, if you dont' want to be a loser I mean.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OSGi ain't the only way to modularize your apps