Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
We are currently developing a new software for which we decided OSGi modularity would be quite useful, as the software itself can be pretty well decomposed into modular structure in order to avoid code mess in the future and be able to easily add new features and hook into existing ones.
I have been playing with two (probably most popular) OSGi platforms, Eclipse Equinox (with Gemini Blueprint) and Apache Felix (with Aries). Basically I am now at the point of making a decision, which one we should use.
We have pretty much experience with Spring, so we would like to continue using that, along with annotations (such as #Autowired for autowiring beans WITHIN the SAME bundle, #ServiceReference for autowiring across bundles), some particular Spring addons (such as Data JPA), Hibernate as a JPA provider (so far, we have experience only with Hibernate as an JPA implementation, it has all features we need so we want to avoid having to switch to something else), JMS messaging (with ActiveMQ client) and few other features.
Later on, we also want to be able to implement our own security manager (to control access to certain bundles, based on e.g. their digital signatures, certificates with Permissions embedded in them)
So far, I have been able to make two testing bundles (one was using a service from the other) and treat them as Spring Beans on Equinox with Gemini BP. However, I've had some problems with annotations, though (and I don't really like wiring beans in XMLs, especially with not so complicated architecture - most of them are Singletons).
I've tried Aries as well (but not succeeded with enabling Spring there; probably just haven't spent enough time on that yet :) ).
Which OSGi platform do you recommend for such use case?
This one will be probably not the best answer but I think it is useful for you if I share my experiences. A couple of years ago I had exactly the same situation. I was experienced with Spring, JPA (Hibernate and EclipseLink). I found OSGi modularity useful so we started projects based on OSGi.
As I had used Spring before, it was obvious to use Blueprint (we ended up using Apache Aries as it was more stable than Gemini Blueprint). We did that for two years. However, we had many issues so I started to implement a new Blueprint container based on the specification. I heard many times that OSGi DS is better but as I had been a Spring fan before, the tutorials did not make me change my mind. I had the feeling that ConfigAdmin would have been really nice to use but with Blueprint it was not really possible to write nice code (I know that there is the cm namespace but it did not work well for us).
At the EclipseCon I talked to Peter Kriens and he convinced me to try out DS on a project. I did so and now I feel really sad about the time I used Blueprint (I did not mean to hurt you, Aries guys :)). Declarative Services together with ConfigurationAdmin is designed to work within the OSGi modularized world. I am pretty sure I know well your current feelings but if I really suggest to you not to make the same mistakes I did. Try to create two bundles with DS components, getting the Configuration from felix-configadmin and feel the power.
As of JPA, we used first EclipseLink. As it was too buggy, we switched to Hibernate. I wrote an adapter to be able to use it (available on GitHub). As much as I know, Hibernate has now more support in this topic, I have never tried it. In the end, we decided to leave JPA. We are on the end of replacing our infrastructure from JPA to Liquibase+QueryDSL. The components are more or less ready at https://github.com/everit-org, we need to work on documentation. If you are interested, why we switched from JPA, read the comments under the this blog post: http://blog.osgi.org/2013/12/attributes-attributes-and-attributes.html
My answer in short:
If you want to avoid of using Declarative Services due to historical reasons (that is a mistake, but I can understand it), use Apache Aries or Gemini BP (that you find better). As Apache Aries was created for OSGi, all namespace handlers that are written for Aries will work for sure. Aries will not support the namespace handlers written for Spring as Aries has its own API. However, ActiveMQ and other projects have Aries namespace handler implementations. Once more, I suggest to consider using DS instead and write your code in Java instead of XML. If you design small modules, deployment time will not be a problem. On the other hand, you will get lots of benefits at the configuration and stability part.
JPA with Hibernate can be used in OSGi. An example can be found here: https://github.com/everit-org/osgi-hibernate. More up-to-date examples are available if you google. I recommend that you should look around as JPA works, but it is not OSGi friendly.
Concerning to the engine: If you use Felix, you can be sure that your code will run on other containers like Equinox or Knopflerfish. The other two has special features that if you use, you may run into the problem that you cannot port your code later. I personally use Equinox, but it has historical reasons.
We use blueprint with Apache aries a lot. Recently there were lots of bugs related to aries but most are fixed right now. Blueprint works pretty well for us but it is lacking a bit support for enterprise features compared to JavaEE. It has basic container managed transactions but little more on this side.
Declarative services seem to be more stable and light weight than blueprint. They also really embrace the dynamic nature of OSGi. On the other hand DS does not have any extension for e.g. JPA and container managed transactions. So I am not sure how difficult it is to write real business code with them.
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. Of course gemini is at eclipse now but I am not sure the community alone can support this.
In mid term I would really like to use CDI and the full JavaEE support on OSGi. There already is pax cdi which provides support for CDI on OSGi and there are portable extensions for e.g. JPA and container managed transactions from Apache Deltaspike. Unfortunately it is not yet fully working so as of now this is no real option.
So my recommendation is to currently do your own proof of concepts with Aries blueprint and DS and decide between the two. At the same time I would keep an eye open for JavaEE support on OSGi to see when it might be ready.
For the basic OSGi platform I think felix and equinox both are nice. It may also make sense to take a look at Apache Karaf which provides management and enterprise functionality on top of both frameworks.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I will be finishing the core Java course and now I have to move on to Java EE side.
I am so much confused that I should simply go with Java EE 6 because I have the books which easily teach from start to end and everything is there.
Or should I start with Spring only?
Because as I have to start from scratch it is good I follow the trend which is good and more job oriented.
Or even if I do Java EE only and then if I need to move on to Spring it will be fast or vice versa.
Also where does Hibernate stand between them? I mean if I use Java EE 6, do I still need Hibernate or in Java EE 6, I don't need it.
Will I be at a disadvantage if I don't use Spring or Spring can make my building web application any way easier than the core Java EE/ JSF framework.
Though your question suggests that Spring and Java EE are two different things, in reality they are not. You can use many Java EE components like
servlets and JSP for Spring MVC,
JPA for Spring DAO.
JTA for Spring security
The only major thing Spring replaces in the Java EE stack is the EJB. Unless you insist on using EJBs, Spring should be the way to go. Also Spring provides inbuilt support for webservices and other things as well.
Also checkout the Groovy and Grails that use Spring as the base.
Finally I would say, functionality wise both does the same. It's code (Java EE) vs configuration (Spring), a matter of preference really.
All my comments should be taken with a grain of salt. I've been a Spring user since version 1.0; I've never used any version of EJB in production - from 1.0 to the present.
Spring has served me well: any technique that I would want to apply from Java EE is available to me in Spring. I've used the web services, LDAP, messaging, and portlet modules along with the usual suspects from persistence, remoting, and web MVC. The code is excellent. I find that emphasis on layering, coding to interfaces, dependency injection and aspect-oriented programming benefits my designs.
The truth is that you can choose either and make it work. There's little advantage or disadvantage at this point, because EJB 3 took so much from Spring that they're supposed to be similar. I can't say that from personal experience, because I haven't used EJB 3.
None of my employers or clients are clamoring for EJB 3. People in my market are using Spring or .NET to talk to web services over HTTP.
EJBs require that you use RMI or CORBA as your network protocol. I believe that HTTP based protocols - be it RPC-XML, SOAP, or REST - are winning, because simple and open usually does.
No one can foretell the future, so job prospect advice is worthless. Your local market conditions might not be the same as mine. You can hedge your bets and learn both. Whichever you choose, it's almost certain that you'll have to learn something new in the future that won't be either EJB or Spring. So pick one and be ready to change.
From my personal experience from learning Java EE/Web programming from the just standard Java, I tried to jump right into some of the frameworks without a clear understanding of how the Java EE/Web stuff worked. While not all of Java EE is relevant if you are using a framework like Spring, I think it is a good idea to have a good grasp of some of the underlying technologies. You don't have to go overboard, but understanding some of the basics is a good idea.
When something is not configured correctly in the libraries (like Spring) sometimes they assume a certain level of knowledge on their user's part. After struggling with a few basic issues, I spent some time and went back to the basics. After that I was better able to deal with the frameworks.
I would just forgo the EJB route though.
First please understand that Java EE is not a single specification, but a set of specifications. While Spring is a framework.
Spring has a neat integration with many Java EE specifications including EJBs.
The idea of using the specifications is to make your application portable between different implementations of this specification. Unfortunately this doesn't work very well in real life.
Now regarding Hibernate. Again: it's a framework. Java EE includes a specification called JPA. Hibernate implements JPA. You may find other implementations. So if you are using another implementation, you don't need Hibernate.
Now, you are probably want to know the bottom line. I don't really have it. If you are studying Java, the more you know, the better it will be.
If you are looking for technologies to start a new web application, I believe it's better to use Spring with a servlet container (servlet container is part of Java EE!) like Jetty or Tomcat + to use JPA (Hibernate implementation) for persistency.
Spring and Java EE 6 is in some sense similiar. They goes their way in parallel. I think it will be better if you learn Java EE 6 and then (if want/need) learn Spring.
In Java EE there is Java persistence that works very well for different database query purposes.
There is really no reason to go with Spring on a new project. There are a lot of applications out there that still use it though. You should definitely learn Java EE before Spring. Spring used to make development easier. At this point though Java EE is easier to work with and you can get rid of the Spring dependency as well.
I have just started learning java and i have about 8 months time. My main aim is to build web application using java. But as there are many java technologies/frameworks available i am conufused how should i go
IDE i am using is eclipse
The path which i am thinking is below
1)Learn Core Java
2)Project: Build Java Invoicing System with JDBC or mysql to test java knowledge
3)Learn Servlets / JSP to
4)Build small site like simple logon/memberarea/catalogue using servlets/jsp
Now guys I really don't know where the following things stand in my path and which things they will help
1)Java EE
2)Spring or spring MVC, what's the difference?
3)Hibernate
4)Wicket
5)Struts
I really don't know how should i learn those and which things to choose from.
what should be my final project which can be build using those because if i see from my current stage even website can be build using servlets/jsp. then why do i need those other technologies
Can anyone give an example of a project which can be build using new technologies and not using jsp/servlet, so that I can get an idea why we need those?
Lot's of stuff to learn in here so I would take it a bit at a time. I'm going to assume you are relatively comfortable with the Java language and core APIs.
First learn about JDBC and databases. Get a basic functional JDBC example app working (not visual just some a vanilla Java app) that does read/insert/update/delete of some records in a table. This will give you the basis for building whatever app you choose. Almost all interesting applications involve some sort of persistence/database.
Learn the main JDBC APIs (Connection, PreparedStatement, ResultSet) and write some code that uses these to get comfortable.
Learn about how transactions work in databases if you aren't familiar already and how JDBC uses them (Connection.commit and rollback)
Next you could look into the spring framework. This has a several useful features that come in handy when building these applications. The main ones to get to know the dependency injection functionality and the JDBC libraries it has. The DI stuff is a bit of a "duh"? if you haven't used it before but it is very useful/powerful especially for medium size + apps. The JDBC libraries help with the cruft of dealing with the raw JDBC APIs and make your code less error-prone.
Once you've got some basic JDBC and Spring stuff worked out you can then start bringing in a web framework.
This is more difficult because there are so many. In the interest of getting something up and running quickly I would probably go with Wicket. It runs inside a servlet container like Jetty, easy to get up and running with a basic web page or two and relatively easy to evolve of the project over time without going down too many blind alleys. I've found that frameworks like JSF (the Java EE default web/view framework) takes a lot of up front time investment to get going on. Most of these frameworks, including Wicket, can leverage the spring stuff you've got above.
Avoid JSP, it's unpleasent technology and outdated by virtually everything else.
To answer some of your other points.
Hibernate is a tool for mapping an object model to a relational model. In it's most basic form you define a Java class for each DB table with the class having one Java property (variable+getter+setter) for each DB column. You can also add references from one class to another to model database relations. It is good but it takes a bit of getting used to.
Spring I've explained partly above. Spring is much bigger than just DI and some JDBC libraries. It also has transaction management libs and bunch of other stuff. Spring MVC is a web framework which lives under the spring umbrella and makes use of a lot of the spring libraries internally. I've never used it so can't offer an opinion on it.
Java EE is an umbrella term for a large set of "enterprise" specifications/libraries. JSF is a web view framework that is part of Java EE.
That's my very high level advice. To summarise I would learn basic DB/JDBC then some spring stuff and then start building a basic web app using what you've learned already.
Hope that helps. There's plenty of info out there on the web on all these topics and you can always ask questions here on more specific parts if you need help. Good luck and enjoy!
EDIT (to address comment):
All of the above is my recommendation/opinion on how to approach learning Java web development.
In summary
Learning JDBC/transactions/databases is a must
Spring is optional but I strongly recommend. Spring is a big library but you can pick and choose the bits you like/need.
Web frameworks the choice is really yours. From what I have tried (JSF/JSP/Wicket) Wicket is the easiest to get going with so you don't spend too much time frustrated with the getting the initial setup. JSP is awful, it's very easy to make a mess with it. JSF is powerful but heavy and probably more suited to very enterprisy projects than a first web app.
Hibernate is optional but can make life easier simply because you can work with Java objects when you do DB queries/updates rather than writing tedious insert/update statements. Hibernate isn't the only tool like this but it's the one I've used most and does the job well. Just don't go too overboard with the "clever" hibernate features initially.
You could easily use Spring MVC instead of Wicket. That may be a perfectly good choice, I've not used Spring MVC myself so can't comment. I'm sure it will integrate well with spring stuff tho so that would certainly be a positive factor.
Do some more research if you're not sure, there's no end of people happy to give their opinion! But really you just have to dive in and try something.
You are correct. If all your applications are served by servlets, JSPs, and JDBC, then maybe you don't need to learn anything else.
I commend you for learning the fundamentals first before diving into a thicket of frameworks that you don't understand. That's a good thing.
But if you reach the point where you have those down cold, maybe looking at these other technologies can help you improve your game.
1)Java EE
You are learning (part) of Java EE when you use servlets, JSPs, and JDBC. They're a subset of the full Java EE machinery - EJBs, JMS, JNDI, etc.
2)Spring or spring MVC whats
difference
Spring is an alternative framework developed by Rod Johnson and Springsource, now part of VMWare, that is based on dependency injection, aspect-oriented programming, and framework modules. Spring web MVC is one module in the Spring framework, based on servlets, that acts as the front end for web applications.
3)Hibernate
An object-relational mapping technology (ORM), built on top of SQL and JDBC, that lets you map objects to tables. It has its own object-based query language.
4)Wicket
Another web MVC alternative to Spring MVC, Struts, JSF, etc.
5)Struts
The first web MVC framework. It's gone through versions 1.0 and 2.0, and has now been supplated by Java Server Faces. It's still used, though. Like all other web MVC frameworks in Java, it's based on servlets and JSPs.
From a Java perspective it might be best to start looking at Java EE. All the others you mentioned are alternative technologies, which might be useful to you if you decide that what the standard framework offers isn't your cup of tea. But for that to decide, it's never a bad idea to at least know what the standard framework is about.
Truth be told, before 2006 the standard framework had a bad reputation and some of the sentiments that form the basis for recommending alternative technologies are still based on that. Starting with version 5, Java EE got dramatically better. The latest version, Java EE 6 is arguably one of the best Java frameworks that's out there. Of course, the best is a highly subjective term and naturally it won't be the best one for each and every person out there.
At any length, Java EE 6 is a very complete framework that allows a large range of application to be written without depending on any additional library. Being the standard framework, most other frameworks at least depend on some parts of it.
Most typically EJB, CDI and JSF are replaced by alternative technologies. E.g. the core Spring container replaces EJB and CDI and Spring MVC replaces JSF. A full Spring stack typically still uses JPA, JTA, JMS and Servlet from Java EE. Wicket on its turn only replaces JSF, or when used with a Spring stack replaces Spring MVC.
Hibernate is a special case. It doesn't replace anything from Java EE, but is instead often used as an implementation for one of the key APIs of Java EE: JPA. The original creator of Hibernate, Gavin King, is one of the prime supporters of the Java EE framework and is in fact the spec lead of one of the most important parts of modern Java EE: CDI.
Wicket by itself is a very nice web framework, but in practice it isn't used as often as JSF. I won't go into the discussion whether Wicket or JSF is 'better' (this is mostly a religious battle anyway), but due to the popularity of JSF there are simply more people experienced with it and there is a large community offering many things for JSF like component libraries and extensions.
Struts has historically been completely replaced by JSF. The original creator or Struts, Craig Mcclanahan, was the one who started JSF as the successor of Struts. Nevertheless, Struts was once the absolute de-facto standard for web frameworks in Java. It's not often advised to be used for new projects, but till this day it's still used in a huge number of existing applications. So even though it's not really 'hot' to learn Struts anno 2011 knowledge of it may still be very practical for when you have to maintain existing applications.
ps
See this answer for a general description about Java EE: Frameworks for Layering reusable Architectures
I'm sure that nobody seriously can tell you the best way, because this would mean that (s)he would have tried all. Why do you want to learn a Java web application framework? Just to learn it to be prepared for the (next) job? In that case it is likely that you've learned the wrong one.
The next question would be what you want to do with the web application framework. Do you want to make a website a little bit active, e.g. make each page look similar (corporate design), auto-generate menus from an internal structure, or do you want to write a real web application, e.g. with database access.
I'd first define the goal what you want to achieve. IMHO a good way to motivate you to make it right is to take a small project which helps you to solve a small problem.
Then I would start with Java Server Pages (JSP) and servlets to understand the basic concepts. Then you can try to do the same with a few well-known web application frameworks, e.g. Wicket.
Having worked for Java for 7 years I'm now moving into a project in .net. The team I'm working in have recently used a technology stack that we are fairly happy with in the business layer and below:
Spring for dependency injection, transaction management, security and for adding interceptors and for getting the possibility to inject different implementations of interfaces when in unit-test as oppose to deployed on a server.
JUnit for unit tests.
JPA/Hibernate for ORM
Could you use this stack in .net? I've heard of nHibernate, spring.net and nUnit.
Are these the translations into .net? or are those projects dead, bad implementations or what?
Are there other superior techniques/frameworks?
Appreciate your thougts!
You nailed it - NHibernate, Spring.NET and NUnit are all widely used frameworks on the .NET side that compliment their sister frameworks on the java side.
None of those projects are anywhere near dead. I think NUnit just released a new version last month, actually.
I would recommend xUnit.net over nUnit. It has a rationalised approach and some very nice features which set it apart from the other frameworks.
Assert.Throws() is just wonderful (beats [ExpectedException] hands down) and the Extensions assembly provides [Theory] which, combined with [InlineData()], is incredibly powerful. For more info see the project homepage
The frameworks you mention (as far as I'm aware) are still current and active development. I might suggest a few alternates to look at.
Spring.NET is the only thing I'm aware of to do what you're talking about.
nUnit is a good choice. You might want to check out the different versions of Visual Studio. Different versions have different features...some have heavy unit testing functionality built in.
nHibernate is a good .NET ORM. With the release of .NET 3.5, you might want to check out the Entity Framework or LINQ to SQL Classes.
nHibernate and nUnit are very much alive and well. Initially they were ports of their java counterparts, but have evolved since then I believe.
Can't speak to spring.net though..
Do you still use session or entity EJBs in your project? Why?
EJB3 is a vast improvement over previous versions. It's still technically the standard server-side implementation toolset for JavaEE and since it now has none of the previous baggage (thanks to annotations and Java Persistence), is quite usable and being deployed as we speak. As one commenter noted, JBoss SEAM is based upon it.
EJB 3 is a viable alternative to Spring, and the two technologies may become more tightly related. this article details that Spring 3.0 will be compatible with EJB Lite (which I'm not sure what that is, exactly) and possibly be part of Java EE 6.
EJB is not going anywhere.
We're working with EJB here and it works quite well with JBoss Seam and JSF, Faclets and MyFaces Trinidad. Good UI, Templating, AJAX and stable production 24/7 running on JBoss 4.2.
It's a good stack for business processes, workflows, messageing, webservices and ui control. Fast delivery of features, easy programming and stable ground based on entitybeans with mysql persistance.
I don't want to miss the featureset of EJB 3 for the tasks our product demands.
See the overview of new features in Java EE 6. EJB 3.1 and WebBeans 1.0 help make a Java EE 6 container environment become easier to use, similar to frameworks like Seam on Java EE 5 or Spring. If you're familiar with Spring 3, this article illustrates how Java EE has evolved to become a comparable framework.
EJB is still there and growing up. There are many new features (SOAP/RESTful webservice, JPA entities, JAXB...) depend on it or at least reuse the philosophy of developing.
Yes, but EJB were stupidly complex for most use cases. Very clever, but real overkill in most cases. Hence the lightweight approach taken now-a-days.
Justin
I've just started back to work on an EJB project. I didn't remember how heavy and hard was to work with this technology. It was luck when Spring, Hibernate and Maven came. Since then everything was different and much easier.
I always could see this technology was never used properly and was taken as a pattern that I never understood.
It was supposed you needed two containers and if it was possible one server for each container. One for Business(EJBs) and another one for Views(MVC). I never saw that.
Well, it's good to know that EBJ is upgrading.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What makes a module/service/bit of application functionality a particularly good candidate for an OSGi module?
I'm interested in using OSGi in my applications. We're a Java shop and we use Spring pretty extensively, so I'm leaning toward using Spring Dynamic Modules for OSGi(tm) Service Platforms. I'm looking for a good way to incorporate a little bit of OSGi into an application as a trial. Has anyone here used this or a similar OSGi technology? Are there any pitfalls?
#Nicolas - Thanks, I've seen that one. It's a good tutorial, but I'm looking more for ideas on how to do my first "real" OSGi bundle, as opposed to a Hello World example.
#david - Thanks for the link! Ideally, with a greenfield app, I'd design the whole thing to be dynamic. What I'm looking for right now, though, is to introduce it in a small piece of an existing application. Assuming I can pick any piece of the app, what are some factors to consider that would make that piece better or worse as an OSGi guinea pig?
Well, since you can not have one part OSGi and one part non-OSGi you'll need to make your entire app OSGi. In its simplest form you make a single OSGi bundle out of your entire application. Clearly this is not a best practice but it can be useful to get a feel for deploying a bundle in an OSGi container (Equinox, Felix, Knoplerfish, etc).
To take it to the next level you'll want to start splitting your app into components, components should typically have a set of responsibilities that can be isolated from the rest of your application through a set of interfaces and class dependencies. Identifying these purely by hand can range from rather straightforward for a well designed highly cohesive but loosely coupled application to a nightmare for interlocked source code that you are not familiar with.
Some help can come from tools like JDepend which can show you the coupling of Java packages against other packages/classes in your system. A package with low efferent coupling should be easier to extract into an OSGi bundle than one with high efferent coupling. Even more architectural insight can be had with pro tools like Structure 101.
Purely on a technical level, working daily with an application that consists of 160 OSGi bundles and using Spring DM I can confirm that the transition from "normal" Spring to Spring DM is largely pain free. The extra namespace and the fact that you can (and should) isolate your OSGi specific Spring configuration in separate files makes it even easier to have both with and without OSGi deployment scenarios.
OSGi is a deep and wide component model, documentation I recommend:
OSGi R4 Specification: Get the PDFs of the Core and Compendium specification, they are canonical, authoritative and very readable. Have a shortcut to them handy at all times, you will consult them.
Read up on OSGi best practices, there is a large set of things you can do but a somewhat smaller set of things you should do and there are some things you should never do (DynamicImport: * for example).
Some links:
OSGi best practices and using Apache Felix
Peter Kriens and BJ Hargrave in a Sun presentation on OSGi best practices
one key OSGi concept are Services, learn why and how they supplant the Listener pattern with the Whiteboard pattern
The Spring DM Google Group is very responsive and friendly in my experience
The Spring DM Google Group is no longer active and has moved to Eclipse.org as the Gemini Blueprint project which has a forum here.
When learning a new technology rich tooling gets you into things without big headaches.
At this point the community at ops4j.org provides a rich toolset called "PAX" which includes:
Pax Runner: Run and switch between Felix, Equinox, Knopflerfish and Concierge easily
Pax Construct: Construct, Organize & Build OSGi projects with maven easily
Pax Drone: Test your OSGi bundles with Junit while being framework independent (uses PaxRunner)
Then there are many implementations of OSGi compendium services:
Pax Logging (logging),
Pax Web (http service),
Pax Web Extender (war support),
Pax Coin (configuration),
Pax Shell (shell implementation, part of the next osgi release)
and much more.
.. and there is a helpful, framework independend community, - but thats now advertisement ;-)
This answer comes nearly 3 years after the question was asked, but the link I just found is really good, especially for starters using maven. A step-by-step explanation.
Is your existing application monolithic or tiered in seperate processes/layers?
If tiered, you can convert the middle/app-tier to run in an OSGi container.
In my team's experience, we've found trying to do web-stuff in OSGi painful. Other pain points are Hibernate and Jakarta Commons Logging.
I find the OSGi specs pretty readable and I recommend you print out the flowchart that shows the algorithm for class loading. I'll guarantee you'll have moments of, "why am I getting a NoClassDefFoundError?": the flowchart will tell you why.
Try http://neilbartlett.name/blog/osgibook/. The book has hands on examples with OSGi best practices.
Try http://njbartlett.name/files/osgibook_preview_20091217.pdf
OR
http://www.manning.com/hall/
The second is not a book i have read myself but I have heard good things about it.
The first was very useful for me. He takes you through the architecture initially and then it's hands on OSGi.
There are a couple of thinks to keep in mind if you are starting with OSGi.
As mentioned elsewhere in this thread, knowing about classloading is really important. In my experience everybody sooner or later runs into problems with it.
Another important thing to remember is: never hold references! Have a look at the whiteboard pattern on which the services concept of OSGi is build (see the link in one of the other answers).
In my experience you should not try to convert a monolitic application into an OSGi-based one. This usually leads to a badly and unmanageable mess. Start anew.
Download one of the freely available stand-alone OSGi implementations. I found Knopflerfish rather good and stable (I use it in many projects). It also comes with lots of source code. You can find it here: http://www.knopflerfish.org
Another good tutorial can be found here. https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial
Peter Kriens of the OSGi Alliance gave a nice interview: http://www.infoq.com/interviews/osgi-peter-kriens. His homepage and blog (which is always a good read can be found here: http://www.aqute.biz
I really like the Apache Felix tutorials. However, I think in general leveraging OSGi in your application isn't one of those "let's use this framework, because it's hype" decision. It's more of a design question, but then everything that OSGi gives you in terms of design, you can have with vanilla Java as well.
As for the runtime, you cannot just add an existing application and make it OSGi enabled. It needs to be design to be dynamic. Spring DM makes it easy to hide that from you, but it's still there and you need to be aware of it.