[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-dev] ArtifactEdits, Java EE 5, old code, and new code
|
Hi Chuck,
Yes, I will track the requirements and also will try to get
deeper in the issue myself.
I realize that it is a lot of work and is not achievable
for WTP 2.0.
The general agreement for doing it is more than enough.
Greetings,
Kaloyan
Hi, I have been away, sorry for not responding
earlier. I completely agree it would
be useful to create a simple common interface for "all" versions, and this can
be done selectively, and where it makes sense. We have made good progress simplifying the new JEE5
interfaces (removing EMF signatures), and we don't want to introduce any
more complexity. Kaloyan, can you track
the requirements for a common interface between versions?
I would expect a common interface for common
structural models such as Applications, EJBJar's, and Web Applications, and
perhaps some of the root the containment objects (Servlets, Beans etc..).
Whatever we decide, the IModelProvider
interface isn't tied to a specific interface, but utility classes could use the
common interfaces. I'm thinking these
details are more appropriate post WTP 2.0 - especially if we agree the new JEE5
model api's are provisional, and can be modified for these types of
revisions. Gary - I'll check on the
new factory class - it should be public. - Chuck
Rational Java
Enterprise Tooling Team Lead
IBM Software Lab - Research Triangle Park,
NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L:
444)
"Gerry Kessler"
<gerry.kessler@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
05/07/2007 04:32 PM
|
Please respond
to
"gerry.kessler@xxxxxxxxxx" <gerry.kessler@xxxxxxxxxx>;
Please respond to
"General discussion of project-wide or
architectural issues."
<wtp-dev@xxxxxxxxxxx> |
|
|
To
| "General discussion of project-wide
or architectural issues." <wtp-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| RE: [wtp-dev] ArtifactEdits, Java
EE 5, old code, and new code |
|
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:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]On 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
jlanuti@xxxxxxxxxx
t/l 441-7861
"Raev, Kaloyan"
<kaloyan.raev@xxxxxxx>
Sent by:
wtp-dev-bounces@xxxxxxxxxxx
05/03/2007 12:20 PM
|
Please respond
to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx> |
|
|
To
| "General discussion of
project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
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:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] 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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev
mailing
list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing
list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
