[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)
10 years, 6 months
[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)
10 years, 6 months
[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)
10 years, 6 months
[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3345:
-------------------------------
Priority: Blocker (was: Major)
> Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows
> ----------------------------------------------------------------------
>
> Key: WFLY-3345
> URL: https://issues.jboss.org/browse/WFLY-3345
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 8.1.0.Final, 9.0.0.Alpha1
>
>
> In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error:
> {code}
> [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months