[JBoss JIRA] Created: (JBBUILD-378) Research options for testing dependency version ranges
by Paul Gier (JIRA)
Research options for testing dependency version ranges
------------------------------------------------------
Key: JBBUILD-378
URL: http://jira.jboss.com/jira/browse/JBBUILD-378
Project: JBoss Build System
Issue Type: Task
Components: Maven
Reporter: Paul Gier
Fix For: MavenBuild 2007
It would be helpful to be able to automatically run a maven build with each of the valid combinations of dependency versions. For example, if a dependency includes a version range of 1.1, 1.2, and 1.3. We would want to build and test the project using each of these versions to make sure that they all work correctly.
Sherriff on the maven forum has worked on something like this for continuum. When we move our automated builds to hudson, maybe we could create something similar to this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (JGRP-628) Discovery: add cluster name to discovery request to be able to discard responses from different clusters
by Bela Ban (JIRA)
Discovery: add cluster name to discovery request to be able to discard responses from different clusters
--------------------------------------------------------------------------------------------------------
Key: JGRP-628
URL: http://jira.jboss.com/jira/browse/JGRP-628
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6.1, 2.7
When we have 2 groups ONE and TWO:
ONE: 228.8.8.8:7500 and
TWO: 228.1.2.3:7500
In some cases, they will receive each other's traffic (http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic).
Assume ONE has members {A,B,C} and TWO has no members yet. When D (in cluster TWO) starts up and sends out a discovery request, it might also receive discovery responses from ONE (A,B,C). D might now identify A as coordinator and send a JOIN-REQ to A. However, A will discard that request as the group name of D's request is TWO rather than ONE !
Result: D's JOIN-REQ will hang !
Note that the transport (TP) does drop messages from different clusters, but this happens only after the new member has joined the group, so discovery requests/responses from different groups are *not* discarded.
Tasks:
- Verify that the transport-name matching algorithm in TP is correct
- Confirm that - on initial discovery - discovery requests and responses are not matched
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (JBCACHE-1251) Re-adding invalidated node fails with invalidation + pessimistic locking
by Brian Stansberry (JIRA)
Re-adding invalidated node fails with invalidation + pessimistic locking
------------------------------------------------------------------------
Key: JBCACHE-1251
URL: http://jira.jboss.com/jira/browse/JBCACHE-1251
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.1.0.CR2
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Scenario is one where a parent node represents a structural node, and then child nodes represent different data elements.
Such data structures are set up on both caches, and then the parent node is removed (globally, via INVALIDATION) and re-added (locally) on one cache. This represents an attempt to clear the region -- removing a node and re-adding is one of the only ways to do this.
On the second cache, the fact that the structural node is missing is detected, and an attempt is made to re-add it locally. This fails with pessimistic locking:
18:50:34,821 TRACE PessimisticLockInterceptor:71 - PessimisticLockInterceptor invoked for method MethodName: _put; MethodIdInteger: 1; Args: (null, /test/com/foo/test/ENTITY, null, true)
18:50:34,821 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main]
18:50:34,822 TRACE PessimisticLockInterceptor:334 - Directly got child node null
18:50:34,822 TRACE IdentityLock:264 - acquiring RL: fqn=/, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,823 TRACE IdentityLock:270 - acquired RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,823 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,824 TRACE IdentityLock:264 - acquiring RL: fqn=/test, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,824 TRACE IdentityLock:270 - acquired RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,825 TRACE PessimisticLockInterceptor:334 - Directly got child node com
18:50:34,825 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,826 TRACE IdentityLock:270 - acquired RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,826 TRACE PessimisticLockInterceptor:334 - Directly got child node foo
18:50:34,827 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,827 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,828 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,828 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,829 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,829 TRACE PessimisticLockInterceptor:334 - Directly got child node ENTITY
18:50:34,830 TRACE IdentityLock:164 - acquiring WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=<unlocked>
18:50:34,830 TRACE IdentityLock:170 - acquired WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main]
18:50:34,831 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main]
18:50:34,831 TRACE PessimisticLockInterceptor:334 - Directly got child node null
18:50:34,832 TRACE IdentityLock:264 - acquiring RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,832 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /
18:50:34,833 TRACE IdentityLock:270 - acquired RL: fqn=/, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,833 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,834 TRACE IdentityLock:264 - acquiring RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,834 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test
18:50:34,835 TRACE IdentityLock:270 - acquired RL: fqn=/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,835 TRACE PessimisticLockInterceptor:334 - Directly got child node com
18:50:34,836 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,836 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com
18:50:34,837 TRACE IdentityLock:270 - acquired RL: fqn=/test/com, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,837 TRACE PessimisticLockInterceptor:334 - Directly got child node foo
18:50:34,838 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,838 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com/foo
18:50:34,839 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,839 TRACE PessimisticLockInterceptor:334 - Directly got child node test
18:50:34,840 TRACE IdentityLock:264 - acquiring RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,840 TRACE IdentityLock:307 - acquireReadLock(): caller Thread[main,5,main] already owns lock for /test/com/foo/test
18:50:34,841 TRACE IdentityLock:270 - acquired RL: fqn=/test/com/foo/test, caller=Thread[main,5,main], lock=read owners=[Thread[main,5,main]]
18:50:34,841 TRACE PessimisticLockInterceptor:334 - Directly got child node ENTITY
18:50:34,842 TRACE IdentityLock:164 - acquiring WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main]
18:50:34,842 TRACE IdentityLock:187 - acquireWriteLock(): caller already owns lock for /test/com/foo/test/ENTITY (caller=Thread[main,5,main])
18:50:34,843 TRACE IdentityLock:170 - acquired WL: fqn=/test/com/foo/test/ENTITY, caller=Thread[main,5,main], lock=write owner=Thread[main,5,main]
18:50:34,843 TRACE PessimisticLockInterceptor:292 - Attempting to lock node /test/com/foo/test/ENTITY for owner Thread[main,5,main]
18:50:34,844 TRACE PessimisticLockInterceptor:334 - Directly got child node null
..... continues looping through the hierarchy until the timeout kicks in and a TimeoutException is thrown
The above described scenario describes what happens with the "region clearing" operations in the Hibernate/JBC integration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (EJBTHREE-1154) 2.1 Home create() implementation returns wrong type
by Andrew Lee Rubinger (JIRA)
2.1 Home create() implementation returns wrong type
---------------------------------------------------
Key: EJBTHREE-1154
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1154
Project: EJB 3.0
Issue Type: Bug
Reporter: Andrew Lee Rubinger
Assigned To: Andrew Lee Rubinger
Priority: Critical
Fix For: AS 5.0.0.Beta3
EJB3 Mirror issue of JBAS-5036.
Local home (and presumably remote, too) implementation for EJB 3 sessions creates an object that is an instance of the local *business* interface of the EJB 3 session, and returns that. This is contrary to EJB 3 specification, which says that local home create methods must return an instance of the local interface of the EJB 3 session (as in: not local business interface).
The type of the local interface is apparently deduced from the return type of the create method in the local home interface (there is no annotation for it).
For beans that follow the specification, this causes a class cast exception when create() is called: the local home interface is specified to return an instance of local interface, but the implementation JBoss supplies creates a instance of local business interface (I presume so, because changing local home to return that works), and then we end up with class cast exception.
There is no workaround other than going against specification in code: define local home interface to return instance of local business interface.
This simple session, which as far as I can see is exactly according to EJB 3 spec, illustrates the problem, and does not work on JBoss 4.2.1.GA:
--
@javax.ejb.Stateless(name="Stateless")
@javax.ejb.LocalHome(StatelessHome.class)
@javax.ejb.Local({StatelessLocal.class})
public class StatelessBean implements StatelessLocal { public void ejbCreate() {} }
--
public interface StatelessLocal {}
--
public interface StatelessHome extends javax.ejb.EJBLocalHome
{ public StatelessLocal21 create() throws javax.ejb.CreateException;}
--
public interface StatelessLocal21 extends javax.ejb.EJBLocalObject, StatelessLocal {}
--
When home is looked up, and create is called, the result is:
java.lang.ClassCastException: $Proxy271 cannot be cast to StatelessLocal21
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (EJBTHREE-1147) private ejbCreate is used as an Init method
by Carlo de Wolf (JIRA)
private ejbCreate is used as an Init method
-------------------------------------------
Key: EJBTHREE-1147
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1147
Project: EJB 3.0
Issue Type: Bug
Reporter: Carlo de Wolf
Assigned To: Carlo de Wolf
Fix For: AS 5.0.0.Beta3
10:32:46,882 ERROR [STDERR] java.lang.RuntimeException: java.lang.IllegalAccessException: Class org.jboss.ejb3.stateful.StatefulContainer can not access a member of class com.sun.ts.tests.ejb30.bb.session.stateful.callback.method.annotated.SessionBeanCallbackBean with modifiers "private"
10:32:46,882 ERROR [STDERR] at org.jboss.ejb3.stateful.StatefulContainer.invokeInit(StatefulContainer.java:501)
10:32:46,882 ERROR [STDERR] at org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:121)
10:32:46,882 ERROR [STDERR] at org.jboss.ejb3.InfinitePool.get(InfinitePool.java:56)
10:32:46,883 ERROR [STDERR] at org.jboss.ejb3.pool.ThreadlocalPool.create(ThreadlocalPool.java:58)
10:32:46,883 ERROR [STDERR] at org.jboss.ejb3.pool.ThreadlocalPool.get(ThreadlocalPool.java:113)
10:32:46,883 ERROR [STDERR] at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:351)
10:32:46,883 ERROR [STDERR] at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:362)
10:32:46,883 ERROR [STDERR] at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
10:32:46,883 ERROR [STDERR] at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
10:32:46,884 ERROR [STDERR] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:771)
10:32:46,884 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
10:32:46,884 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
10:32:46,884 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
10:32:46,884 ERROR [STDERR] Caused by: java.lang.IllegalAccessException: Class org.jboss.ejb3.stateful.StatefulContainer can not access a member of class com.sun.ts.tests.ejb30.bb.session.stateful.callback.method.annotated.SessionBeanCallbackBean with modifiers "private"
10:32:46,884 ERROR [STDERR] at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
10:32:46,885 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:578)
10:32:46,885 ERROR [STDERR] at org.jboss.ejb3.stateful.StatefulContainer.invokeInit(StatefulContainer.java:494)
10:32:46,885 ERROR [STDERR] ... 12 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years