Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] IModuleArtifact and Cactus Testing


Thank you very much for the information. This sounds exactly like what I want to hear. I do have a couple of follow-up questions, however. Some of them might be newbie questions since I am just starting with WTP. If so, I am happy to be referred to any resources I can use to catch up.


If I understand you correctly, I want to define a new org.eclipse.wst.server.core.moduleType. I am not entirely clear what, exactly, this entails. Does this mean creating a new moduleType, and new moduleFactory, and new moduleFactoryAdapter and a new launchableAdapter?


I am also unclear on what you mean by “mixing deployables”.


A lot of this terminology is new to me. Is there some kind of step-by-step tutorial—you know, something like “So You Want to Create a New Type”? If not, could you point me out to the best example of an implementation that is more or less parallel to what I am trying to do? If this tutorial doesn’t exist, I would be happy to write one as I go through enabling cactus launching. I just might need a little hand-holding on the way.


Thanks again for your help.





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.


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>
        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.
wtp-dev mailing list

Back to the top