October 2019 - jboss-jira - Jboss List Archives

[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: ------------------------------------- Could you please enable TRACE logging for org.jboss.as.jpa and attach the WildFly console output (or server.log) to this jira. Some instructions for doing that are at [https://docs.wildfly.org/17/Developer_Guide.html#troubleshooting]. I'm curious what [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] will show. Some points of reference for passing the beanManager and ValidationFactory into EclipseLink: [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] has constants for properties that should be passed into EclipseLink. [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] is the Map of properties that should be passed into EclipseLink. [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] is where we should be setting ValidationFactory in the "properties" map. [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] is where we should be passing the CDI bean manager in. [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] is where we actually pass the properties into EclipseLink. Scott > 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 > > 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> >  > <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)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-187) Changes to PVC are not reflected in Operator

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-187?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFWIP-187. ------------------------------- Resolution: Explained > Changes to PVC are not reflected in Operator > -------------------------------------------- > > Key: WFWIP-187 > URL: https://issues.jboss.org/browse/WFWIP-187 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Any chnages (adding, removing or updating) made to PVC after WildFlyServer CR was created are not reflected in underlying PVC kubernetes object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-211) emptyDir.sizeLimit not propagated to Pod Spec

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-211?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFWIP-211. ------------------------------- Resolution: Explained The operator is setting the configuration properly on the statefulset spec but it is discarded when running on OpenShift (while running on Kubernetes retains the sizeLimit) > emptyDir.sizeLimit not propagated to Pod Spec > --------------------------------------------- > > Key: WFWIP-211 > URL: https://issues.jboss.org/browse/WFWIP-211 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > # {code:yaml} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > name: operator-empty-dir > namespace: mchoma > spec: > applicationImage: 'registry.access.redhat.com/jboss-eap-7/eap72-openshift:1.1' > size: 1 > storage: > emptyDir: > medium: Memory > sizeLimit: 1Mi > {code} > # wait until pod are started and look into pod yaml definition "1 Mi" is not there > {code:yaml} > ... > serviceAccount: default > serviceAccountName: default > subdomain: operator-empty-dir-headless > terminationGracePeriodSeconds: 30 > volumes: > - emptyDir: > medium: Memory > name: operator-empty-dir-volume > - name: default-token-j2grg > secret: > defaultMode: 420 > secretName: default-token-j2grg > status: > conditions: > ... > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-196) Operator missing volumes from secrets and config maps

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-196?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFWIP-196. ------------------------------- Resolution: Done > Operator missing volumes from secrets and config maps > ------------------------------------------------------ > > Key: WFWIP-196 > URL: https://issues.jboss.org/browse/WFWIP-196 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Operator is missing way of configuring volumes from secets and config maps > - secrets > -- configuring keystore in ssl > -- configuring keystore for jgroups ASYNC encryption in jgroups (DNS_PING, KUBE_PING)) > - config map > -- Microprofile Config and reading properties from ConfigMap > -- running custom CLI script from config map (EAP7-892) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-223) disableHTTPRoute = true in runtime does not clean CR.status.hosts

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-223?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFWIP-223. ------------------------------- Resolution: Done > disableHTTPRoute = true in runtime does not clean CR.status.hosts > ----------------------------------------------------------------- > > Key: WFWIP-223 > URL: https://issues.jboss.org/browse/WFWIP-223 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Reproducer: > # create CR > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > disableHTTPRoute: false > {code} > # Edit CR with disableHTTPRoute: true. I would expect Route object will be deleted. > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > disableHTTPRoute: true > {code} > # Route object eap-cd is not deleted but status.hosts is still filled > {code:yaml} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > creationTimestamp: '2019-10-01T17:20:34Z' > generation: 2 > name: eap-cd > namespace: mchoma > resourceVersion: '629943' > selfLink: /apis/wildfly.org/v1alpha1/namespaces/mchoma/wildflyservers/eap-cd > uid: c7535f3f-e46f-11e9-b4ad-02e6008f3048 > spec: > applicationImage: >- > image-registry.openshift-image-registry.svc:5000/eapcd-suite-builds/eap-cd-openshift-rhel8:17.0-4 > disableHTTPRoute: false > env: [] > envFrom: [] > replicas: 1 > status: > hosts: > - >- > eap-cd-route-mchoma.apps.eap-qe-cluster105.eap-qe-cluster105.fw.rhcloud.com > pods: > - name: eap-cd-0 > podIP: 10.131.0.246 > state: ACTIVE > replicas: 1 > scalingdownPods: 0 > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12627) Upgrade wildfly-http-client to 1.0.17.Final

by Tomas Hofman (Jira)

[ https://issues.jboss.org/browse/WFLY-12627?page=com.atlassian.jira.plugin... ] Tomas Hofman moved JBEAP-17708 to WFLY-12627: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-12627 (was: JBEAP-17708) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Fix Version/s: (was: 7.3.0.GA) > Upgrade wildfly-http-client to 1.0.17.Final > ------------------------------------------- > > Key: WFLY-12627 > URL: https://issues.jboss.org/browse/WFLY-12627 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Tomas Hofman > Assignee: Cheng Fang > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFWIP-218: --------------------------------- Comment: was deleted (was: The problem is this issue is as follows: 1. transaction log on on server is cleared correctly 2. server's stateful-set is scaled down (pod referenced by client disappears) 3. client checks in-doubt resource but cannot connect to the server In OpenShift environment with wildfly-operator, we can be sure that if the server's stateful-set was scaled down correctly then it logs must have been cleared. As a result, client records can be discarded. This is not true in general (bare-metal) where the server may go down and still have records in the log. in the context of above I would propose: 1. workaround - provide the customer with a manual procedure (if connection error to the server's pod occurs but the pod was scaled down correctly remove log records). This is not elegant, but this is an emergency and I don't expect it to be used often. 2. solution - if operating within OpenShift client cannot connect to one of the server's pods, client checks with OpenShift API whether the server's pod was scaled down. If it was, the record can be discarded. I would suggest downgrading this issue with provided workaround and later work on the target solution (which would require OpenShift integration and has to be researched).) > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFWIP-218 > URL: https://issues.jboss.org/browse/WFWIP-218 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Blocker > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12313) Implement MP OpenAPI

by Michael Edgar (Jira)

[ https://issues.jboss.org/browse/WFLY-12313?page=com.atlassian.jira.plugin... ] Michael Edgar commented on WFLY-12313: -------------------------------------- Hi [~pferraro], please go ahead and add your comments in github and we can discuss anything of larger scope here. I was able to get the /openapi context working this week by using the {{org.wildfly.undertow.host}} capability with dynamic server and virtual host segments. Those two options are also configurable in the subsystem, but default to {{default-server}} and {{default-host}}. I am definitely open to any ideas/suggestions/improvements. > Implement MP OpenAPI > -------------------- > > Key: WFLY-12313 > URL: https://issues.jboss.org/browse/WFLY-12313 > Project: WildFly > Issue Type: Feature Request > Reporter: Michael Edgar > Assignee: Paul Ferraro > Priority: Major > > Please integrate MicroProfile OpenAPI. > Details about MP OpenAPI: > https://github.com/eclipse/microprofile-open-api/releases/tag/1.1.2 > Maybe it is possible to use SmallRye implementation: > https://github.com/smallrye/smallrye-open-api -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3065) Droolog: Prolog-like features/front-end in Drools

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3065?page=com.atlassian.jira.plugi... ] Edoardo Vacchi resolved DROOLS-3065. ------------------------------------ Resolution: Deferred > Droolog: Prolog-like features/front-end in Drools > ------------------------------------------------- > > Key: DROOLS-3065 > URL: https://issues.jboss.org/browse/DROOLS-3065 > Project: Drools > Issue Type: Epic > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4572) a fact with many properties causes a problem with "not" rule in executable-model

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4572?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4572: -------------------------------- Sprint: 2019 Week 38-40 (from Sep 16) > a fact with many properties causes a problem with "not" rule in executable-model > -------------------------------------------------------------------------------- > > Key: DROOLS-4572 > URL: https://issues.jboss.org/browse/DROOLS-4572 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.27.0.Final > Environment: - executable-model > - Without property reactive > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Priority: Major > Labels: support > > Under the conditions: > - executable-model > - "drools.propertySpecific" = "ALLOWED" > - A fact which has more than 128 properties > - A rule with "not" which joins facts > "not" doesn't match so the rule results in an unexpected firing (e.g. an infinite loop) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019