Updating MicroProfile versions on server.xml causes issues with install manager

[Emily-Jiang]

1: use start.micropropfile.io to create.an app
2. update pom.xml with microrpofile version to 5.0 and server.xml to microProfile-5.0 on server.xml for both service-a and service-b
3. used transformer to transform all of the sources to jakarta
4. start my new jakarta app using mvn clean liberty:dev
5. got the following error

[INFO] [ERROR ] CWWKF0044E: The cdi-3.0 and io.openliberty.distributedMapInternal-1.0 features cannot be loaded at the same time. The cdi-3.0 feature of Jakarta EE 9 is incompatible with the io.openliberty.distributedMapInternal-1.0 feature of Java EE 6. The microProfile-5.0 and microProfile-5.0 configured features include an incompatible combination of features. Your configuration is not supported. Update the configuration to use features that support either the Jakarta EE or Java EE programming models, but not both.
[INFO] [WARNING ] CWWKF0046W: The configuration includes an incompatible combination of features. As a result, the feature manager did not install any features.

[Azquelt]

After resolving the features which are needed, the RepositoryResolver has to create lists of which features to install. There's a list of everything needed for each requested feature and one for each auto-feature. When creating the install lists, it's traversing the dependencies but stops traversing when it finds a dependency which is installed.

If distributedMap-1.0 is installed but distributedMapInternal-1.0 is not, it stops traversing dependencies when it hits distributedMap-1.0 and distributedMapInternal-1.0 is not added to the list.

When building the install lists, I think we need to trace down the entire dependency tree, build the list and finally remove any features which are already installed.

This bug has always been present but is being exposed now because we are making greater use of tolerates, particularly in our internal features, to support EE8 and EE9+ without making multiple public features.

[jhanders34]

I was also able to easily reproduce this by:

1. Get open liberty javaee8 zip file
2. Create new server and put in a feature list of webProfile-9.1 in the server.xml
3. Run featureUtility to install server features
4. Start server.

The featureUtility did not install any of the internal.ee-9.0.mf feature files so the server fails to start because they are not found.

[mbroz2]

@Azquelt or @Emily-Jiang plz update the description using the bug report template

[Azquelt]

All the relevant info needed to diagnose the problem was included in the description, why does it need to match the template now that the problem is fixed?

[jhanders34]

@Azquelt because it is a release bug and is linked from the fix list for 22.0.0.2.

[r-uu]

I see the "incompatible combination of features" when I try to lauch openliberty 22.0.0.8 in docker:

