May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ] Paul Ferraro edited comment on WFLY-10339 at 5/22/18 5:01 PM: -------------------------------------------------------------- [~eduda] I do not intend to require a migration operation. This change should be entirely achievable using normal resource/operation transformations and operation translations. [~jmesnil] I'll plan to address this for WF14. {quote}Could I suggest that we keep the <broadcast|discovery>-group for the JGroups implementation (which is the default we use)?{quote} I would actually recommend against that. Using new path names for both resources makes it easy to distinguish between a legacy CLI command and one intended for the current version of the model - especially since the resource in question heavily relies on optional attributes. This way we can replace the add/remove operation handling with an implementation that redirects/translates the operation to the correct path address. WDYT? was (Author: pferraro): [~eduda] I do not intend to require a migration operation. This change should be entirely achievable using normal resource/operation transformations and operation translations. [~jmesnil] I'll plan to address this for WF14. {quote}Could I suggest that we keep the <broadcast|discovery>-group for the JGroups implementation (which is the default we use)?{quote} I would actually recommend against that. Use new path names for both resources makes it easy to distinguish between a legacy CLI command and one intended for the current version of the model - especially since the resource in question heavily relies on non-required attributes. This way we can replace the add/remove operation handling with an implementation that redirects/translates the operation to the correct path address. WDYT? > Broadcast/discovery-group resources have ambiguous requirement specs > -------------------------------------------------------------------- > > Key: WFLY-10339 > URL: https://issues.jboss.org/browse/WFLY-10339 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 12.0.0.Final > Reporter: Paul Ferraro > Assignee: Jeff Mesnil > > Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined. > I suggest splitting these resources into 2: > {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code} > {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code} > which requires clustering capabilities > and > {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code} > {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code} > which requires a socket-binding capability. > This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10428) Upgrade to WildFly Galleon plugins 1.0.0.CR7 and fork embedded in the build

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFLY-10428: ---------------------------------------- Summary: Upgrade to WildFly Galleon plugins 1.0.0.CR7 and fork embedded in the build Key: WFLY-10428 URL: https://issues.jboss.org/browse/WFLY-10428 Project: WildFly Issue Type: Component Upgrade Components: Build System Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky 1.0.0.CR7 significantly reduces the classpath prepared by the plugins to launch the embedded server and also adds an option to execute the embedded in a separate process to avoid FD leaks in jboss-modules. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3872) Upgrade to WildFly Galleon plugins 1.0.0.CR7 and fork embedded in the build

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFCORE-3872: ----------------------------------------- Summary: Upgrade to WildFly Galleon plugins 1.0.0.CR7 and fork embedded in the build Key: WFCORE-3872 URL: https://issues.jboss.org/browse/WFCORE-3872 Project: WildFly Core Issue Type: Component Upgrade Components: Build System Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky 1.0.0.CR7 significantly reduces the classpath prepared by the plugins to launch the embedded server and also adds an option to execute the embedded in a separate process to avoid FD leaks in jboss-modules. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10427) override the Hibernate ORM 5.3 JtaPlatform on WildFly for all deployments

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10427?page=com.atlassian.jira.plugin... ] Scott Marlow updated WFLY-10427: -------------------------------- Summary: override the Hibernate ORM 5.3 JtaPlatform on WildFly for all deployments (was: specify the Hibernate ORM 5.3 JtaPlatform on WildFly for all deployments) > override the Hibernate ORM 5.3 JtaPlatform on WildFly for all deployments > ------------------------------------------------------------------------- > > Key: WFLY-10427 > URL: https://issues.jboss.org/browse/WFLY-10427 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 13.0.0.CR1 > > > When applications call javax.persistence.Persistence.generateSchema() from active JTA transactions, Hibernate defaults to using org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform, which uses com.arjuna.ats.jta.TransactionManager. We cannot use com.arjuna.ats.jta.TransactionManager directly anymore, instead we need to use the WildFly transaction client layer which wraps Arjuna TM. > [https://paste.fedoraproject.org/paste/9y4vn4E0yT77u471LNL-Xw] shows the call stack of where error is thrown by LocalTransaction.verifyAssociation: > {quote} > Caused by: java.lang.IllegalStateException: WFTXN0073: Unexpected provider transaction mismatch; expected TransactionImple < ac, BasicAction: 0:ffff0a0000b0:3831261e:5b045a43:11 status: ActionStatus.RUNNING >, got null[javatest.batch] 13:59:36,576 INFO [stdout] (Thread-130) > at org.wildfly.transaction.client.LocalTransaction.verifyAssociation(LocalTransaction.java:245) > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10425) With Hibernate ORM 5.3, protect against NPE in WildFlyCustomRegionFactoryInitiator for non-container-managed JPA deployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10425?page=com.atlassian.jira.plugin... ] Scott Marlow updated WFLY-10425: -------------------------------- Fix Version/s: 13.0.0.CR1 > With Hibernate ORM 5.3, protect against NPE in WildFlyCustomRegionFactoryInitiator for non-container-managed JPA deployment > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10425 > URL: https://issues.jboss.org/browse/WFLY-10425 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 13.0.0.Beta1 > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 13.0.0.CR1 > > > WildFlyCustomRegionFactoryInitiator needs to test for jpa_shared_code_mode being null. > {code} > at org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator.resolveRegionFactory(WildFlyCustomRegionFactoryInitiator.java:44) > at org.hibernate.cache.internal.RegionFactoryInitiator.initiateService(RegionFactoryInitiator.java:47) > at org.hibernate.cache.internal.RegionFactoryInitiator.initiateService(RegionFactoryInitiator.java:32) > at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:94) > at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:263) > at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:237) > at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214) > - locked <0x4fcc> (a org.hibernate.boot.registry.internal.StandardServiceRegistryImpl) > at org.hibernate.boot.internal.MetadataBuilderImpl$MetadataBuildingOptionsImpl.<init>(MetadataBuilderImpl.java:688) > at org.hibernate.boot.internal.MetadataBuilderImpl.<init>(MetadataBuilderImpl.java:123) > at org.hibernate.boot.MetadataSources.getMetadataBuilder(MetadataSources.java:136) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:213) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:169) > at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:76) > at org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilder(HibernatePersistenceProvider.java:179) > at org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:127) > at org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:69) > at org.hibernate.jpa.HibernatePersistenceProvider.generateSchema(HibernatePersistenceProvider.java:164) > at javax.persistence.Persistence.generateSchema(Persistence.java:114) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10320) Upgrade artemis from 1.5.x to 2.x.x

