Announcement Announcement Module
No announcement yet.
Is Roo 1.1.x compatible with JPA 1.x? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is Roo 1.1.x compatible with JPA 1.x?

    We have a large project which is running Roo 1.0.x on a Weblogic 10.3.3 server using Hibernate for JPA 1.x

    We really want to upgrade to the latest Roo version 1.1.2 but the problem is that it's now dependent on JPA 2.0 which we are not able to run on our Weblogic 10.3.3 server since Hibernates JPA 2.0 is not compatible with Weblogic yet.

    Is there any way of upgrading to Roo 1.1.2 and still use JPA 1.x? or are the generated aj files hardcoded to use JPA 2?

    Hope for some input on the matter

    Kind Regards,

  • #2

    You are one of the few -that I know able to successfully deploy differently to tomcat.

    I wonder if you can provide some details about it. i.e.

    Are you deploying the war file created by the Roo? or you have modify to work on WL.

    Thank you


    • #3
      I've had a little luck, but not much

      I can actually get my DBRE generated entities to "work" in Glassfish, but I'm not using the default Roo mechanism for injecting a persistence context. I've found that if I create a stateless session EJB and inject the persistence context there, I can use that context to do finds, queries, etc. against my domain model. However, I can't use any of the pre-generated methods that rely on the internally injected persistence manager (in the *_Roo_Entity.aj files), because I can't get that injected correctly. It seems to be a problem with handling the @Configurable annotation, along with other glassfish oddities regarding field and method names realted to the persistence context.


      • #4

        You have to use Glassfish for some reason?... you can avoid all these issues just by deploying straight to tomcat. You can use all this time for solving your problem instead.

        I just trying to help you



        • #5
          Our corporate standard is JES/Glassfish.


          • #6
            I understand...

            The thing is that -in my opinion you are trying to fit two different java web development approaches/frameworks for solving your problem.

            Would it work? may be yes may be not. The fact of the matter is that by doing all this extra configuration work the main benefit of using Spring Roo is pretty much gone. Not to mention that major pieces of your web application server -for which your company pays big bucks- would not used or might be underused.

            Again, I'm just offering an opinion on the matter.



            • #7
              I don't follow your point

              What are the different java web development approaches/frameworks you're talking about? Obviously Tomcat is going to be the best supported and tested environment, since Roo comes from SpringSource, but most things are standards based, and conceptually there's no conflict that I'm aware of between using Roo in Tomcat vs. a full J2EE environment.

              I fell pretty confident that the problems I'm seeing are mostly learning curve related, and due to this being somewhat untried. I think that with more time and sufficient help from the rest of the community, we can get these container issues resolved and documented, and possibly some patches and add-ons that make the process more streamlined in the future.


              • #8
                Spring framework was created as an alternative to the the EJB spec approach...

                EJB is container-based to manage enterprise stuff like transactions, security, etc.

                Spring framework does the same but application wide not just for ejbs but implements the functionality differently.

                This overlap/redundancy of functionality will be always there when you try to use it together.


                • #9
                  That's not what the Spring page says


                  You can use all of Spring's functionality in any J2EE server, and most of it also in non-managed environments. A central focus of Spring is to allow for reusable business and data access objects that are not tied to specific J2EE services. Such objects can be reused across J2EE environments (web or EJB), standalone applications, test environments, etc without any hassle.
                  So, what you say seems to contradict the stated message on Spring's own description page. I want to use the Roo generated entites in Glassfish, and it should work "without any hassle". Now, I've been programming long enough to know that there's always going to be some hassle, but barring any showstopper bugs in Glassfish, it should be possible to get this to work...I just need to know the right way to get Roo/Spring/AspectJ/Glassfish to all play together. Unfortunately with apps composed out of so many different projects and pieces, it's hard to tell just where the process is breaking down.


                  • #10

                    I replied to you private message...

                    Best Luck


                    • #11
                      Sorry to revive an old thread but I'd like to see if there are any good news on this front?

                      Like many others, I'm stuck on Weblogic 10.3.x. It doesn't look like JPA2 will be in the picture any time soon. What would you suggest is the best way to go?

                      I was thinking of writing an add-on or changing the roo code to write JPA1 code instead for the entities. There might be better solutions.

                      Hopefully someone has a good idea or has had success with this before.