RE: [wtp-dev] IModuleArtifact and Cactus Testing

[Brad Blancett <blancett@xxxxxxxxxx>]

Hey Daniel,

I wasnt exactly sure how Cactus worked,
and I appreciate your clarification. I agree, for the shortterm, if this
is just for setting up context information
to pass to the client then leveraging
or creating your own moduleArtifactAdapter
to return a WebTestableResource
would be a viable solution.  If you create your own moduleArtifactAdapter,
which I recommend since this code is still internal, then the current adapter
would need logic not to create WebResources and defer to your adapter.
I would be happy to work with you on adding this function, please open
a defect or email me directly.

Thanks,



 Brad Blancett
 IBM Software Solutions
 Tie  3-2650

"Daniel Somerfield" <dsomerfi@xxxxxxx> Sent by: wtp-dev-bounces@xxxxxxxxxxx 04/06/2005 06:23 PM Please respond to "General discussion of project-wide or architectural issues."

To:        "General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>         cc:                 Subject:        RE: [wtp-dev] IModuleArtifact and Cactus Testing

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_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev