[
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
