May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2982) refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2982?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-2982: ------------------------------------ Some of the competing concerns for this task: * The DataSource may be needed before any application classloaders have been used. The DataSource is currently used when Hibernate is called to create the entity manager factory. For the two phase bootstrap approach, Hibernate accesses the DataSource during the first bootstrap phase. Currently, we do not have a way to prevent application classloaders from being used before the WildFly Install deployment phase. Persistence providers are allowed to rewrite entity classes as per the JPA specification (which has been part of EE since EE 5). * The CDI bean manager passed to the persistence provider (for entity listeners) cannot be used until the WildFly Install deployment phase. * Entity class rewriting needs to be supported as per the JPA spec (see the above). > refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service > ------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2982 > URL: https://issues.jboss.org/browse/WFLY-2982 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: 8.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 9.0.0.CR1 > > > Related feedback from https://github.com/wildfly/wildfly/pull/4722: > {quote} > This is asymetrical, so if this service , and phase one are stopped, and then phase 1 is started again, phase 2 will appear started. The side effects seem minor though > {quote} > {quote} > We have a long term goal to somehow verify every service can be stopped and started with the expected effect. Right now many of our services are not restartable which makes potential new features like partial deployment standby hard to achieve. So Im just offering pointers whenever I see lifecycle symmetry issues. > {quote} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3419: -------------------------------------- Looks like one of your files is missing a beans.xml. Every jar that you want to have picked up needs to have beans.xml. > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > Attachments: jboss-module-test.src.zip, module.multiplejars.zip, module.ok.zip, servlet-cdi-test-jar.src.zip, servlet-cdi-test3.src.zip, servlet-cdi-test3.war > > > CDI does not scan module with multiple jars. Only first jar is scanned. > Workaround is to package everything in single jar file. > To reproduce: > {CODE} > #download attached files > #download and unzip wildfly > cd wildfly-9.0.0.Alpha1-SNAPSHOT #or other version > 8.0.0 > unzip ../module.multiplejars.zip > cp ../servlet-cdi-test3.war standalone/deployments/ > ./bin/standalone.sh > # observe deployment fails > # stop server > unzip ../module.ok.zip > ./bin/standalone.sh > # observe deployment succeeds > {CODE} > The same scenario succeeds in both cases on EAP 6.2.x. > module.ok.zip was created from module.multiplejars.zip by merging jar files into single one -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3423) EJB timer create table code fails on postgresql

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-3423: ------------------------------------ Summary: EJB timer create table code fails on postgresql Key: WFLY-3423 URL: https://issues.jboss.org/browse/WFLY-3423 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3329) EJBs with same Java class name not intercepted by CDI interceptors

