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


Gorkem,

Your are right, in the long term, some sort of priority through function groups or activities is the proper solution. I dont think server tooling has had to deal with this situation yet considering our deployables have been its main consumer. The options right now are:  you either shadow, or have two modules representing the same J2EE resources and it would be up to the user to decide which  to deploy at runtime. Neither of these are really good solutions. Daniel, I hope this discussion has helped you. I would recommend opening a function request against server tooling. Please email me if you have any questions.

Thanks for you comments,


Brad Blancett
IBM Software Solutions
Tie  3-2650



Gorkem Ercan <gorkem.ercan@xxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/07/2005 08:35 AM
Please respond to gercan,"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,
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
>
>
>
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev


Back to the top