Bug 162769

Comment 1 Chris Brealey 2006-11-01 08:38:14 EST

J2EE allows both standalone (eg. client app jar) and packaged applications (eg. an EAR containing a client app jar) to be deployed to a container. The Web Service wizard bases its decision to require, or not require, an EAR on the target server's declaration of requiring, or not requiring, EARs for the purpose of deployment. As far as I know, server tools does not specify the requirement, or lack thereof, of an EAR per module type. I will chat with the Server Tools team (Tim) about whether we need to do this. The alternative is to special-case our logic to make the EAR optional when assembling/deploying app clients despite what the target server's opinion is about needing EARs, but I'm not too comfy with this idea - not yet, anyways...

Thanks - CB.

Comment 2 Tim deBoer 2006-11-01 08:55:34 EST

Correct, this requirement doesn't come from the framework. I assume it was with a specific server adapter? We'll have to look at what the WS team uses to determine if an EAR is required, if this makes sense, and if the specific server adapter is returning correct information.

Comment 3 Kathy Chan 2008-02-01 16:14:00 EST

The code we used to check is:

ServerUtils.isTargetValidForEAR(serverTargetId, "13")

Tim, I believe we had discussed this before.  The current behaviour from server tooling API is to see if the server target can take EAR or not, but not if EAR can be optional.  So in the case where EAR is optional, it would still return true since the target is valid for EAR.  We seems to need a way to find out if EAR is optional or not. 

Comment 4 Kathy Chan 2008-02-19 16:10:15 EST

*** Bug 119165 has been marked as a duplicate of this bug. ***

Comment 5 Kathy Chan 2008-03-11 09:48:19 EDT

Andrew, over to you to make the change once Angel make the requested API change.

Comment 6 Angel Vera 2008-03-13 11:45:03 EDT

ServerUtils is the WebServices code, what is the call that you actually make to the wst.Server layer?

(In reply to comment #3)
> The code we used to check is:
> 
> ServerUtils.isTargetValidForEAR(serverTargetId, "13")
> 
> Tim, I believe we had discussed this before.  The current behaviour from server
> tooling API is to see if the server target can take EAR or not, but not if EAR
> can be optional.  So in the case where EAR is optional, it would still return
> true since the target is valid for EAR.  We seems to need a way to find out if
> EAR is optional or not. 
> 

Comment 7 Angel Vera 2008-03-13 11:47:31 EDT

Hmm.. I just found the equivalent bug for the wst.server side. 

It is interesting how bugzilla doesn't actually make a comment saying that this bug depends on another.. perhaps a feature request for bugzilla :)

(In reply to comment #6)
> ServerUtils is the WebServices code, what is the call that you actually make to
> the wst.Server layer?
> 
>

Comment 8 Kathy Chan 2008-03-13 12:59:50 EDT

Here's the code in ServerUtils:

public static boolean isTargetValidForEAR(String runtimeTargetId,
			String j2eeVersion) {
		if (runtimeTargetId == null)
			return false;

		String earModuleType = IModuleConstants.JST_EAR_MODULE;
		String stJ2EEVersion = ServerUtils.getServerTargetJ2EEVersion(j2eeVersion);
        List runtimes = Arrays.asList(ServerUtil.getRuntimes(earModuleType, stJ2EEVersion));
		for (int i = 0; i < runtimes.size(); i++) {
			IRuntime runtime = (IRuntime) runtimes.get(i);
			IRuntimeType runtimeType = runtime.getRuntimeType();
			if (runtimeType != null)
			{
				String thisId = runtimeType.getId();
				if (thisId.equals(runtimeTargetId))
					return true;
			}
		}

		return false;
	}

We could change this code to also pass in the module we plan to add to the EAR so that server tooling tell us if EAR is required or optional.

Comment 9 Kathy Chan 2008-03-26 09:43:02 EDT

Tim mentioned that server tooling might not be able to address prereq bug 218568.  Awaiting more info.

Comment 10 Kathy Chan 2008-03-26 14:14:33 EDT

Won't be able to fix this as server tooling does not plan to provide the necessary API (bug 218568 was rejected as "Won't fix") because the problem involved does not justify the work.

We could revisit if customer is running into serious problem with this limitation.

Comment 11 Kathy Chan 2008-06-11 15:48:17 EDT

Bug cleanup.  Closing on behalf of the originator.