by Maxim Frolov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3329?page=com.atlassian.jira.plugin.... ] Maxim Frolov commented on WFLY-3329: ------------------------------------ Indeed "overriding", using {{@Stateless(name="...")}} works fine on WildFly and JBoss AS7! I retested it. Obviously I made some mistake during my first tests. As to _no-interface view_, thank you for good hints with correct spec references! Actually the problem occured in production where both beans were {{@Remote(...)}} {{@Stateless}} and one of them was additionally {{@WebService}}. To provide an example I tried to reduce everything to a minimum and clearly removed too much. > EJBs with same Java class name not intercepted by CDI interceptors > ------------------------------------------------------------------ > > Key: WFLY-3329 > URL: https://issues.jboss.org/browse/WFLY-3329 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 8.0.0.Final > Reporter: Maxim Frolov > Assignee: Martin Kouba > Labels: ejb, ejb3.1, interceptor > > h3. Given > Two or more EJBs with the same Java class name but from different Java deployments. > h3. Problem > Interceptor intercepts method calls to only one of the EJBs. > An EJB to be intercepted seems to be chosen randomly after each redeployment. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3422) VFSResourceLoader is creating too many code sources

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3422?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3422: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103298 > VFSResourceLoader is creating too many code sources > --------------------------------------------------- > > Key: WFLY-3422 > URL: https://issues.jboss.org/browse/WFLY-3422 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading, VFS > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > A new code source is being created for every class. We should be mapping code signer lists to cached code sources instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2912) Generic JMS adapter does not deploy correctly in domain mode.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2912?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2912: ----------------------------------------------- Tom Ross <tom.ross(a)redhat.com> changed the Status of [bug 1103238|https://bugzilla.redhat.com/show_bug.cgi?id=1103238] from NEW to POST > Generic JMS adapter does not deploy correctly in domain mode. > ------------------------------------------------------------- > > Key: WFLY-2912 > URL: https://issues.jboss.org/browse/WFLY-2912 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Final > Reporter: Tom Ross > Assignee: Stefano Maestri > Fix For: 8.1.0.CR1 > > > When trying to use generic resource adapter with third part JMS providers like TIBCO it is necessary to use generic RA provided in JBoss EAP 6.2. Unfortunately it would appear that when trying to use in domain mode the RA does not get deployed full, though it works perfectly in standalone mode. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3422) VFSResourceLoader is creating too many code sources

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3422?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-3422: ------------------------------ Component/s: Class Loading > VFSResourceLoader is creating too many code sources > --------------------------------------------------- > > Key: WFLY-3422 > URL: https://issues.jboss.org/browse/WFLY-3422 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > A new code source is being created for every class. We should be mapping code signer lists to cached code sources instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3422) VFSResourceLoader is creating too many code sources

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3422?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-3422: ------------------------------ Component/s: VFS > VFSResourceLoader is creating too many code sources > --------------------------------------------------- > > Key: WFLY-3422 > URL: https://issues.jboss.org/browse/WFLY-3422 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading, VFS > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > A new code source is being created for every class. We should be mapping code signer lists to cached code sources instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3422) VFSResourceLoader is creating too many code sources

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3422?page=com.atlassian.jira.plugin.... ] David Lloyd moved MODULES-193 to WFLY-3422: ------------------------------------------- Project: WildFly (was: JBoss Modules) Key: WFLY-3422 (was: MODULES-193) Security: Public Fix Version/s: 8.1.0.Final 9.0.0.Alpha1 (was: 1.2.5.Final) (was: 1.1.6.GA) (was: 1.4.0.Beta1) (was: 1.3.4.Final) > VFSResourceLoader is creating too many code sources > --------------------------------------------------- > > Key: WFLY-3422 > URL: https://issues.jboss.org/browse/WFLY-3422 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > A new code source is being created for every class. We should be mapping code signer lists to cached code sources instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3421) Rehashing on view change can result in premature session/ejb expiration

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-3421: ---------------------------------- Summary: Rehashing on view change can result in premature session/ejb expiration Key: WFLY-3421 URL: https://issues.jboss.org/browse/WFLY-3421 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.1.0.CR2 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Critical Fix For: 8.1.0.Final, 9.0.0.Alpha1 Session/ejb expiration is scheduled only the the owning node of a given session/ejb. When a node leaves each node that assumes ownership of the sessions/ejbs that were previously owned by the leaving node schedules expiration of those sessions. However, view change can also lead to ownership changes for any session/ejb. We are currently handling this properly. If a session/ejb changes ownership, the expiration scheduling is never cancelled, and that session/ejb will expire prematurely, unless the node reacquires ownership. When using sticky sessions, this issue is not apparent, since subsequent requests will direct to the previous owner, who will cancel expiration on the old owner and reschedule expiration on the new owner properly. However, this will be a problem for web sessions if sticky sessions is disabled - and for @Stateful EJBs, if the ejb client receives updated affinity information prior to subsequent requests. There are 2 ways to address this: # When a request arrives for an existing session/ejb, we immediately cancel any scheduled expiration/eviction. This is currently a unicast, which typically results in a local call - but can go remote if the ownership has changed. Making this a cluster-wide broadcast would fix the issue. # We can allow the scheduler to expose the set of keys that are currently schedule, and, on topology change, cancel those sessions/ejbs for which the current node is no longer the owner - and reschedule on the new owner. Option 1 adds an additional cluster-wide RPC per request. Option 2 adds N*(N-1) unicast RPCs per view change, where N is the cluster size (i.e. each node sends 1 rpc to every other node containing the set of session/ejb IDs to schedule for expiration), Option 2 is the least invasive solution - so we'll go with that. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 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 May 2014