Brad,
I have taken more time to think about the
problem and your response and I realize I might not have framed the problem
very well. I would like to take a moment to try and clarify to make sure we are
going down the right path here.
If I am understanding your advice, you are
recommending adding a new top level module type, like J2EE Web or EJB Module
that would, in turn, contain Cactus-test artifacts. I think this isn’t
exactly what I need.
Ideally I would like a cactus test to live
in a WebModule, rather than it’s own specialized type since this is a
very common deployment scenario for them. Running a cactus test doesn’t
really require any specialized logic on the part of the server. All you have to
know is what context information to pass to the client to run the test. Then it
hits a servlet with the correct arguments and you are in business.
Is it correct to say that, currently, if
you want to be able to create a new type of deployable artifact, like a cactus
test, that is based on the ICompilationUnit that would reside in an existing
module type, you cannot do so without modifying that module? So, to give a
parallel example, if I want to add support for Page Flows in a WebModule, would
I be in a similar position? Would I have to modify the
WebDeployableArtifactUtil to recognize PageFlow servlets, too?
I might not understand your
recommendation, in which case I would ask for some clarification—offline,
if necessary. But if I do understand the problem and this is a real limitation,
I think we are going to run into it for a number of resources, like the
PageFlow example above. We often have JSR-175 adorned java classes which require
some additional massaging to run and my fear is that we are going to have to
have a new type of module for each one.
I apologize if I am just misunderstanding
your solution.
Thanks again for your help,
Dan
---
Daniel R Somerfield
BEA Systems
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Brad Blancett
Sent: Wednesday, April 06, 2005
6:51 AM
To: General discussion of
project-wide or architectural issues.
Subject: Re: [wtp-dev]
IModuleArtifact and Cactus Testing
Hey Daniel,
Tim
Deboer, fixed the module adapter collision problems associated in M3. In M4 you
can have adapters overlapping on compilation units. Currently, the EJB and Web
deployables are overlapping on multiple objects, ie IResource.. Filtering
occurs in the ArtifactAdapter, where deployables are returned by type:
ServerUtil.getModules("j2ee.web or j2ee.ejb")). This basically calls into
a plugin defined factory where you create/retrieve the deployables you are
interested in. I would recommend creating your own type with respect to cactus
testing. In this case you would be responsible for making sure the server
framework, can associate a server for this type. For minimal support, you could
mix deployables (catcus. and non cactus) using j2ee.* types. The user would
choose on the server wizard's last page which module to be deployed.
Ideally,
I would like to see the server framework utilize function groups/ activities.
The extra layer would add more flexibility for filtering deployables.
WebDeployableArtifact.getServletMapping(),
the J2EEWebNatureRuntimeUtilities.getJ2EERuntime(), this is
a bug, as of M4, you will not be able to create projects with J2EE
Natures. In fact migration is already in place to migrate old natrues to
ModuleCoreNatures. I will fix this to utilize the flexible framework.
Regardless, this wont be an issue if you create your own adapter.
Thanks,
Brad Blancett
IBM Software Solutions
Tie 3-2650
|
"Daniel Somerfield"
<dsomerfi@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
03/31/2005 06:38 PM
Please
respond to "General discussion of project-wide or architectural
issues."
|
To: <wtp-dev@xxxxxxxxxxx>
cc:
Subject: [wtp-dev]
IModuleArtifact and Cactus Testing
|
Hi all,
As I
mentioned previously, I am working on cactus testing for WTP. I think it
certainly makes sense in the long term to integrate server-side unit testing
with TPTP. However, until we get to that point, it would be nice to support
something, however minimal. Currently, I have a very simple launch shortcut for
executing cactus tests on the server. I have run into a couple of challenges,
however, and I wanted to get a little bit of feedback from the community.
In my
mind, the Cactus test case is very similar to the servlet case. You examine a
CompilationUnit and if it extends ServletTestCase, it is a WebResource. I was
able to do something similar (creating a WebTestableResource), but it required
a modification to WebDeployableArtifactUtil.getModuleObject() to do it. The
challenge is that the org.eclipse.jst.j2ee.web plugin has a
moduleArtifactAdapter enabled for ICompilationUnit and unless I am mistaken, I
can’t add my own moduleArtifactAdapter without clashing. Is this correct,
or can two adapter peacefully co-exist somehow?
The
other issue that started recently with the latest integration build (I20050331)
is that in WebDeployableArtifact.getServletMapping(), the
J2EEWebNatureRuntimeUtilities.getJ2EERuntime(). I was using that to validate
that the cactus servlet had been set up for the project that is being run. I
have had to disable that for now. Ultimately, I would like to automatically add
the servlet mapping when a test is run, but I have not figured that out how to
do that yet.
I
would be happy to share this code with anyone who is interested or I could post
it to the group, if that is deemed appropriate. I am using some internal APIs
and if there are more appropriate public APIs, I would definitely like to hear
about them.
Thanks,
Daniel
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev