[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=13099639#comment-13099639 ] 

Rob Stryker edited comment on JBIDE-20460 at 8/18/15 11:45 PM:
---------------------------------------------------------------

There is a relationship between execution environments which we've been using already. Our class VMInstallUtil   has utility methods for discovering these super-environments. For example, IExecutionEnvironment  has a method public IExecutionEnvironment[] getSubEnvironments();

So if we have the java6 exec-env in our hand, we can query all existing execution environments to find out if java6 is one of their sub environments. 

It is not our server adapters, but rather our runtimes, that customize this behavior, at least theoretically.  The behavior is initially driven by the UI, but the APIs they use would exist in the runtime (but we don't currently implement it). 

So, how an extender would implement this is as follows:
  1) Their UI class (wizard fragment) probably has a subclass of AbstractJREComposite in it
  2) Their AbstractJREComposite has a method they should implement:  public IExecutionEnvironment getMaximumExecutionEnvironment() 
  3) The suggested method of implementing this is to have your composite query your runtime, as both Karaf/Fuse and JBoss/WF/EAP servers currently do.  Example for minimum:

{code}
		public IExecutionEnvironment getMinimumExecutionEnvironment() {
			IRuntime r = getRuntimeFromTaskModel();
			IKarafRuntime jbsrt = (IKarafRuntime)r.loadAdapter(IKarafRuntime.class, null);
			return jbsrt.getMinimumExecutionEnvironment();
		}
{code}

This has been in existence a while, so now we just added a similar maximum method. It's suggested implementers also update their internal interfaces if they require this, or, they could pull from their Extended Server Properties if they choose to store it there instead. 

It's also strongly suggested that if they have a method called getValidJREs() on their IRuntime interface (which ASTools and Karaftools do), that they make use of the various utility methods in VMInstallUtil and update this method's list of return values. 

More signatures were also added to this class for more fine-grained behavior (for example if your runtime prefers the lowest jre that fits the minimum environment, as opposed to other runtimes which may prefer to resolve to the maximum). 


was (Author: rob.stryker):
There is a relationship between execution environments which we've been using already. Our class VMInstallUtil   has utility methods for discovering these super-environments. For example, IExecutionEnvironment  has a method public IExecutionEnvironment[] getSubEnvironments();

So if we have the java6 exec-env in our hand, we can query all existing execution environments to find out if java6 is one of their sub environments. 

It is not our server adapters, but rather our runtimes, that customize this behavior, at least theoretically.  The behavior is initially driven by the UI, but the APIs they use would exist in the runtime (but we don't currently implement it). 

So, how an extender would implement this is as follows:
  1) Their UI class (wizard fragment) probably has a subclass of AbstractJREComposite in it
  2) Their AbstractJREComposite has a method they should implement:  public IExecutionEnvironment[] getSubEnvironments();
  3) The suggested method of implementing this is to have your composite query your runtime, as both Karaf/Fuse and JBoss/WF/EAP servers currently do.  Example for minimum:

{code}
		public IExecutionEnvironment getMinimumExecutionEnvironment() {
			IRuntime r = getRuntimeFromTaskModel();
			IKarafRuntime jbsrt = (IKarafRuntime)r.loadAdapter(IKarafRuntime.class, null);
			return jbsrt.getMinimumExecutionEnvironment();
		}
{code}

This has been in existence a while, so now we just added a similar maximum method. It's suggested implementers also update their internal interfaces if they require this, or, they could pull from their Extended Server Properties if they choose to store it there instead. 

It's also strongly suggested that if they have a method called getValidJREs() on their IRuntime interface (which ASTools and Karaftools do), that they make use of the various utility methods in VMInstallUtil and update this method's list of return values. 

More signatures were also added to this class for more fine-grained behavior (for example if your runtime prefers the lowest jre that fits the minimum environment, as opposed to other runtimes which may prefer to resolve to the maximum). 

> 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)