[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] IModuleArtifact and Cactus Testing
|
Brad,
Do you think we will need a better solution than modifying our
ArtifactAdapters for every new artifact introduced, since the same
problem will be in our hands if a user tries to provide a struts or
page flow artifact. The user artifactAdapter may be shadowed by our
ArtifactAdapters if they are valid for the same module type. The only
solution I can think of right now is to have a priority level for each
adaptor so that a test servlet adaptor has priority over a servlet
adaptor.
--
Gorkem Ercan
On Apr 7, 2005 1:32 PM, Brad Blancett <blancett@xxxxxxxxxx> wrote:
>
> 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
>
>
>
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
>
>
