[JBoss JIRA] (SWSQE-973) Make sure that cleaning job cleans all namespaces
by Filip Brychta (Jira)
Filip Brychta created SWSQE-973:
-----------------------------------
Summary: Make sure that cleaning job cleans all namespaces
Key: SWSQE-973
URL: https://issues.jboss.org/browse/SWSQE-973
Project: Kiali QE
Issue Type: QE Task
Reporter: Filip Brychta
Assignee: Filip Brychta
Problem with cleaning job is that it's called from install-maistra with parameters passed to install maistra. So in cases where the cluster contains more control planes from previous testing and one tries to reinstall it with one control plane it will only clean one leaving second there which is causing job to be stuck.
We need to clean always all namespaces for given app.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (JBEE-246) Jakarta EE BOMs
by Eduardo Martins (Jira)
[ https://issues.jboss.org/browse/JBEE-246?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins resolved JBEE-246.
----------------------------------
Resolution: Done
The following file system changes were applied:
/jboss-javaee-web -> /jboss-jakartaee-web
/jboss-javaee-all -> /jboss-jakartaee-all
And wrt pom.xml or README.md content, any maven coordinate with “javaee” string changed to “jakartaee”:
jboss-javaee-8.0 —> jboss-jakartaee-8.0
jboss-javaee-web-8.0 —> jboss-jakartaee-web-8.0
jboss-javaee-all-8.0 —> jboss-jakartaee-all-8.0
> Jakarta EE BOMs
> ---------------
>
> Key: JBEE-246
> URL: https://issues.jboss.org/browse/JBEE-246
> Project: JBoss Enterprise Spec APIs
> Issue Type: Enhancement
> Components: jboss-javaee-specs
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> The following JBoss BOM artifactIds should be renamed to not include javaee, replacing it with jakartaee8:
> jboss-javaee-8.0
> jboss-javaee-web-8.0
> jboss-javaee-all-8.0
> Ideally this should be done on a new repo jboss/jboss-jakartaee-specs, forked from jboss/jboss-javaee-specs
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12535) Container does not pass the beanManager when creating eclipselink EntityManagerFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12535?page=com.atlassian.jira.plugin... ]
Scott Marlow edited comment on WFLY-12535 at 10/9/19 3:30 PM:
--------------------------------------------------------------
>From a few years ago, [https://github.com/eclipse-ee4j/jpa-api/issues/70] ("Allow two phase bootstrap approach to creating the EntityManagerFactory") is for deploying persistence units via two phases, which WildFly does with Hibernate currently (via Hibernate extensions) but not EclipseLink.
For bean validator, perhaps there could be a workaround that we could do, like detecting that the bean validator factory is null and creating a new bean validator factory as a workaround.
For CDI, it is tougher to workaround [WFLY-12535] (other than setting the jboss.as.jpa.classtransformer to false) as initializing CDI (Weld), requires reading application classes, which must be done after the JPA persistence provider has enhanced entity classes (or entity classes will not be rewritten/enhanced by the persistence provider). When, jboss.as.jpa.classtransformer is set to false, entity classes are not enhanced (because the persistence unit is deployed/started after CDI has caused the application classes to be defined).
If EclipseLink implemented [https://github.com/eclipse-ee4j/jpa-api/issues/70], then WildFly could expect to run the first (JPA) bootstrap phase very early in deployment (at which time the EclipseLink class transformer can be registered, so that entity class transformation works), EclipseLink could then expect to not use the BeanValidator or CDI BeanManager until the second phase.
If EclipseLink also implemented [https://github.com/eclipse-ee4j/jpa-api/issues/83], that would also help with improving CDI integration + JPA listeners, which isn't really related to [WFLY-12535].
was (Author: smarlow):
>From a few years ago, [https://github.com/eclipse-ee4j/jpa-api/issues/70] ("Allow two phase bootstrap approach to creating the EntityManagerFactory") is for deploying persistence units via two phases, which WildFly does with Hibernate currently (via Hibernate extensions) but not EclipseLink.
For bean validator, perhaps there could be a workaround that we could do, like detecting that the bean validator factory is null and creating a new bean validator factory as a workaround.
For CDI, it is tougher to workaround [WFLY-12535] (other than setting the jboss.as.jpa.classtransformer to false) as initializing CDI (Weld), requires reading application classes, which must be done after the JPA persistence provider has enhanced entity classes.
If EclipseLink implemented [https://github.com/eclipse-ee4j/jpa-api/issues/70], then WildFly could expect to run the first (JPA) bootstrap phase very early in deployment (at which time the EclipseLink class transformer can be registered, so that entity class transformation works), EclipseLink could then expect to not use the BeanValidator or CDI BeanManager until the second phase.
If EclipseLink also implemented [https://github.com/eclipse-ee4j/jpa-api/issues/83], that would also help with improving CDI integration + JPA listeners, which isn't really related to [WFLY-12535].
> Container does not pass the beanManager when creating eclipselink EntityManagerFactory
> --------------------------------------------------------------------------------------
>
> Key: WFLY-12535
> URL: https://issues.jboss.org/browse/WFLY-12535
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 16.0.0.Final
> Reporter: charles ghislain
> Assignee: Scott Marlow
> Priority: Major
> Attachments: server.log, server.log
>
>
> When creating the entity manager factory for eclipseliknk using `javax.persistence.spi.PersistenceProvider#createContainerEntityManagerFactory`, wildfly does not pass the properties required by the jee8 spec, as specified in the javadoc of this method:
> {code}
> If a Bean Validation provider is present in the classpath, the container must pass the ValidatorFactory instance in the map with the key "javax.persistence.validation.factory". If the containing archive is a bean archive, the container must pass the BeanManager instance in the map with the key "javax.persistence.bean.manager"
> {code}
> Debugging the eclipselink implementation of this method, `org.eclipse.persistence.jpa.PersistenceProvider#createContainerEntityManagerFactory`, the properties set by the container contains the following 3 entries:
> {code:java}
> eclipselink.logging.logger -> org.jipijapa.eclipselink.JBossLogger
> eclipselink.archive.factory -> org.jipijapa.eclipselink.JBossArchiveFactoryImpl
> eclipselink.target-server -> org.jipijapa.eclipselink.WildFlyServerPlatform
> {code}
> I think this prevents CDI injection in custom ConstraintValidators, as mentionned on an old eclipselink thread: https://www.eclipse.org/lists/eclipselink-users/msg08503.html.
> I have a `ConstraintValidator` with an `@Inject`ed EJB, but when validation is triggered on the call to `javax.persistence.EntityManager#merge`, the injected field is null.
> The wildfly installation has been updated to include eclipselink as per documentation:
> the org.eclipse.persistence module has been updated to include the eclipselink jar with the following descriptor:
> {code:java}
> <module xmlns="urn:jboss:module:1.1" name="org.eclipse.persistence">
> <resources>
> <!-- jipijapa line is kept from the original module -->
> <resource-root path="eclipselink.jar">
> <filter>
> <exclude path="javax/**" />
> </filter>
> </resource-root>
> </resources>
> <dependencies>
> <module name="asm.asm"/>
> <module name="javax.api"/>
> <module name="javax.annotation.api"/>
> <module name="javax.enterprise.api"/>
> <module name="javax.persistence.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.validation.api"/>
> <module name="javax.xml.bind.api"/>
> <module name="javax.ws.rs.api"/>
> <module name="org.antlr"/>
> <module name="org.apache.commons.collections"/>
> <module name="org.dom4j"/>
> <module name="org.jboss.as.jpa.spi"/>
> <module name="org.jboss.logging"/>
> <module name="org.jboss.vfs"/>
> </dependencies>
> </module>
> {code}
> The persistence unit provider has been set to `org.eclipse.persistence.jpa.PersistenceProvider` in the persistence.xml file.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-238) SSO support should have dual security
by Jean Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFWIP-238?page=com.atlassian.jira.plugin.... ]
Jean Francois Denise updated WFWIP-238:
---------------------------------------
Description:
Currently SSO configuration uses elytron, it is a change with prior configuration.
SSO support should detect if security subsystem is present and use it if SSO_FORCE_LEGACY_SECURITY=true. Elytron being used only if legacy security subsystem is not there or if SSO_FORCE_LEGACY_SECURITY=false (default value).
EAP CD18 will set SSO_FORCE_LEGACY_SECURITY=true
was:
Currently SSO configuration uses elytron, it is a change with prior configuration.
SSO support should detect if security subsystem is present and use it. Elytron being used only if legacy security subsystem is not there.
This offers a backward compatible configuration.
Obviously this should be tuned in order to "modernize" the configuration by using elytron in all cases. That is made possible using the SSO_FORCE_ELYTRON_SECURITY=true.
That is what WildFly s2i is using by default.
> SSO support should have dual security
> -------------------------------------
>
> Key: WFWIP-238
> URL: https://issues.jboss.org/browse/WFWIP-238
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> Currently SSO configuration uses elytron, it is a change with prior configuration.
> SSO support should detect if security subsystem is present and use it if SSO_FORCE_LEGACY_SECURITY=true. Elytron being used only if legacy security subsystem is not there or if SSO_FORCE_LEGACY_SECURITY=false (default value).
> EAP CD18 will set SSO_FORCE_LEGACY_SECURITY=true
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12535) Container does not pass the beanManager when creating eclipselink EntityManagerFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12535?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-12535:
-------------------------------------
>From a few years ago, [https://github.com/eclipse-ee4j/jpa-api/issues/70] ("Allow two phase bootstrap approach to creating the EntityManagerFactory") is for deploying persistence units via two phases, which WildFly does with Hibernate currently (via Hibernate extensions) but not EclipseLink.
For bean validator, perhaps there could be a workaround that we could do, like detecting that the bean validator factory is null and creating a new bean validator factory as a workaround.
For CDI, it is tougher to workaround [WFLY-12535] (other than setting the jboss.as.jpa.classtransformer to false) as initializing CDI (Weld), requires reading application classes, which must be done after the JPA persistence provider has enhanced entity classes.
If EclipseLink implemented [https://github.com/eclipse-ee4j/jpa-api/issues/70], then WildFly could expect to run the first (JPA) bootstrap phase very early in deployment (at which time the EclipseLink class transformer can be registered, so that entity class transformation works), EclipseLink could then expect to not use the BeanValidator or CDI BeanManager until the second phase.
If EclipseLink also implemented [https://github.com/eclipse-ee4j/jpa-api/issues/83], that would also help with improving CDI integration + JPA listeners, which isn't really related to [WFLY-12535].
> Container does not pass the beanManager when creating eclipselink EntityManagerFactory
> --------------------------------------------------------------------------------------
>
> Key: WFLY-12535
> URL: https://issues.jboss.org/browse/WFLY-12535
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 16.0.0.Final
> Reporter: charles ghislain
> Assignee: Scott Marlow
> Priority: Major
> Attachments: server.log, server.log
>
>
> When creating the entity manager factory for eclipseliknk using `javax.persistence.spi.PersistenceProvider#createContainerEntityManagerFactory`, wildfly does not pass the properties required by the jee8 spec, as specified in the javadoc of this method:
> {code}
> If a Bean Validation provider is present in the classpath, the container must pass the ValidatorFactory instance in the map with the key "javax.persistence.validation.factory". If the containing archive is a bean archive, the container must pass the BeanManager instance in the map with the key "javax.persistence.bean.manager"
> {code}
> Debugging the eclipselink implementation of this method, `org.eclipse.persistence.jpa.PersistenceProvider#createContainerEntityManagerFactory`, the properties set by the container contains the following 3 entries:
> {code:java}
> eclipselink.logging.logger -> org.jipijapa.eclipselink.JBossLogger
> eclipselink.archive.factory -> org.jipijapa.eclipselink.JBossArchiveFactoryImpl
> eclipselink.target-server -> org.jipijapa.eclipselink.WildFlyServerPlatform
> {code}
> I think this prevents CDI injection in custom ConstraintValidators, as mentionned on an old eclipselink thread: https://www.eclipse.org/lists/eclipselink-users/msg08503.html.
> I have a `ConstraintValidator` with an `@Inject`ed EJB, but when validation is triggered on the call to `javax.persistence.EntityManager#merge`, the injected field is null.
> The wildfly installation has been updated to include eclipselink as per documentation:
> the org.eclipse.persistence module has been updated to include the eclipselink jar with the following descriptor:
> {code:java}
> <module xmlns="urn:jboss:module:1.1" name="org.eclipse.persistence">
> <resources>
> <!-- jipijapa line is kept from the original module -->
> <resource-root path="eclipselink.jar">
> <filter>
> <exclude path="javax/**" />
> </filter>
> </resource-root>
> </resources>
> <dependencies>
> <module name="asm.asm"/>
> <module name="javax.api"/>
> <module name="javax.annotation.api"/>
> <module name="javax.enterprise.api"/>
> <module name="javax.persistence.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.validation.api"/>
> <module name="javax.xml.bind.api"/>
> <module name="javax.ws.rs.api"/>
> <module name="org.antlr"/>
> <module name="org.apache.commons.collections"/>
> <module name="org.dom4j"/>
> <module name="org.jboss.as.jpa.spi"/>
> <module name="org.jboss.logging"/>
> <module name="org.jboss.vfs"/>
> </dependencies>
> </module>
> {code}
> The persistence unit provider has been set to `org.eclipse.persistence.jpa.PersistenceProvider` in the persistence.xml file.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months