Launching defaultServer (Open Liberty 22.0.0.8/wlp-1.0.67.cl220820220719-1056) on Eclipse OpenJ9 VM, version 17.0.4.1+1 (en_US)
[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml
[ERROR   ] CWWKF0044E: The jsonb-2.0 and io.openliberty.distributedMapInternal-1.0 features cannot be loaded at the same time. The jsonb-2.0 feature of Jakarta EE 9 is incompatible with the io.openliberty.distributedMapInternal-1.0 feature of Java EE 6. The jsonb-2.0 and restConnector-2.0 configured features include an incompatible combination of features. Your configuration is not supported. Update the configuration to use features that support either the Jakarta EE or Java EE programming models, but not both.
[ERROR   ] CWWKF0033E: The singleton features io.openliberty.servlet.api-5.0 and io.openliberty.servlet.api-3.0 cannot be loaded at the same time.  The configured features mpOpenAPI-3.0 and restConnector-2.0 include one or more features that cause the conflict. Your configuration is not supported; update server.xml to remove incompatible features.
[WARNING ] CWWKF0046W: The configuration includes an incompatible combination of features. As a result, the feature manager did not install any features.
[AUDIT   ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 1.763 seconds.

Any suggestions? Any additional information I could provide?

[jhanders34]

Is this the same scenario or something else? What does your server.xml and Dockerfile look like?

[r-uu]

server.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE xml>
<server description="open liberty taggable server">

	<!-- enable features -->

	<featureManager>
		<feature>cdi-3.0</feature>
		<feature>jsonp-2.0</feature>
		<feature>jsonb-2.0</feature>
		<feature>persistence-3.0</feature>
		<feature>persistenceContainer-3.0</feature>
		<feature>restConnector-2.0</feature>
		<feature>restfulWS-3.0</feature>
		<feature>mpConfig-3.0</feature>
		<feature>mpOpenAPI-3.0</feature>
		<feature>mpRestClient-3.0</feature>
	</featureManager>

	<!-- define variables and their values -->
	<variable name="default.http.port"     defaultValue="9080"     />
	<variable name="default.https.port"    defaultValue="9443"     />
	<variable name="default.host.name"            value="*"/>

	<!-- This template enables security. To get the full use of all the capabilities, 
	     a keystore and user registry are required. -->

	<!-- For the keystore, default keys are generated and stored in a keystore. 
	     To provide the keystore password, generate an encoded password using bin/securityUtility 
	     encode and add it below in the password attribute of the keyStore element. 
	     Then uncomment the keyStore element. -->
	<!-- <keyStore password=""/> -->

	<!--For a user registry configuration, configure your user registry. For 
	    example, configure a basic user registry using the basicRegistry element. 
	    Specify your own user name below in the name attribute of the user element. 
	    For the password, generate an encoded password using bin/securityUtility 
	    encode and add it in the password attribute of the user element. Then uncomment 
	    the user element. -->
	<basicRegistry id="basic" realm="BasicRealm">
		<user name="admin" password="admin"/>
	</basicRegistry>

	<administrator-role>
		<user>admin</user>
	</administrator-role>

	<!-- <remoteFileAccess> -->
	<!-- </remoteFileAccess> -->

	<httpEndpoint id       ="defaultHttpEndpoint"
	              httpPort ="${default.http.port}"
	              httpsPort="${default.https.port}"
	              host     ="${default.host.name}"/>

	<dataSource id           ="PostgresDS"
	            jndiName     ="jdbc/PostgresDS"
	            jdbcDriverRef="postgresql-driver"
	            type         ="javax.sql.ConnectionPoolDataSource"
	            transactional="true">
		<properties serverName  ="${datasource_server_host}"
		            portNumber  ="${datasource_server_port}"
		            databaseName="${datasource_database}"
		            user        ="${datasource_database_username}"
		            password    ="${datasource_database_password}"/>
	</dataSource>

	<jdbcDriver id                                  ="postgresql-driver"
	            jakarta.sql.XADataSource            ="org.postgresql.xa.PGXADataSource"
	            jakarta.sql.ConnectionPoolDataSource="org.postgresql.ds.PGConnectionPoolDataSource"
	            libraryRef                          ="postgresql-driver-library"/>

	<library id="postgresql-driver-library">
		<fileset id      ="PostgreSQLFileset"
		         dir     ="${shared.resource.dir}/"
		         includes="postgresql-42.4.0.jar"/>
	</library>

	<!-- Automatically expand WAR files and EAR files -->
	<applicationManager autoExpand="true"/>

	<!-- configures the application on a specified context root -->
	<webApplication contextRoot="/"
	                location="taggable.war"
	                name="taggable"/>

	<!-- Default SSL configuration enables trust for default certificates from the Java runtime -->
	<ssl id="defaultSSLConfig" trustDefaultCerts="true"/>

</server>

docker-compose.yml:

version: "3.7"

volumes:
  postgres_data:
    driver: local

services:
  postgres:
    container_name: postgres
    image: postgres:latest
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./database-init/init-taggable.sql:/docker-entrypoint-initdb.d/init-taggable.sql
    environment:
      POSTGRES_DB: taggable
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    ports:
      - 5432:5432
    networks:
      - taggable-network

  zookeeper:
    container_name: zookeeper
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - 22181:2181
    networks:
      - taggable-network

  kafka1:
    container_name: kafka1
    image: confluentinc/cp-kafka:latest
    hostname: kafka1
    depends_on:
      - zookeeper
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka1:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
    ports:
      - 29092:29092
    networks:
      - taggable-network

  kafdrop:
    container_name: kafdrop
    image: obsidiandynamics/kafdrop:latest
    ports:
      - 9000:9000
    environment:
      - KAFKA_BROKERCONNECT=kafka1:9092
    depends_on:
      - kafka1
    networks:
      - taggable-network

  open-liberty:
    container_name: open-liberty-taggable
    build: ./../../../../app/taggable/server/openliberty
    image: openliberty:latest
    depends_on:
      - postgres
    links:
      - "postgres"
    environment:
      - datasource_server_host=postgres
    ports:
      - "9080:9080"
      - "9443:9443" # HTTPS listener
    networks:
      - taggable-network

networks:
    taggable-network:
        driver: bridge
        name: taggable-network

[jhanders34]

I assume you pasted the wrong thing for the docker content since it is the same as the server.xml output.

[r-uu]

Sorry, you are right. I updated my post.