Community
Participate
Working Groups
Build Identifier: If a runtime server has more than 1 JDK that can be used, the Java facet version in the default configuration preset should be the one used by the selected runtime, not the latest version supported by the server. See code: org.eclipse.wst.common.project.facet.core.internal.DefaultFacetsExtensionPoint.getDefaultFacets() has fv = f.getLatestSupportedVersion( runtime ); Reproducible: Always Steps to Reproduce: 1.Create a new EJB project and select targeted runtime to IBM WAS v8.5 2.In the Configuration field, select "Default Configuration for WebSphere Application Server" 3.Click Modify, the version of Java facet is 1.7, should be 1.6
We could possibly still use the same api, but determine if a delaging class could override simple extension point declarations.. If server supports both java 1.6, and 1.7, but the specific instance only supports 1.6. Then we would want f.getLatestSupportedVersion( runtime ); to return 1.6. Is there a mechanism for overriding this behavior - something similar to IDefaultVersionProvider, but with a link to the runtime?
There should be sufficient API already to achieve the behavior that you are after. Here is how it works... The runtime delegate (part of server tools API) is responsible for controlling which JRE is associated with the server runtime. There is a bridge that takes the specified JRE and turns it into a JRE runtime component that the faceted project framework can understand. At this point, you will have runtime components components like JRE 1.5, JRE 1.6, JRE 1.7, etc. The getLatestSupportedVersion() API then works within the constraints of that runtime component. So, if you have a server that can use either Java 6 or Java 7, you need to make sure that the appropriate JRE is returned by the runtime delegate. How you do that is up to the particular server adapter. You can read some configuration files in the installation, you can prompt user to select JRE on the runtime configuration screen, etc.
Thanks for your input. I reopened this defect since I think the implementation of org.eclipse.wst.common.project.facet.core.internal.ProjectFacet.getLatestSupportVersion() method should be modified based on the discussion. The current implementation has: public IProjectFacetVersion getLatestSupportedVersion( final IRuntime r ) { for( IProjectFacetVersion fv : getSortedVersions( false ) ) { if( r.supports( fv ) ) { return fv; } } return null; } It returns the highest version of the facet read from metadata. It should get the version from the IRuntime object.
No. The code is correct. If your runtime is configured to use Java 6, r.supports(fv) will return false for fv == Java 7. If this isn't what you are seeing, the problem is in what WebSphere adapter is feeding the framework.
Hi, Konstantin Thanks for your prompt response. In my case, I have a BridgedRuntime object passed in to the ProjectFacet.getLatestSupportedVersio() method where the ProjectFacet is a Java facet. BridgedRuntime.supports() method has: public synchronized boolean supports( final IProjectFacetVersion fv ) { if( fv.getPluginId() == null ) { return true; } final List<IRuntimeComponent> comp = getRuntimeComponents(); if( this.supported == null || ! this.composition.equals( comp ) ) { this.supported = RuntimeManagerImpl.getSupportedFacets( comp ); this.composition = comp; } return this.supported.contains( fv ); } The value of supported set is returned from RuntimeManagerImpl.getSupportedFacets() which returns a subset of supportMappings built up while reading metadata. If in the server runtime plugin.xml, it has <supported> <runtime-component id="***runtime" version="aVersion"/> <facet id="jst.java" version="1.4,5.0,6.0,1.7"/> </supported> Then r.supports(fv) will return true for fv == Java 7 Not sure whether I understand your original comment about the runtime delegate should return the correct JDK version. To me, this part of the code should be modified to return the version of JDK used by the runtime. Maybe IJavaRuntime.getVMInstall() should be used. Thanks,
> If in the server runtime plugin.xml, it has > > <supported> > <runtime-component > id="***runtime" > version="aVersion"/> > <facet > id="jst.java" > version="1.4,5.0,6.0,1.7"/> > </supported> > > Then r.supports(fv) will return true for fv == Java 7 Remove the above declaration and you should get the behavior your after (assuming nothing else in the server adapter needs fixing). You shouldn't be providing a supports declaration from your server runtime to java facet. WTP already contains correct support mappings between JRE runtime component and Java facet. Please don't re-open this again. I don't mind helping you figure out how this API works, but there is nothing to be gained from changing the bug status.
Hi, Konstantin Sorry for keeping on reopen the defect. I thought it was the correct process to get people's attention since I truly thought the problem was at the WTP side at that time. As your suggested, I removed the support declaration from my server runtime to java facet. The Java facet version got the correct version with respect to the version of JDK used by the runtime. Thank you very much for your help. Christine
No problem. Glad we got this sorted out.
