Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Server Tools API changes

I will commit fixes for jst.generic.core.internal shortly. 

Gorkem Ercan

On Wed, 16 Mar 2005 09:40:11 -0500, Brad Blancett <blancett@xxxxxxxxxx> wrote:
> Hey Tim,   
> Thanks for your work, and we are a go for the integration build. 
> Its still early but, I did see some errors in the
> ...jst.generic.core.internal plugin. 
> Thanks, 
>  Brad Blancett
>  Rational Tools Developer
>  Tie  3-2650
>  Timothy Deboer <deboer@xxxxxxxxxx> 
> Sent by: wtp-dev-admin@xxxxxxxxxxx 
> 03/15/2005 11:14 AM 
> Please respond to wtp-dev         
>         To:        wtp-dev@xxxxxxxxxxx 
>         cc:         
>         Subject:        [wtp-dev] Server Tools API changes
>  Hi, 
>  Two new API changes for wst.server are being dropped immediately for this
> week's integration build. We'll work with the affected teams to make sure
> that references to these classes and methods get fixed quickly. 
>  Elson Yuen (lead for the WebSphere server adapter in Rational Application
> Developer) has been working with me on these changes, adding javadoc, and
> providing feedback on the API - Thanks Elson. 
>  1. ILaunchable 
>  The ILaunchable interface previously had all of it's methods removed, and
> was just being used as a marker interface. However, it was confusing given
> that the Eclipse debug team named an interface with exactly the same name,
> and it wasn't really providing any useful function. This interface will be
> removed and replaced with java.lang.Object wherever it was used. 
>  2. IModule parents 
>  This change is to solve several recurring problems with "module
> hierarchies" (trees of modules) in the API. When server types support
> modules that contain other modules, (e.g. a Web module contained in an EAR)
> the generic server had various issues representing this: 
>  a) In a few cases, we had the "parent" information, but it was provided via
> a clunky aMethod(IModule[] parents, IModule module). (e.g. aMethod(new
> IModule[] { EAR }, Web))  To improve this, we've merged the two parameters
> so that a module reference is just the path down the tree to uniquely
> identify the module. The method above would be changed to aMethod(IModule[]
> moduleTree). (e.g. aMethod(new IModule[] { EAR, Web })) 
>  b) In other cases, the "parent" information was missing. For instance, if a
> Web module was contained in two EARs, both copies of the Web module had the
> same started/stopped state, regardless of the state of the two EARs. In
> these cases, we've added the parent information as in the above case. 
>  c) When we had to pass around a complete list of modules and their parents
> on a server, things got worse. In one case, there was a "List[] parents,
> IModule[] modules". Under the new structure, this can be simplified to "List
> moduleTrees" which is just an array of IModule[]. 
>  Thanks, 
>  Tim deBoer
>  WebSphere Tools - IBM Canada Ltd.
>  (905) 413-3503  (tieline 969)
>  deboer@xxxxxxxxxx 

Gorkem Ercan

Back to the top