by Giovanni Lovato (JIRA)

[ https://issues.jboss.org/browse/WFLY-10320?page=com.atlassian.jira.plugin... ] Giovanni Lovato commented on WFLY-10320: ---------------------------------------- Artemis 2.6.0 has been finally released. Is there a PR to keep track of test against master? The original PR testing 2.4.0 was closed. > Upgrade artemis from 1.5.x to 2.x.x > ----------------------------------- > > Key: WFLY-10320 > URL: https://issues.jboss.org/browse/WFLY-10320 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Erich Duda > Assignee: Jeff Mesnil > Priority: Blocker > Labels: blocker-WF14, feature-branch-blocker > Fix For: 14.0.0.CR1 > > > As the summary of this Jira hints, this is an umbrella Jira for tracking all issues related to the upgrade of Artemis component from version 1.x to 2.x. > The issues were identified after running tests against following pull request - https://github.com/wildfly/wildfly/pull/10641 > This PR integrates Artemis 2.4.0 in WildFly master branch -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10427) specify the Hibernate ORM 5.3 JtaPlatform on WildFly for all deployments

by Scott Marlow (JIRA)

Scott Marlow created WFLY-10427: ----------------------------------- Summary: specify the Hibernate ORM 5.3 JtaPlatform on WildFly for all deployments Key: WFLY-10427 URL: https://issues.jboss.org/browse/WFLY-10427 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 13.0.0.CR1 When applications call javax.persistence.Persistence.generateSchema() from active JTA transactions, Hibernate defaults to using org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform, which uses com.arjuna.ats.jta.TransactionManager. We cannot use com.arjuna.ats.jta.TransactionManager directly anymore, instead we need to use the WildFly transaction client layer which wraps Arjuna TM. [https://paste.fedoraproject.org/paste/9y4vn4E0yT77u471LNL-Xw] shows the call stack of where error is thrown by LocalTransaction.verifyAssociation: {quote} Caused by: java.lang.IllegalStateException: WFTXN0073: Unexpected provider transaction mismatch; expected TransactionImple < ac, BasicAction: 0:ffff0a0000b0:3831261e:5b045a43:11 status: ActionStatus.RUNNING >, got null[javatest.batch] 13:59:36,576 INFO [stdout] (Thread-130) at org.wildfly.transaction.client.LocalTransaction.verifyAssociation(LocalTransaction.java:245) {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10426) Drop usage of JpaAttachments#TRANSACTION_MANAGER and #TSR

by David Lloyd (JIRA)

David Lloyd created WFLY-10426: ---------------------------------- Summary: Drop usage of JpaAttachments#TRANSACTION_MANAGER and #TSR Key: WFLY-10426 URL: https://issues.jboss.org/browse/WFLY-10426 Project: WildFly Issue Type: Task Components: JPA / Hibernate Reporter: David Lloyd Assignee: Scott Marlow Since the WildFly Transaction Client is responsible for coordinating between WildFly and the backing TM implementation, the attachments {{JpaAttachments#TRANSACTION_MANAGER}} and {{JpaAttachments#TRANSACTION_SYNCHRONIZATION_REGISTRY}} are no longer needed and all usages can be replaced with simple calls to {{ContextTransactionManager.getInstance()}} and {{ContextTransactionSynchronizationRegistry.getInstance()}}. Note that deployment dependencies (such as those established in {{PersistenceUnitParseProcessor#deploy}}) are presently still required (to ensure that the TM is available before starting the deployment), but the value can be discarded. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9710) Add Undertow buffer pools as a preferred alternative to the deprecated XNIO ones

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-9710?page=com.atlassian.jira.plugin.... ] Jan Stourac edited comment on WFLY-9710 at 5/22/18 2:18 PM: ------------------------------------------------------------ Attached PR has been merged already... so state of this jira should be updated probably? Hm,... well, name of this issue states 'preferred alternative'... which is not true with current state as support has been merged, although default variant is still the deprecated xnio buffers in configuration. So not sure what is proper state of this jira... I propose to update name of this jira so it is not confusing and move it forward. Default configuration shall be done in another PR and jira in the future. was (Author: jstourac): Attached PR has been merged already... so state of this jira should be updated probably? > Add Undertow buffer pools as a preferred alternative to the deprecated XNIO ones > -------------------------------------------------------------------------------- > > Key: WFLY-9710 > URL: https://issues.jboss.org/browse/WFLY-9710 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9710) Add Undertow buffer pools as a preferred alternative to the deprecated XNIO ones

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-9710?page=com.atlassian.jira.plugin.... ] Jan Stourac commented on WFLY-9710: ----------------------------------- Attached PR has been merged already... so state of this jira should be updated probably? > Add Undertow buffer pools as a preferred alternative to the deprecated XNIO ones > -------------------------------------------------------------------------------- > > Key: WFLY-9710 > URL: https://issues.jboss.org/browse/WFLY-9710 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 May 2018