Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 111341

Summary:	Enhancements to API used to install a module on server
Product:	[WebTools] WTP ServerTools	Reporter:	Rupam Kuehner <rsinha>
Component:	wst.server	Assignee:	Tim deBoer <deboer>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P4	CC:	cbrealey, gorkem.ercan, kathy
Version:	1.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:
Bug Depends on:
Bug Blocks:	119165

Description Rupam Kuehner

2005-10-03 11:25:19 EDT

Opening this to request enhancements to the API used to install modules on 
servers. 

Background/Motivation
---------------------

The Web service wizard's mission is to guide users through end-to-end Web 
service creation and as part of this mission, it automatically installs modules 
onto servers in order to leave the user with a running Web service at the end 
of the wizard flow. Currently, we ask the user to select an EAR whenever EARs 
can be installed on the selected the server type. There are two things that are 
not good about this approach:

1. We have plans to push much of the Web service API into the WST layer and so 
can't be referring to EARs on our API

2. Just because a server type supports EARs doesn't mean that EARs are the only 
type of module that can be added to servers of that type.

Requirements
------------
We'd like to be able to ask the following questions:

1. Given a module type (or group of facets) and a server type, can the module 
be installed on the server directly, as in not via a root/parent module.

If the answer is yes, we're done.
If the answer is that the module can be installed but not directly, we need to 
get more information from the user regarding what they want installed on the 
server:

2. A UI widget, with an associated data model and operation, from the server 
tools API that we could render to collect the additional information. The data 
model would hold the information and we would run any associated operations.
The API to add a module to a server could then optionally take in this data 
model.

I realize the requirments here are a bit sketchy but I think it's enough to 
give you the gist of the kind of thing we're looking for. We'll need to discuss 
this further is person.

Comment 1 Tim deBoer

2005-10-04 14:52:13 EDT

Hi,
Since we're in the same office, please book a meeting to discuss. We can post
further details here once we've had a chance to meet.

Comment 2 Tim deBoer

2005-11-09 12:56:35 EST

Hi,
Are you going to book a meeting or post further details? Is this requirement
already covered?

Comment 3 Tim deBoer

2005-11-09 14:47:04 EST

Response from Rupam and Chris via email indicates that this is not required
until 1.5.

Comment 4 Kathy Chan

2006-01-11 17:12:58 EST

Please note that we need at least Requirement 1 in order to properly enable/disable the EAR field for servers that can take Web module directly or in an EAR (e.g. Geronimo server).  This is the problem reported in bug 119165.  So I think we should at least consider the first requirement for WTP 1.5.

Comment 5 Kathy Chan

2006-11-23 16:04:37 EST

I think what we need for WTP 2.0 is item #1 in bugzilla 111341.  Item #2 is nice to have but we understand we might not get there soon.  That is, in the case where a project or a server might or might not already exist, just given the project types/facets and server type, we would like to find out if the server:

1. Do not accept EAR (e.g. Tomcat).
2. Always require EAR (e.g. current implementation of WAS)
3. Accept both WAR and EAR (e.g. Geronimo)

Keep in mind that we are collecting this information on page 1 of the Web service wizard.  The project or server might or might not exist yet but we need to find out if we need to ask for EAR information (determine if it is required, optional or not required).  The wizard is doing all the necessary project creation, EAR creation and server creation for the user.

Comment 6 Tim deBoer

2006-11-27 09:28:06 EST

IRuntimeType.getModuleTypes() returns the types of modules that the server supports. Would it be enough if for each module type there was also way to tell whether it could normally be used as a 'root' module on the server? i.e., a flag that indicates that the module type can be added to the server directly:

Tomcat
  Web - true

WebSphere
  EAR - true
  Web - false
  EJB - false
  ...

Note that any of this is a 'best-guess' at the point you're trying to get the information. Like IURLProvider, there is no way to determine absolutely if a module that hasn't been created can be added to a server that hasn't been created. Once both have been created and you'll still need to handle failure from canModifyModules() or modifyModules().

Comment 7 Kathy Chan

2006-11-27 13:28:51 EST

Yes.  It looks like with this new piece of information, I can tell if a server would always require, can accept or do not accept EARs.

So for Geronimo, it would return:

  EAR - true
  Web - true
  EJB - true

Comment 8 Tim deBoer

2011-01-20 10:32:08 EST

Old bug, no plan to fix. Please reopen if this is still a problem.