Community
Participate
Working Groups
Created attachment 75337 [details] plugin The attached plugin contains the Java EE annotation model developed in SAP. The plugin parses the available Java EE 5 projects in the workspace and builds a model from the Java source annotations. However, for the moment, the model covers only EJB 3.0 projects and not all of the annotations in the specification. Nevertheless, this is enough for the Java EE navigator content in the Project Explorer. The plugin is currently enabled in debugging mode and debugging information is printed in the console (System.out). The plugin starts in lazy mode. This means that a method of the plugin should be called (AnnotationModelPlugin.getProject(project)) to trigger the initialization of the model.
Created attachment 75338 [details] junit test case Attached is the junit test case for the annotation model plugin. It can help in illustrating the usage of the model API.
*** Bug 199111 has been marked as a duplicate of this bug. ***
Created attachment 88002 [details] A document describing a different approach I have tried a different approach with and have prepared a document describing the idea. We have some basic implementation, but it is a subject of many changes and will not attach it for now. Early comments will be great for improving the document and the model.
Thanks for the very good explanation of your approach. The use of different model provider implementations (XML, annotation, or merged) is a good one, and as you mentioned, by using different "modelPath" arguments, can determine which model is chosen, as there will be scenarios to get each separately. I don't see any mention to how the merge is done, or how a user could determine the "source" of each model element (possibly adapters?). Also - I agree lazy initialization is a good start, but for the models to perform, a good caching mechanism, that participates in the listener mechanism you mentioned is essential.
(In reply to comment #4) > I don't see any mention to how the merge is done, or how a user could determine > the "source" of each model element (possibly adapters?). The merging mechanism is still changing very rapidly. I will soon attach a proposed implementation. The merger has a simple method - merge(base, toMerge).This method will merge every property in the toMerge and to the base. For example if the base is a session bean with one reference to a persistence unit and toMerge is also a session bean with another reference to persistence unit the result of the method will be that base will have two references to the persistence unit. There will be different type of mergers: A merger for the EJBJar, A merger for the SessionBean, etc... The merger can easily determine the priority. If base is a session bean with name "beanName1" and toMerge is a sessionBean with name "beanName2" then the value of base is with higher priority. We are trying to keep the mergers as simple as that - everything from toMerge goes to base. If there are conflicts the value at base is with higher priority. This means that there might be a level over the mergers that knows how exactly to use this mergers. For example if the user changes a session bean in a .java file we can merge this change in the already loaded model. We will just determine that only a java file is change. Build a deltaModel only for this file. Merger this deltaModel to the already loaded model. It is a lot of work to handle all the case where there will be conflicts in between the values in base and toMerger. This is way we are trying to introduce an extension mechanism for the mergers. This will allow us to have one merger of this wtp version and an improved merger for the next verision, and to plug other mergers for the next javaee version. It would be possible for adopters to change the mergers if they would like an improved functionality. For example - interceptors are very rare and some adopters might provide a merger that knows how to merger interceptors which will be an enchantment for their product. Maybe it would be a nice to register merger for a project with specific facet version? According to the source of the element: I have tree ideas: 1.Load the xml model. Load the annotation model. Merge everything in the annotation model. - memory is reduced. Only two models. Changing the annotation of a bean in a java class will result in a resource change. A new model object (SessionBean) is build for this change. When merging this change to the annotation model the problem is that you can not determine the priority of the conflicts. One is merging an annotation model to an annotation model. 2.Load the xml model. Load the annotation model. Merge everything in the xml model - memory is reduced. Only two models. Change the annotation of a bean as in case 1 will result in a new annotation model that will be merged to a xml model. Priorities are fine. Problem - how do you save the xml. No way of knowing which of the elements are from xml and which are from annotation. 3.Load the xml model. Load the annotation model. Create a new model an call it - mergedModel. Merge everything from the xml model to the mergedModel. Merge everything from the annotation model to the mergedModel. This way there are tree models - mergedModel, annotation and xml. Memory is with 50% more. I am expecting in the general case the model for a project to be not more then 100KB. I am not sure about this number. The good thing here is that it will be easy to determine the source of an object. I am expecting that finding the source of the element will be done in O(n) time where n is the number of object of the same type (for example SessionBean). This means that all modifications to the model must be executed through the IModelProvider::modify() method since only the model provider can determine the source of the object. I am currently working on the 3 approach. > Also - I agree lazy initialization is a good start, but for the models to > perform, a good caching mechanism, that participates in the listener mechanism > you mentioned is essential. Since I have some problems with the IElementChangeListener - I need more time to investigate the issue. For the moment I am trying to use IResourceChangeListener, but the granularity that IElementChangeListener is providing is very tempting.... All this will soon be described in the document, but I prefer to attach a few tests and classes before that. Any comments are very welcome.
Created attachment 88793 [details] Initial contribution of the classes. This patch contains the model provider, the merges and tests for the model provider. As a starting point one can review the CreateAnnotationModel test and the logic flow in it. The test basically tests the EJBAnnotationReader. There are two kind of tests - one for the initially loaded model objects and three tests for changing, removing and adding a java file with a stateless annotation, that will change the annotation model. Changes are based on IResourceChangeEvent for now. The other starting point is the EJB3MergeModelProviderFactory. We will try to provide a more complete example and description of the next attachment. Comments are welcome for the improvements of the initial implementation.
Created attachment 89128 [details] Implementation of a model merging SessionBeans. This patch is an implementation of a model provider that presents a merged view of a model build from deployment descriptor and from annotations. We have also implemented a navigator content extension that is showing the model. This navigator content is contributed to Project Explorer and as a children of a project. You can use this project explorer to check the merged model. Unzipping in the workspace and starting a new runtime-workbench should get you going. I have implemented test for the functionality of adding, removing, changing and moving files out of, and into the class path of the project. This all scenarios are described in the CreateModelFromAnnotation test. The CreateMergedModel test is a simple JUnit test(no JUnit Plug-in test) that knows how to merge two EMF models. You can take a look at it. I will also attach a screen shot.
Created attachment 89129 [details] Implementation of a model merging SessionBeans. This patch is an implementation of a model provider that presents a merged view of a model build from deployment descriptor and from annotations. We have also implemented a navigator content extension that is showing the model. This navigator content is contributed to Project Explorer and as a children of a project. You can use this project explorer to check the merged model. Unzipping in the workspace and starting a new runtime-workbench should get you going. I have implemented test for the functionality of adding, removing, changing and moving files out of, and into the class path of the project. This all scenarios are described in the CreateModelFromAnnotation test. The CreateMergedModel test is a simple JUnit test(no JUnit Plug-in test) that knows how to merge two EMF models. You can take a look at it. I will also attach a screen shot.
Created attachment 89130 [details] A screen shot of 3 beans. Two of the beans are in the xml. One is in described as annotation.
I have forgot to mention that the CreateModelFromAnnotation test has a constant with the path in the file system to an ejb-3_0-api.jar. So for this test to run the static constant must have the right value. This ensures that the test is working on a valid project.
Created attachment 89294 [details] Implementation that is aware of Local and Remote interfaces I am providing an implementation of the EJB3MergedModelProvider that knows how to create a model from the annotation and is aware of: sessionBeans localInterfaces remoteInterfaces session bean name session bean mapped name session bean description A typical scenario for testing the provider will be: 1.Create an ejb 3.0 project. 2.Create a new session bean using the SessionBean wizard 3.Expand the tree in the project explorer as shown in the screen shot of attachment https://bugs.eclipse.org/bugs/attachment.cgi?id=89130&action=edit The model of the bean is shown. Another use case is: 1.Create an ejb 3.0 project 2.Create a package org.eclipse. 3.Create a class. 4.Add the Stateless annotation to the class. Check that now the bean is shown in the tree. 5.Change the bean so that it implements an interface. For example - Interface1. But do not create Interface1 for now. Just type "implements Interface1". 6.Check that the tree is updated and the bean model is updated - its business local list contains a value "Interface1". 7.Now Using quick fix create Interface1 in package org.eclipse. 8.Check that the tree is again updated, but now the value in the business local list is the fully qualified name of Interface1(eg. org.eclipse.Interface1). 9.Now add a Remote annotation to org.eclipse.Interface1. 10.The bean model is update and Interface1 is no more in business local list, but in business remote list. Another feature: 1.Create a project. 2.Create a bean - called it SessionBean1. 3.Specify the name of the bean in the annotation - give it a name "myBean" 4.Create another bean. - called it SessionBean2. 5.Specify the name of the bean in the annotation - give it a name "myBean" 6.Check that only one bean is shown in the tree as desired. The beans are "merged". There are of course test cases for all the scenarios. New tests (compared to previous attachment) are added CreateModelFromAnnotation, EjbFactory2Test and ResourceToModelRelationTest. I am experiencing some performance problems with org.eclipse.jdt.internal.core.NamedMember.resolveType, but for this I will attach another file.
Created attachment 89295 [details] Screen shot of a performance result I have profiled the loading of the model in a project of 33 java files from which 12 are beans 12 are local interfaces and 9 are remote interfaces. Total time is 10.6 seconds for now. A total number of 10 beans are found since 3 of the beans have the same name. The most time consuming method is: org.eclipse.jdt.internal.core.NamedMember.resolveType -50% of the time - 5.346 seconds It is called for every interface implemented by a bean since the fully qualified name of the interface must be added to the business local/remote interfaces. I have checked that the methods are not called unnecessary number of times, but there must be a way to implement this in a more performance way. Any comments and proposals will be great.
Created attachment 90749 [details] working version of the EJB model and UI
(In reply to comment #13) The the attachment https://bugs.eclipse.org/bugs/attachment.cgi?id=90749 supports for the following annotations: # javax.ejb.ActivationConfigProperty # javax.ejb.EJB # javax.ejb.EJBs # javax.ejb.Init # javax.ejb.Local # javax.ejb.LocalHome # javax.ejb.MessageDriven # javax.ejb.PostActivate # javax.ejb.PrePassivate # javax.ejb.Remote # javax.ejb.RemoteHome # javax.ejb.Remove # javax.ejb.Stateful # javax.ejb.Stateless # javax.ejb.Timeout # javax.ejb.TransactionManagement # javax.annotation.PostConstruct # javax.annotation.PreDestroy # javax.annotation.Resource # javax.annotation.Resources # javax.annotation.security.DeclareRoles # javax.annotation.security.RunAs A bean depends on the files that describes the bean and the interfaces that are local,remote,part of an ejb or resource injection. When such an interface is for example change from local to remote all the beans that depend on this interface will be rebuilded(And only this beans:) ). Checks are made for whether the annotation is placed on the right place. There are some requirements for PostConstruct, PreDestoroy, PostActivate,PrePassivate annotations and the methods on which they are placed. I am thinking of providing the user with problem in the problems view for such invalid placed annotations.
Created attachment 91780 [details] support for web artefacts. Still no ui
Ever wonder if it is possible to have a model provider for Web25 projects that will give you a merged view between the deployment descriptor and the annotated java classes? :) Well, now you have it. Only at the price of downloading the attachment https://bugs.eclipse.org/bugs/attachment.cgi?id=91780 you get a model provider capable of merging: @Resource annotation @EJB anntoation @Resources annotation @DeclareRoles annotation @RunAs annotation. However if you download the patch in the next 10 minutes you will get for free: -processing the @EJB, @Resource annotations on type, method, field level. -processing the @DeclareRoles, @RunAs only on servlets. (pure listeners and filters) -annotations are process only on servlets, filters, listeners described in the deployment descriptor. So do not hesitate and download it immediately. :) There is still not an UI so you won`t see a tree on the web project. But we will try to soon implement it.
Created attachment 92146 [details] Five patches on a project level for five projects I am including five patches for five projects. The patches are on project level. The next attachment to come will include a patch on a workspace level for all the projects, but having different patches might make this easier.
Created attachment 92147 [details] Patch on workspace level for the five projects. This patch is on a workspace level. One may chose between this and attachment 92146 [details](https://bugs.eclipse.org/bugs/attachment.cgi?id=92146&action=edit). They should be equal, but here all changes are contained in one patch.
Created attachment 92168 [details] icons for the ui plugin Icons for the ui plugin since the patch has some difficulties :) with binary files.
code dropped and released to HEAD Only tests are not released, because they are based on JUnit 4. Chuck, is there a problem if unit tests are based on JUnit 4 instead of JUnit 3?
(In reply to comment #20) > code dropped and released to HEAD > > Only tests are not released, because they are based on JUnit 4. > Chuck, is there a problem if unit tests are based on JUnit 4 instead of JUnit > 3? > Carl brought this to my attention, so I'll respond (even though I'm not Chuck :) It's my understanding that the way the infrastructure works is that if have the correct pre-req range for JUnit 4 (or, is that a separate ID?) that it should work fine. As far as I know, though, no one has done it before (in WTP) so you should stay aware of build results and be prepared to revert if there's some major issue.
According to http://www.jup-net.de/djux/JUnit40QuickStartGuide.pdf it should be possible to run junit4 tests with existing runner. This is due to the JUnit4TestAdapter.
(In reply to comment #22) > According to http://www.jup-net.de/djux/JUnit40QuickStartGuide.pdf it should be > possible to run junit4 tests with existing runner. > > This is due to the JUnit4TestAdapter. > Ok ... made me look :) ... apparently it does _not_ currently work, in Eclipse Testing Infrastructure. See bug 153429.
Created attachment 92332 [details] Revert merged model provider factories entrypoint in plugin xml. Revert merged model provider factories in plugin.xml files to old factories.
Created attachment 92334 [details] remove of junit 4 tests remove of junit 4 tests
Patches committed to HEAD and released: - Revert merged model provider factories entrypoint in plugin xml. - remove of junit 4 tests
Created attachment 92414 [details] fix and enable of Merged Model Merged model is fixed to modify only xml files and to introduce consistent instance of ModelObject. It is no longer necessary to explicitly call getModelObject in order to get refreshed model.
Thanks, Dimitar! Unfortunately, it is too late to include this patch in this I-build. I will commit the patch once the I-build is declared.
"fix and enable of Merged Mode" dropped to HEAD.
Created attachment 92873 [details] Ear and Application Client UI for DD descriptors Support for ear and application client deployment descriptor node in project explorer added. Drag and drop support is added to make reference from ear project to JEE modules, it works on project level.
Created attachment 92914 [details] icons for App client and ear deployment descriptor tree
I would like to reopen the bug since the tests are not yet submitted. I will provide a patch with the next attachment and comment. We have also found the problem https://bugs.eclipse.org/223211. 223211 is about EJB3ModelProvider. I can provided a workaround for the problem of 223211 in the EJB3MergedModelProvider if necessary (but this will be a workaround). So there are still changes (especially the tests) that from my point of view should be tracked with this bug. If it does not have tests, it does not exist :)
Created attachment 92949 [details] JUnit3 tests for the model providers. This patch contains the tests for the model provider. The tests were attached with one of the previous attachments, but they were all JUnit4. I have restructured them to JUnit3 so they can not be run with the existing tests. The tests are structured in two suites: AllAnnotationModelTest MergersTestSuite Tests are now using org.eclipse.jst.j2ee.dependency.tests.util.ProjectUtil.java to create projects. I would really like to further improved the structure of the tests, but this can be handled by other bugs. Note: What is more importantly here: JUnit4 allows me to create a project before a test suite and delete the project after the test suite. Using @BeforeClass and @AfterClass JUnit3 allows me only to create a project before a test suite. But I can not delete it. This means that there are more then one project in the workspace while the tests are run. Which makes debugging the tests a little harder since more then one instance for a model provider will receive notification for workspace changes and will be currently active. I am currently setting the name of the test class as the name of the project that this class creates. .class.getSimpleName() is used so it is possible to have conflict situations. One of the tests is failing. It is testing the problem described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=223211. This test is called GenerateDDTest.
"Ear and Application Client UI for DD descriptors" along with the icons patch is committed to HEAD
There are two tests throwing exception when I run them locally. This is in addition to the test that is expected to fail. It could be something wrong on my side. I prefer to hold on committing the tests for this I-build. We will do it next week and we will have the time to take a deeper look at them.
*** Bug 199113 has been marked as a duplicate of this bug. ***
Created attachment 93291 [details] JUnit3 tests for the model providers. Second Try Created an attachment (id=92949) [details] JUnit3 tests for the model providers. This patch contains the tests for the model provider. Tests from the previous attachment https://bugs.eclipse.org/bugs/attachment.cgi?id=92949 are fixed. More tests are added compared to 92949. Two of the tests is failing. This is because of bug 223656.
Tests are dropped to HEAD and released to build. I have commented the two failing tests. They will be uncommented when bug 223656 is fixed. The idea of having unit tests run on every build is to catch regression. It seems that bug 223656 exists already for some time, so it cannot be considered as a regression.
Verified with S-3.0M6-20080404175400
Closing
