12 Replies Latest reply on Mar 2, 2017 5:54 PM by asookazian

    Weld and OSGi

    asookazian

      any advantages to using an OSGi-based container like Glassfish V3 or SpringSource dm server with Weld?

        • 1. Re: Weld and OSGi
          pmuir

          The primary benefit is if you want to take advantage of OSGi in your application. However in GlassFish, they use OSGi more for infrastructural purposes (though I'm sure you can still use OSGi directly). You would need to do some integration work if you want to use dmServer.

          • 2. Re: Weld and OSGi
            gavin.king

            Personally I've seen very few applications that are big enough, or have a sufficiently complex set of dependencies to require internal use of a module architecture like OSGi. But they certainly do exist. Obviously something like Eclipse, or an application server, is impossible without a module architecture.

            • 3. Re: Weld and OSGi
              gavin.king

              What I mean to say (but did not say clearly at all) is that the application server already has a modular architecture. From your point of view you probably don't care very much whether this is OSGi or something else, since your application probably isn't complex enough that it can't be easily structured and deployed as an EAR.

              • 4. Re: Weld and OSGi
                asookazian

                If no EJBs, then the application may be deployed as a WAR (in fact, I used WAR for my last Seam 2.x project b/c EJBs are not incrementally hot deployable via the special Seam classloader, even not via JRebel until the new version that is coming soon which supposedly will pickup changes to the EJB interface).


                • 5. Re: Weld and OSGi
                  gavin.king

                  In EE6 you can deploy EJBs in a war.

                  • 6. Re: Weld and OSGi
                    asookazian

                    I thought that one of the advantages of OSGi-based app server is avoiding the classloader problems of traditional J2EE app servers...


                    How bout this:



                    We don't care what model you use, we want to supply you with the model you need, and it's not just about saying, 'Here is our model. Use it', we're really saying: 'Here is our middleware, we want you to use that, and here are the extra number of models that you can use on top of that middleware'.

                    http://www.infoq.com/interviews/dm-Server-Rob-Harrop#


                    sounds good to me...


                    how is EE 6 offering different models?  EJB lite, for example and different web profiles?

                    • 7. Re: Weld and OSGi
                      gavin.king

                      I thought that one of the advantages of OSGi-based app server is avoiding the classloader problems of traditional J2EE app servers...

                      Look, I'm not saying OSGi isn't an improvement, or that it doesn't solve some issues. It is certainly a problem that the very basic module system in Java EE is underspecified and that the individual vendors are left with too much freedom to implement it in different, incompatible ways. But I'm also highly skeptical of claims that OSGi is the magic bullet that solves all classloading problems.


                      By the way, the OSGi spec itself is not that great, IMO. The modules layer seems reasonably sound, but especially the services layer is actually quite lame and looks like something designed in 2003.


                      So personally, I'm still waiting for a better module system. Hopefully in Java 7, as part of the language.



                      how is EE 6 offering different models?

                      Count me as one who believes that EE should offer one model that actually works. Of course, EE should also provide SPIs to let you integrate third-party frameworks - which servlet6 and CDI do now provide.


                      The kind of support for different models that is useful is:



                      • letting you easily integrate a different web framework, e.g. Wicket

                      • make it easy to integrate legacy code written using, e.g. Spring

                      • make it easy to extend the model


                      • 8. Re: Weld and OSGi
                        asookazian

                        Gavin King wrote on Nov 08, 2009 20:15:


                        It is certainly a problem that the very basic module system in Java EE is underspecified and that the individual vendors are left with too much freedom to implement it in different, incompatible ways.



                        And hence the difficulty of porting one JEE app (EAR) from Weblogic to JBoss or vice versa, for example.  This has been a problem for years, I wonder when the JCP/EGs will address this?  When will JEE container clustering become a JSR?  or is there one already?



                        The kind of support for different models that is useful is:

                            - letting you easily integrate a different web framework, e.g. Wicket
                            - make it easy to integrate legacy code written using, e.g. Spring
                            - make it easy to extend the model


                        I liked that response.  And JSF has render kits which is along the same lines...


                        • 9. Re: Weld and OSGi
                          gavin.king

                          And hence the difficulty of porting one JEE app (EAR) from Weblogic to JBoss or vice versa, for example. This has been a problem for years, I wonder when the JCP/EGs will address this?

                          I'm not sure if you've been living under a rock, Arbi, but there is a highly-publicized effort to create a native module system for Java, as part of the language and JDK. Now, this process is somewhat ballsed-up at the moment for a number of different reasons (including the fact that the EC can't agree on licensing of Java 7, hostility from the OSGi community, and, it seems to me, a bit of confusion on Sun's part about what they are actually trying to achieve). But when this new module system exists, EE7 will use that.

                          • 10. Re: Weld and OSGi
                            asookazian

                            Ok, GKing, you got me on that one considering EG formation was 28 Jun, 2005 for JSR 277: Java Module System (no retaliatory effort).  But I'm not as embedded in EG's and JCP as you are obviously.


                            http://jcp.org/en/jsr/detail?id=277


                            sounds interesting (I think I may have read about this feature targeted for JDK 7 a while back) and I'm glad my favorite OO-bigot, none other than Ted Neward, is on the EG.  something to look forward to...

                            • 11. Re: Weld and OSGi
                              asookazian

                              Interesting...



                              i find their most recent anti-application server vendor strategy around suggesting that OSGi is not ready for the enterprise to be interesting, to say the least, as Glassfish and JBoss played catch-up to delivering a micro-kernel architecture, right at the moment that they finally caught up, Spring Source pulled the rug out from underneath Glassfish, and JBoss, in particular, by saying that they are no longer interested in their customers deploying through OSGi, leaving fear, uncertainly and doubt in the minds of developers and particularly IT managers, over whether OSGi is in fact a 'risky' proposition to deploy to....

                              http://www.javaworld.com/community/?q=node/3955


                              SpringSource = FUD HQ

                              • 12. Re: Weld and OSGi
                                asookazian

                                Interesting, so fast forward 7 years (wow!).  I'm now developing multiple apps on a different Java tech stack: JDK 8, Apache Karaf 4.0.8 (OSGi --> Felix), Angular JS, Maven 3.3.9, DI via Blueprint (no Spring/Seam/Weld/EJB/etc.), CXF, Camel, ActiveMQ, Titan, Cassandra

                                 

                                JSR 277 (Java Module System) withdrawn and replaced by JSR 376 (Java Platform Module System)

                                 

                                Haven't used Java 9 yet but according to this article it's not as good as OSGi:

                                 

                                Java 9, OSGi and the Future of Modularity (Part 1)

                                 

                                I am able to install JARs or WARs as bundles in Karaf, no more restarting the app server for a one line change in one class deployed in a JAR in an EAR.  No more necessity for JRebel.

                                 

                                I'm not a big fan of Angular JS, I find it somewhat unintuitive and wish I could flashback to the days of JSF/EJB3/Seam...