14 Replies Latest reply on Feb 25, 2006 3:15 AM by Max Rydahl Andersen

    JBossIDE / JEE5 features for EJB3 Tools

    Marshall Marshall Expert

      Hey guys..

      I'm going around collecting information about what features you envision being supported by JBossIDE in your project. I'm starting this thread to get your requests / wishes / concerns for EJB3 Tools written down so we can assess what is and isn't doable by JavaOne timeframe (if it's not doable, then we will probably put it on the roadmap for a later release).

      Thanks, look forward to the discussion..

        • 1. Re: JBossIDE / JEE5 features for EJB3 Tools
          Marshall Marshall Expert

          Ok, since no one has replied yet.. I can think of some niceties we could add in (these would all be JBoss EJB3 specific)...

          - An EJB3 Service bean / Management interface wizard
          - AsyncFacade refactoring
          - Auto complete on hibernate properties in persistence.xml

          Anyone else? ;)

          • 2. Re: JBossIDE / JEE5 features for EJB3 Tools
            mazz Master

            Not sure what, if anything, JBoss-IDE can provide here but...

            What can the tool generate for me wrt testing? For example, I can generate EJB3 beans from an existing data model. But, can I generate some kind of unit test or other kind of test class that I can use to help test my EJBs? Not just limited to entities.

            Perhaps it can help generate the setup/tear down methods that can be used to startup/stop the embedded server so my tests can run without requiring a server running somewhere (i.e. the big problem with EJB 2.x unit testing).

            • 3. Re: JBossIDE / JEE5 features for EJB3 Tools
              Chris DeLashmutt Newbie

              I know this isn't EJB 3.0 specific, but...

              I think continued development of the SEAM GUI generation for with EJB 3.0 backends should be done. This is a great feature and really helps get projects started using EJB 3.0 Entities. Perhaps we could include some kind of migration tool to move EJB 2.1 CMP style entities to EJB 3.0 persistence?

              Part of the problem with the lack of feedback on this thread could be that EJB 3.0 is supposed to make all of the wizards/generators/xdoclet stuff unecessary because you develop through annotations. The more likely reality is that people haven't really developed too many applications that use EJB 3.0 Persistence for many large apps yet.

              • 4. Re: JBossIDE / JEE5 features for EJB3 Tools
                Max Rydahl Andersen Master

                 

                "mazz@jboss.com" wrote:

                What can the tool generate for me wrt testing? For example, I can generate EJB3 beans from an existing data model. But, can I generate some kind of unit test or other kind of test class that I can use to help test my EJBs? Not just limited to entities.


                For entities: we don't have anything yet, but we have a long standing wish and idea for data generation based on metadata ...search for datagen in our jira - contributions welcome ;)

                For non-entities: it would be nice to generate some basic testing - ideas on how these tests should look like to actually be usefull would be welcome.


                Perhaps it can help generate the setup/tear down methods that can be used to startup/stop the embedded server so my tests can run without requiring a server running somewhere (i.e. the big problem with EJB 2.x unit testing).


                probably would be a good idea to add e.g. a template that generates the basic TestNG template that they e.g. use in Seam docs.

                • 5. Re: JBossIDE / JEE5 features for EJB3 Tools
                  Max Rydahl Andersen Master

                   


                  I think continued development of the SEAM GUI generation for with EJB 3.0 backends should be done. This is a great feature and really helps get projects started using EJB 3.0 Entities.


                  we actually have received a couple of talks for jbossworld concerning this, so we might get contributions from the community on this.

                  In any case, the generation stuff is planned to be enhanced/fine-tuned.


                  Perhaps we could include some kind of migration tool to move EJB 2.1 CMP style entities to EJB 3.0 persistence?


                  hmm - what would such a thing look like ? it's pretty different programming models...and does the EJB 2.1 style entities provided more real information than e.g. just reverse engineer the underlying db ?


                  Part of the problem with the lack of feedback on this thread could be that EJB 3.0 is supposed to make all of the wizards/generators/xdoclet stuff unecessary because you develop through annotations. The more likely reality is that people haven't really developed too many applications that use EJB 3.0 Persistence for many large apps yet.


                  An IDE is *much* more than wizard/generators/xdoclet stuff, it is also about having tools that supports during development...like enhanced code completion, JEMS specific debug views, visualization etc. these are the things i find much more usefull in the long run.

                  • 6. Re: JBossIDE / JEE5 features for EJB3 Tools
                    Emmanuel Bernard Master

                    Annotation smart wizard. We actually see crazy people annotating their entities like hell wo understanding the consequences.

                    You could provide some analysis mechanism that could detect:
                    - miss of @MappedSuperclass
                    - miss of @Id
                    - annotation of both methods and fields
                    - mismatch between entity and embedded object / superclass default access type (regarding annotations position)
                    - simplification of annotations if default are used
                    ...

                    • 7. Re: JBossIDE / JEE5 features for EJB3 Tools
                      Max Rydahl Andersen Master

                      So that would be more like a "annotation validator" than a wizard and this validator would provide quick fixes to fix these annotations.

                      I think these features would fit well into the Dali project and/or at least utilize some of the model they have around annotation based persistence.

                      • 8. Re: JBossIDE / JEE5 features for EJB3 Tools
                        mazz Master

                        (I apologize upfront for the long post :-)

                        One other thing that I just ran into. This came into play when I was putting together that skeleton Eclipse project for EJB3 projects (see EJB3 wiki).

                        So, here's the deal. I want to deploy my EJB3 app in JBossAS - say I'm building an EAR with some webapp maybe and my EJB-JAR. Or maybe I just want to deploy in the JBossAS container (i.e. not use the standalone embedded EJB3) for whatever reason. This is very helpful during development because I can now create a JBossAS debug configuration using JBoss-IDE and thus I can start/stop my JBossAS instance from within the IDE. And I can use the packaging/deploy mechanism that JBoss-IDE gives me to push out my code to the JBossAS instance - complete end-to-end development using JBoss-IDE and Eclipse.

                        This means that in order for me to build inside of Eclipse, I need to have my build path point to all the libs necessary - for example, JBoss-IDE creates my EJB3 project by putting the "JBoss EJB3 Libraries" library in my build path.

                        But (and here's the issue), what if I want to build and run unit tests all within Eclipse? I need to now have the embedded EJB3 jars in my build path. This is because my JUnit or TestNG classes will need to start and shutdown the embedded EJB3 container so I can unit test within that environment (this allows me to use the TestNG or JUnit debug configurations in Eclipse to run/debug). But the bootstrap classes aren't in JBossAS EJB3 jars (none that I've seen anyway - I used 4.0.4RC1 and nothing that JBoss-IDE imported into my build path has them). For example, EJB3StandaloneBootstrap.

                        If I put the embedded EJB3 jars in my build path, I've essentially put two sets of (almost) identical jars in my build path. If the embedded EJB3 jars are out of sync with the jars shipping in my JBossAS, I could conceivably run into class cast issues or whatever. The point is, I have two sets of jars in my build path when I really only want one. In the end, I ended up just putting the embedded EJB3's "jboss-ejb3.jar" in my build path and for now that supplies all the classes I need, but I just have a skeleton project at the moment with no real tests other than one that starts/shuts down the embedded EJB3 container.

                        I don't know what JBoss-IDE can do for me - but one thing is to perhaps do the same thing it does today wrt creating JBossAS Debug Configurations. Maybe create JBoss-Embedded-EJB3 configurations that runs the container. I can put the embedded jars in taht configuration's run classpath. This is basically what I do in the TestNG debug configuration I created - I can run TestNG with just the embedded EJB3 jars in its classpath, along with my classes.

                        But that doesn't solve the build path problem of the project. In order for me to build my distribution classes (the ones getting deployed in JBossAS), I need the JBossAS EJB3 libs. But in order for me to build my test classes, I need the embedded EJB3 jars in my build path. I don't know how to solve this need for two separate (but almost identical) sets of jars.

                        • 9. Re: JBossIDE / JEE5 features for EJB3 Tools
                          Marshall Marshall Expert

                          I think it would be relatively easy / a good idea to add an JBoss EJB3 Embedded project wizard and Classpath Container so your classes will compile correctly. That will go on the list =).

                          I'm kind of confused on what you need in terms of IDE support for your embedded test cases. You speak of an "Embedded EJB3" run configuration, but wouldn't that kill the purpose of embedded ejb3? I'm probably just confused =).

                          • 10. Re: JBossIDE / JEE5 features for EJB3 Tools
                            Max Rydahl Andersen Master

                            it is a built in problem of using different environments for testing and deployment...and the fact that the jars a "overlapping" doesn't make it easier.

                            A minimal thing is probably to have support for a class container you can add to your junit, testng or whatever launcher you have that includes these additional jars.

                            What i don't think is good is to create a new kind of launcher just for this.

                            • 11. Re: JBossIDE / JEE5 features for EJB3 Tools
                              Andrig Miller Apprentice

                              Marshall,

                              Here are some of my ideas for EJB3 specific tooling in JBoss IDE. I have been messing around with an EJB3 prototype since the first EJB3 stuff came out. I have also used the current JBoss IDE support for EJB3, and played with the reverse engineering stuff. Based on all of that, there are several things that would make life easier.

                              With the reverse engineering from a JDBC connection, it would be nice if the generated code generated a hashCode and equals method for each entity. It would be nice if you could configure the reverse engineering to tell it to use the column and table names as the bean and property names, and eliminate the extra annotations. Finally, if you could configure the reverse engineering to specify the cardinality of the relationships. Right now it seems to assume that all relationship are OneToMany and ManyToOne. Database meta data is never sufficient, and even actual table data from statistics can be misleading.

                              Full round-trip engineering. I would like to be able to go from an POJO annotated as an Entity and have it create the tables in the database via JDBC. This would give developers the flexibility to start wherever they want, or need to, but not lose customizations along the way. For example, maybe I start by reverse engineering from the schema, but then during development I realize that I need an additional attribute, or relationship that isn't in the current schema. Then I could just update the POJO, right-click, and forward engineer back to the schema. Of course, this would be subject to the priveleges of the database, but very useful.

                              There has been discussions about Unit testing, and the conflicts between the Embedded EJB3 and the application server. The libraries are duplicated. What I did for my unit testing is actually setup a unit testing project, that then included the EJB3 project, with only the Embedded libraries (I created my own User library that includes the embedded distribution jars). So maybe, in the wizard for setting an EJB 3 project, you can include an option for a unit test project to be created which would have the parent project in the build path. That unit test project would have the embedded library in it, instead of the normal EJB3 libraries that point at the application server, and the Eclipse JUnit library added to the build path as well. Eclipse already has wizards for creating JUnit tests and JUnit test suites. I found that with the example JUnit test in the embedded distribution that I could not really use the wizards because of the way that the embedded server is boot strapped. I changed it so that I could use the wizards and use some utility classes from within the normal Eclipse generated JUnit classes. The only real issue with the way I did this, is that I can only run test suites, and not individual tests. I have to refactor what I did so it works both ways. With something like this, you could provide very tight JUnit support. I know a lot of folks like to use TestNG as well, but I have never used that, so I cannot speak to how you could support that as well.

                              I think that is about all I can think of. I hope this is helpful.

                              Andy

                              • 12. Re: JBossIDE / JEE5 features for EJB3 Tools
                                Max Rydahl Andersen Master

                                It is not possible to create a proper hashcode and equals automatically since it requires a natural key. One thing I could do though is to detect if there is a column or columns that is marked as unique and use them in equals and hashcode.
                                (see http://www.hibernate.org/109.html why i cant just generate it automatically from primary key)

                                Full round-trip engineering - we already got that. What are you missing ? :) (most likely some better ui, but have you tried enabling ejb3/annotaitons on the console configuration, right click and run schema export ?) ..this is also what makes it possible to generate Seam Apps from *existing* mappings, be it hbm.xml or annotations....reverse engineering is just *one* start point.

                                Regarding your final thoughts about junit tests could you show me a sample ? e.g. create a project setup, zip it and attach/send it to us ?

                                Thanks for the feedback.

                                • 13. Re: JBossIDE / JEE5 features for EJB3 Tools
                                  Marshall Marshall Expert

                                  I think another thing we should target is to try to extend / integrate with Dali as much as possible.

                                  Max , you have the most experience in dealing with Dali -- is there anything we've listed here that will be covered by that integration?

                                  • 14. Re: JBossIDE / JEE5 features for EJB3 Tools
                                    Max Rydahl Andersen Master

                                    Not really yet. The annotation validation/quickfixes is something they have on their roadmap.

                                    I think Dali needs a milestone or two before being interesting to bundle and extend; but it should definitly be a goal and i'm monitoring possible integration/extension/compability possibilities/issues.