I also agree. On a somewhat related note, the old code exposed the factory for creating the J2EE EMF objects. How does one create a Servlet, for example, using the new code? I am using last week's IBuild, and the JavaEE EMF factory is internal.
Gerry Kessler WTP JSF Tools Team -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Lanuti Sent: Friday, May 04, 2007 11:57 AM To: General discussion of project-wide or architectural issues. Subject: RE: [wtp-dev] ArtifactEdits, Java EE 5, old code, and new code I think Kaloyan has a good point. I understand the desire to create a new set of models the "right" way and not be tied to limitations in the old models. But is there some way to provide a common interface or some utility classes so that client logic does not need to be duplicated everywhere? Thanks, John Lanuti IBM Web Tools Platform Technical Lead, IBM Rational IBM Software Lab - Research Triangle Park, NC [EMAIL PROTECTED] t/l 441-7861 "Raev, Kaloyan" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 05/03/2007 12:20 PM Please respond to "General discussion of project-wide or architectural issues." <wtp-dev@eclipse.org> To "General discussion of project-wide or architectural issues." <wtp-dev@eclipse.org> cc Subject RE: [wtp-dev] ArtifactEdits, Java EE 5, old code, and new code Hello, Let me explain in written form what I have tried to tell on the phone line. Let's go to the validateDisplayName() method of the org.eclipse.jst.j2ee.internal.web.operations.NewServletClassDataModelProvide r class. This method checks if the given servlet name already duplicates the name of the existing servlets for this project. To do this the ArtifactEdit is taken, then WebApp object and then the WebApp.getServlets() method is called. If I want to modify the code in a way to support the Java EE 5 case, I have to use the new model provider's functionality. So, I have to do the following: 1. Get the model provider for the project: IProject project = ProjectUtilities.getProject(getStringProperty(IArtifactEditOperationDataMode lProperties.PROJECT_NAME)); IModelProvider mp = ModelProviderManager.getModelProvider(project); 2. Get the model object: Object mobj = mp.getModelObject(); This is org.eclipse.jst.javaee.web.WebApp in the Java EE 5 case and org.eclipse.jst.j2ee.webapplication.WebApp in the J2EE 1.4. These a completely different interfaces and they do not subclass each other. 3. Call the WebApp.getServlets() method: if (mobj instanceof org.eclipse.jst.javaee.web.WebApp) { // Java EE 5 case EList servlets = ((org.eclipse.jst.javaee.web.WebApp) mobj).getServlets(); // do further logic here } else if (mobj instanceof org.eclipse.jst.j2ee.webapplication.WebApp) { // J2EE 1.4 case EList servlets = ((org.eclipse.jst.j2ee.webapplication.WebApp) mobj).getServlets(); // do further logic here } Now, here is the problem. The developer has to split his logic to cover explicitly the two cases: J2EE 1.4 and Java EE 5. However, In both code streams he does one and the same things, but with different set of interfaces. It would be much nicer if the common methods between the two different WebApp interfaces are assembled in a common abstract interfaces that the two WebApp interfaces extend. This means that we have a base AbstractWebApp interface and both: org.eclipse.jst.javaee.web.WebApp extends AbstractWebApp and org.eclipse.jst.j2ee.webapplication.WebApp extends AbstractWebApp In this case step 2 would look like: AbstractWebApp webApp = (AbstractWebApp) mp.getModelObject(); And step 3: EList servlets = webApp.getServlets(); This looks much nicer and the developer does not have to split his code logic. This will also work fine without modification if new models (Java EE 6 ?!) are introduced by the model provider. However, if the developer needs something special from the J2EE 1.4 or Java EE 5 model, he still will need to class cast the abstract interface to the specific one. I hope my example outlines the benefits of having common roots for the J2EE 1.4 and Java EE 5 models. Greetings, Kaloyan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carl Anderson Sent: Thursday, May 03, 2007 6:41 AM To: General discussion of project-wide or architectural issues. Subject: [wtp-dev] ArtifactEdits, Java EE 5, old code, and new code Folks, I am hesitant to write this note, but since Chuck is not available, and since there is quite a clamor about this, I thought I had better explain the state of things for Java EE support in WTP 2.0. (But I will leave Chuck the ability and right to clarify and or expound upon what I say here, when he returns.) First, we have always said that we would not be extending the previous J2EE 1.2 to 1.4 models and infrastructure to support Java EE 5 - there are just too many changes between J2EE 1.4 and Java EE 5, and there are quite a few drawbacks to our current models and infrastructure that we are hoping to overcome by providing some new layers to the Java EE code in WTP. Now, a brief review of our changes over the last few weeks: We added in the ability to create the various Java EE 5 projects/modules/components, and there was much rejoicing in the land. We added in the ability to run a Servlet 2.5 module on a server (such as Tomcat 6), and there was much rejoicing in the land. We added in the Java EE 5 models, and there was much rejoicing in the land. We added in a check in ArtifactEdit to see if it is being created on a validProjectVersion(), which throws an IllegalArgumentException (especially for ArtifactEdits created on Java EE 5 modules). This exception is caught (and ignored) in almost every getXXXArtifactEditForRead/Write() method, which then returns NULL. So, just when a lot of coders (improperly) thought that they could now get WebArtifactEdits for Dynamic Web Projects with a facet version of 2.5, they suddenly get NULL back (and open a Bugzilla about a NullPointerException in their code). Also note that this change should only effect the J2EE-type ArtifactEdits... other ArtifactEdits such as WSDDArtifactEdit should work on Java EE 5 modules as well as J2EE modules. And now, we added in org.eclipse.jst.j2ee.model.ModelProviderManager. If a coder passes in an IProject, he will get back an IModelProvider. In the case of J2EE 1.2-1.4 projects, the IModelProvider is the appropriate ArtifactEdit. (If you want, you can cast it to the appropriate ArtifactEdit subclass and utilize it as before.) In the case of Java EE 5, new IModelProviders are being fleshed out (only a basic skeleton is there at the moment). For our next trick, we hope to flesh out the new IModelProviders, add some helper classes, and perhaps even adding another layer to ease access to the stuff harbored within a Java EE 5 project. (But I am extremely leery of making any such announcement.... watch this space for details.) Then we will declare that that is as much Java EE 5 support as we can put into WTP 2.0. Now, please note (esp. David Williams) that we are NOT changing any of the current API. Any code that is written to use ArtifactEdits and their getXXXArtifactEditForRead/Write() methods (or any other public/protected method) will still work as before. No adopters should be broken by any of these changes, since the current API is not changing and still works the same. However, if you want your code to work for both J2EE 1.2-1.4 and Java EE 5, you should change your code over to ask the ModelProviderManager for the IModelProvider, and access the model from it. (Since trying to create a new ArtifactEdit will throw an exception, and asking for one for read or write will return NULL.) Questions? Comments? Send them this way. (Or bring them up at the JEE 5 call.) Sincerely, - Carl Anderson WTP programmer _______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
