[jbosstools-issues] [JBoss JIRA] (JBIDE-20460) Add notion of maximum execution environment for servers

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-20460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100430#comment-13100430 ] 

Rob Stryker commented on JBIDE-20460:
-------------------------------------

If there is no known maximum, a client should return null.  The null is to be treated as no maximum (ie all higher versions will be acceptable). 

>  And I don't see in your explanation where the mapping of server X supports Y runtimes ? where is it actually defined ? Can you link to it ? 

I don't think I understnad your request here.  In a server adapter's plugin.xml, you declare your server, and it directly maps to a runtime. 

{code}
      <serverType
            behaviourClass="org.jboss.tools.as.core.server.controllable.internal.DeployableServerBehavior"
            class="org.jboss.ide.eclipse.as.core.server.internal.DeployableServer"
            description="%deploy.server.description"
            hasConfiguration="false"
            id="org.jboss.ide.eclipse.as.systemCopyServer"
            initialState="stopped"
            launchConfigId="org.jboss.ide.eclipse.as.core.server.startupConfiguration"
            launchModes="run"
            name="%deploy.server.name"
            runtime="false"
            runtimeTypeId="org.jboss.ide.eclipse.as.runtime.stripped"
            supportsRemoteHosts="true"/>
{code}

You can see clearly that the server type declaration includes   runtimeTypeId="org.jboss.ide.eclipse.as.runtime.stripped"

If, on the other hand, you mean where webtools server/runtime X supports Y version of java,  well, that's an internal detail which we've decided to implement primarily in our runtime, but the runtime pulls from our "ServerExtendedProperties", which has methods for getmin and getmax execution environments.   The classname is "JBossExtendedProperties" and has the following methods:

{code}
	public IExecutionEnvironment getDefaultExecutionEnvironment() {
		// NEW_SERVER_ADAPTER  Subclasses override this
		return EnvironmentsManager.getDefault().getEnvironment("J2SE-1.4"); //$NON-NLS-1$
	}
	
	public IExecutionEnvironment getMinimumExecutionEnvironment() {
		// NEW_SERVER_ADAPTER  Subclasses override this
		return getDefaultExecutionEnvironment();
	}
	
	// Return an exec-env or null if it can run on any higher exec-env. 
	public IExecutionEnvironment getMaximumExecutionEnvironment() {
		// NEW_SERVER_ADAPTER  Subclasses override this
		return null;
	}
{code}

So a subclass of JBossExtendedProperties such as Wildfly90ExtendedProperties  would override these methods as they see fit. 

> so if I change my execution environment or JDK setup after configuring this in the UI then there is no way to check at the core level wether the exec environment I'm using is valid before launch ? 

Of course that's possible.  The IRuntime is the object storing either the currently hard-coded jre or the hard-coded execution environment (depending on user selection).  Our launch would simply then ask the IRuntime for the JRE to be used, and then ask the utility classes if the given JRE is valid for the runtime type's min/max exec-environments as pulled from the IRuntime or its extended-properties class (both APIs point to the same code). 

Although I am a bit confused by what you mean when you say "so if I change my execution environment or JDK setup after configuring this in the UI".  Are you implying that you're changing the chosen execution environment for the runtime? That'd be done in the jbt astools server UI obviously.  Also, since hte IRuntime object is not stored in any user-visible file (its stored in webtools plugin metadata location in a shared file), there's no real way for the user to go customizing that.  

So if you're suggesting that you chose a hard-coded jre name (/home/max/java/jre7) and then simply deleted its contents and exploded a java8 inside it instead?  I expect that this wouldn't work properly until at least a workspace restart or something. But I have no reason to treat this as a valid usecase. 

If on the other hand you're suggesting that you're changing your workspace's default jre or default execution environment, then yes, there's still ways for this to work.  The launch scripts pull from our runtime object's  getVM  method, which does all the calculations based on min/max exec env,  currently selected jre or exec-env (as saved in the runtime),  and what the workspace currently resolves as its default values.  Either way, once that JRE is returned, the launch scripts can clearly then compare and see if its valid for the runtime's min/max. 

So the only usecase I would see where this is likely to break is if you're trying to be sneaky and deleting the contents of a java7 folder and replacing it with a java8, or something like that, and that's entirely due (if its a real issue) to the way JDT / Debug / Launching would be caching their reprensentation of a JRE in their model. 

I hope this answers all your questions. 


> Add notion of maximum execution environment for servers
> -------------------------------------------------------
>
>                 Key: JBIDE-20460
>                 URL: https://issues.jboss.org/browse/JBIDE-20460
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: server
>    Affects Versions: 4.3.0.CR1
>            Reporter: Rob Stryker
>            Assignee: Rob Stryker
>             Fix For: 4.3.0.CR1
>
>
> FuseIDE has a need for our various runtime composites to warn and properly display valid jre's that are within a range of java versions, rather than just a minimum.  At this point, I do not believe JBT itself has any runtimes that require this functionality, but we may in the future, so this is definitely a valid usecase. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)