September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBNAME-63) Fix type check in Protocol#RENAME

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/JBNAME-63?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated JBNAME-63: ------------------------------------- Git Pull Request: https://github.com/jbossas/jboss-remote-naming/pull/30 > Fix type check in Protocol#RENAME > --------------------------------- > > Key: JBNAME-63 > URL: https://issues.jboss.org/browse/JBNAME-63 > Project: JBoss Naming > Issue Type: Bug > Components: naming > Reporter: Philippe Marschall > Assignee: Eduardo Martins > > {{Protocol#RENAME}} checks the type of the same array element twice before casting instead of checking the types of all array elements before casing. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBNAME-63) Fix type check in Protocol#RENAME

by Philippe Marschall (JIRA)

Philippe Marschall created JBNAME-63: ---------------------------------------- Summary: Fix type check in Protocol#RENAME Key: JBNAME-63 URL: https://issues.jboss.org/browse/JBNAME-63 Project: JBoss Naming Issue Type: Bug Components: naming Reporter: Philippe Marschall Assignee: Eduardo Martins {{Protocol#RENAME}} checks the type of the same array element twice before casting instead of checking the types of all array elements before casing. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7086) By spec EJB business methods should not final but the deployment did not fail under any circumstances

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7086: -------------------------------------- Summary: By spec EJB business methods should not final but the deployment did not fail under any circumstances Key: WFLY-7086 URL: https://issues.jboss.org/browse/WFLY-7086 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink The ejb 3.2 core specification state in chapter 4.9.6 that business methods should not be declared as final or static. But a Bean with a business method declared in the local or remote interface can be correct deployed and is accesible under some circumstances. To ensure that the Bean is according to the spec and avoid runtime or injection issues the methods should be checked and a VerifyError should be thrown at deployment time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7084) Support Artemis JDBC store

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7084?page=com.atlassian.jira.plugin.... ] Jeff Mesnil closed WFLY-7084. ----------------------------- Resolution: Duplicate Issue > Support Artemis JDBC store > -------------------------- > > Key: WFLY-7084 > URL: https://issues.jboss.org/browse/WFLY-7084 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7085) By spec EJB business methods should not final but the deployment did not fail under any circumstances

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7085: -------------------------------------- Summary: By spec EJB business methods should not final but the deployment did not fail under any circumstances Key: WFLY-7085 URL: https://issues.jboss.org/browse/WFLY-7085 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink The ejb 3.2 core specification state in chapter 4.9.6 that business methods should not be declared as final or static. But a Bean with a business method declared in the local or remote interface can be correct deployed and is accesible under some circumstances. To ensure that the Bean is according to the spec and avoid runtime or injection issues the methods should be checked and a VerifyError should be thrown at deployment time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7084) Support Artemis JDBC store

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-7084: --------------------------------- Summary: Support Artemis JDBC store Key: WFLY-7084 URL: https://issues.jboss.org/browse/WFLY-7084 Project: WildFly Issue Type: Feature Request Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6899) Upgrade RESTEasy to 3.1.0.Beta2

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-6899?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-6899: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9181 (was: https://github.com/wildfly/wildfly/pull/9086) > Upgrade RESTEasy to 3.1.0.Beta2 > ------------------------------- > > Key: WFLY-6899 > URL: https://issues.jboss.org/browse/WFLY-6899 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6899) Upgrade RESTEasy to 3.1.0.Beta2

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-6899?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-6899: ---------------------------------- Summary: Upgrade RESTEasy to 3.1.0.Beta2 (was: Upgrade RESTEasy to 3.1.0.Beta1) > Upgrade RESTEasy to 3.1.0.Beta2 > ------------------------------- > > Key: WFLY-6899 > URL: https://issues.jboss.org/browse/WFLY-6899 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ] Dan Berindei commented on WFCORE-1127: -------------------------------------- Thanks [~pferraro], I looked at {{UnnamedRegistryImpl.registerBinding()}} to check that it still throws the {{IllegalStateException}}, but I didn't realize {{ManagedSocketFactory}} and {{ManagedSocketFactoryTest}} had changed instead. I guess I have some rebasing to do :) > SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets > ---------------------------------------------------------------------------------- > > Key: WFCORE-1127 > URL: https://issues.jboss.org/browse/WFCORE-1127 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.2.Final > > > A failure like this isn't necessary: > {code} > 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException > at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501) > at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73) > at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148) > at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577) > at org.jgroups.protocols.UDP.destroySockets(UDP.java:429) > at org.jgroups.protocols.UDP.start(UDP.java:274) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > ... 5 more > {code} > If there's no socket address, it should just move on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ The naughty/bad thing about fixing the mentioned bug (that we will track via a new WFLY jira soon), is that applications that associate an UNSYNCHRONIZED extended persistence context with the JTA transaction which could start seeing (IllegalStateException) failures after the fix is applied due to the testForMixedSynchronizationTypes. We might need a workaround for applications to get the current behaviour (property to treat extended persistence context as SYNCHRONIZED). > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 September 2016