August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13714) JPA PersistenceUnitInfo.persistenceUnitRootUrl vfs URL should be resolved

by Scott Marlow (Jira)

[ https://issues.redhat.com/browse/WFLY-13714?page=com.atlassian.jira.plugi... ] Scott Marlow commented on WFLY-13714: ------------------------------------- Is this for a particular Java persistence provider that you care to mention? >From [Persistence 3.0 SPEC|https://jakarta.ee/specifications/persistence/3.0/persistence_3.0-RC2.html#a13160] which is the same as earlier JPA versions: {code} /** * Returns the URL for the jar file or directory that is the * root of the persistence unit. (If the persistence unit is * rooted in the WEB-INF/classes directory, this will be the * URL of that directory.) * The URL will either be a file: URL referring to a jar file * or referring to a directory that contains an exploded jar * file, or some other URL from which an InputStream in jar * format can be obtained. * @return a URL referring to a jar file or directory */ public URL getPersistenceUnitRootUrl(); {code} The last form can also be used ("some other URL from which an InputStream in jar format can be obtained"). I do agree that your suggestion would be easier for the persistence provider to deal with. > JPA PersistenceUnitInfo.persistenceUnitRootUrl vfs URL should be resolved > ------------------------------------------------------------------------- > > Key: WFLY-13714 > URL: https://issues.redhat.com/browse/WFLY-13714 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 20.0.1.Final > Reporter: Java Java > Assignee: Scott Marlow > Priority: Major > > Wildlfy passes a PersistenceUnitInfo object to JPA provider using vfs URL as persistenceUnitRootUrl, e.g., > vfs:/C:/wildfly-20.0.1.Final/bin/content/foo.ear/myejb.jar/ > A JPA provider can not resolve this URL without using a third-party library and thus force > the JPA provider to have dependency on 3rd party libraries or wildfly. > > The vfs url should be resolved to a plain file or jar URL that actually exists on file system before passing the URL to a JPA provider when creating an EntityManagerFactory. > > > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13714) JPA PersistenceUnitInfo.persistenceUnitRootUrl vfs URL should be resolved

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13714?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13714: --------------------------------------- Component/s: JPA / Hibernate Assignee: Scott Marlow (was: Brian Stansberry) > JPA PersistenceUnitInfo.persistenceUnitRootUrl vfs URL should be resolved > ------------------------------------------------------------------------- > > Key: WFLY-13714 > URL: https://issues.redhat.com/browse/WFLY-13714 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 20.0.1.Final > Reporter: Java Java > Assignee: Scott Marlow > Priority: Major > > Wildlfy passes a PersistenceUnitInfo object to JPA provider using vfs URL as persistenceUnitRootUrl, e.g., > vfs:/C:/wildfly-20.0.1.Final/bin/content/foo.ear/myejb.jar/ > A JPA provider can not resolve this URL without using a third-party library and thus force > the JPA provider to have dependency on 3rd party libraries or wildfly. > > The vfs url should be resolved to a plain file or jar URL that actually exists on file system before passing the URL to a JPA provider when creating an EntityManagerFactory. > > > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13729) Make optional the javax.xml.rpc.api module dependency added to deployments by EjbDependencyDeploymentUnitProcessor

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13729?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13729: ------------------------------------ Summary: Make optional the javax.xml.rpc.api module dependency added to deployments by EjbDependencyDeploymentUnitProcessor (was: Make optional the javax.sml.rpc.api module dependency added to deployments by EjbDependencyDeploymentUnitProcessor ) > Make optional the javax.xml.rpc.api module dependency added to deployments by EjbDependencyDeploymentUnitProcessor > ------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13729 > URL: https://issues.redhat.com/browse/WFLY-13729 > Project: WildFly > Issue Type: Task > Components: EJB > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Labels: EE9 > Fix For: 21.0.0.Beta1 > > > EjbDependencyDeploymentUnitProcessor add a module dep on the javax.xml.rpc.api module to all deployments. This really just supports a single method in the SessionContext interface, a method that isn't really usable anyway as we don't support JAX RPC. The method is gone in EE 9 and we won't even provide the API jar in our EE 9 dist, so make this module dep optional so if this code runs in an EE 9 context it just works. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13742) Provide a docs/examples/configs/standalone-embedded-jms.xml in the EE9 dist

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13742?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13742: ------------------------------------ Labels: EE9 (was: ) > Provide a docs/examples/configs/standalone-embedded-jms.xml in the EE9 dist > --------------------------------------------------------------------------- > > Key: WFLY-13742 > URL: https://issues.redhat.com/browse/WFLY-13742 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Labels: EE9 > > My current thinking is, in the WF EE9 dist, the default configs will not include an embedded broker as we want to steer people toward remote brokers. But an embedded broker is still valid, so we can provide an example config that is basically standalone-full.xml with the remote broker settings changed to embedded. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13741) The standalone-load-balancer configurations should depend on legacy-management

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13741?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13741: ----------------------------------------- Just an FYI re both this layer and the feature-group. The code for it is in https://github.com/wildfly/wildfly-core/tree/master/core-feature-pack/gal... instead of https://github.com/wildfly/wildfly-core/tree/master/core-feature-pack/gal... because the latter is meant to be "sharable" (i.e. sucked in as source using GAL-319 whereby the consuming f-p has no dependency on org.wildfly.core:wildfly-core-galleon-pack itself) while the former is not. The layer and feature group are not in the sharable one because I want to avoid them leaking out into 'non-legacy' feature packs, i.e. the EE 9 one I'm doing. This doesn't affect this particular JIRA. The wildfly-ee-galleon-pack uses the legacy feature-group; now it will use the legacy layer. Either way it is using legacy stuff, which is ok as it itself is 'legacy'. > The standalone-load-balancer configurations should depend on legacy-management > ------------------------------------------------------------------------------ > > Key: WFLY-13741 > URL: https://issues.redhat.com/browse/WFLY-13741 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 21.0.0.Beta1 > > > The standalone-load-balancer.xml/config.xml which can be found in ee-feature-pack and servlet-feature-pack should depend on the legacy-management layer instead of depending on management and adding security to it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13723) Many Jakarta EE 8 TCK tests are failing due to "Unknown service name jboss.ejb"

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13723?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13723: ----------------------------------------- Excellent! > Many Jakarta EE 8 TCK tests are failing due to "Unknown service name jboss.ejb" > ------------------------------------------------------------------------------- > > Key: WFLY-13723 > URL: https://issues.redhat.com/browse/WFLY-13723 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Scott Marlow > Assignee: Cheng Fang > Priority: Major > Fix For: 21.0.0.Beta1 > > > I am now able to publicly discuss Jakarta EE 8 TCK failures, so am creating this issue to request a fix for the below "Unknown service name jboss.ejb" error. > {code} > \u001b[0m\u001b[0m22:18:24,546 INFO [org.jboss.as.server] (Thread-41) WFLYSRV0010: Deployed "jta_ejb_vehicle.ear" (runtime-name : "jta_ejb_vehicle.ear") > \u001b[0m\u001b[0m22:18:24,580 INFO [stdout] (Thread-186) ************************************************************ > \u001b[0m\u001b[0m22:18:24,580 INFO [stdout] (Thread-186) * props file set to "/tmp/hudson-cts-props.txt" > \u001b[0m\u001b[0m22:18:24,580 INFO [stdout] (Thread-186) ************************************************************ > \u001b[0m\u001b[0m22:18:24,628 INFO [org.wildfly.naming] (Thread-186) WildFly Naming version 1.0.13.Final > \u001b[0m\u001b[0m22:18:24,687 INFO [org.jboss.ejb.client] (Thread-186) JBoss EJB Client version 4.0.33.Final > \u001b[0m\u001b[0m22:18:25,082 INFO [stdout] (Thread-186) 07-30-2020 22:18:25: ERROR: Test failed > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) 07-30-2020 22:18:25: ERROR: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "jta_ejb_vehicle/jta_ejb_vehicle_ejb/com_sun_ts_tests_common_vehicle_ejb_EJBVehicle", view is interface com.sun.ts.tests.common.vehicle.ejb.EJBVehicleHome, affinity is None > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:622) > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553) > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:57) > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624) > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553) > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:148) > \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:137) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:87) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:212) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:995) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:191) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at com.sun.proxy.$Proxy19.create(Unknown Source) > \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicleRunner.run(EJBVehicleRunner.java:66) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.EETest.run(EETest.java:285) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at java.lang.reflect.Method.invoke(Method.java:498) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:99) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at java.lang.Thread.run(Thread.java:748) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:440) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:49) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > \u001b[0m\u001b[0m22:18:25,087 INFO [stdout] (Thread-186) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > \u001b[0m\u001b[0m22:18:25,087 INFO [stdout] (Thread-186) at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > \u001b[0m\u001b[0m22:18:25,087 INFO [stdout] (Thread-186) > \u001b[0m\u001b[31m22:18:26,087 ERROR [stderr] (Thread-186) STATUS:Failed.Test run in ejb vehicle failed > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13742) Provide a docs/examples/configs/standalone-embedded-jms.xml in the EE9 dist

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13742: --------------------------------------- Summary: Provide a docs/examples/configs/standalone-embedded-jms.xml in the EE9 dist Key: WFLY-13742 URL: https://issues.redhat.com/browse/WFLY-13742 Project: WildFly Issue Type: Enhancement Components: JMS Reporter: Brian Stansberry Assignee: Brian Stansberry My current thinking is, in the WF EE9 dist, the default configs will not include an embedded broker as we want to steer people toward remote brokers. But an embedded broker is still valid, so we can provide an example config that is basically standalone-full.xml with the remote broker settings changed to embedded. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11316) Remove unused dependencies from org.jberet.jberet-core

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-11316?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty updated WFLY-11316: --------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13458 > Remove unused dependencies from org.jberet.jberet-core > ------------------------------------------------------ > > Key: WFLY-11316 > URL: https://issues.redhat.com/browse/WFLY-11316 > Project: WildFly > Issue Type: Bug > Components: Batch > Reporter: Yeray Borges Santana > Assignee: Ranabir Chakraborty > Priority: Optional > > Analysis of org.jberet.jberet-core shows: > * org.jboss.jts is unused > * jberet only uses javax.enterprise.api, javax.inject.api, javax.annotation.api and javax.batch.api from javaee.api, maybe we could reduce the final size removing javaee.api and add only the required modules. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-13734. ------------------------------------- Fix Version/s: No Release Resolution: Explained > JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-13734 > URL: https://issues.redhat.com/browse/WFLY-13734 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > Fix For: No Release > > > This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13734: ----------------------------------------- [~yersan]. FYI re this discussion. This makes me wonder whether the jpa / jpa-distributed layers need to have the bean-validation layer as an optional dependency. The primary 'server' layers that incorporate JPA ('cloud-server' and 'jaxrs-server') already include the bean-validation layer, so for anyone using those adding b-v as a dep to jpa would have no practical impact. But for someone adding jpa to some other base, a change may mean they now get b-v when they didn't want it. They can exclude it though. I'm fine with what [~smarlow] thinks is best here. But if we are going to change anything it must happen with WF 21; after that this layer should be locked down. > JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-13734 > URL: https://issues.redhat.com/browse/WFLY-13734 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > > This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020