October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JASSIST-37) CtField.getConstantValue() for just added fileds

by Vlad Skarzhevskyy (JIRA)

CtField.getConstantValue() for just added fileds ------------------------------------------------ Key: JASSIST-37 URL: http://jira.jboss.com/jira/browse/JASSIST-37 Project: Javassist Issue Type: Bug Environment: Java 5, javassist 3.4.ga Reporter: Vlad Skarzhevskyy Assigned To: Shigeru Chiba I'm creating tool to verify Java API compatibility I'm converting class files to XML and then XML to classes creating CtClass objects that have empty implementation. Then target is to compare new lib version to API described in XML. project site: http://pyx4me.com/snapshot/jour/signature.html This is what causing the problem: CtField field = new CtField(CtClass.longType, "test", klass); CtField.Initializer initializer = CtField.Initializer.constant(1); klass.addField(field, initializer); // Then later when Object value = fields.getConstantValue(); //value is always null and can't be used for comparison. when I call klass.writeFile(); The .class is created correctly and when decompiled I see that int filed is properly initialized . -- 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

18 years, 9 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1198) putForExternalRead not silent on remote node

by Brian Stansberry (JIRA)

putForExternalRead not silent on remote node -------------------------------------------- Key: JBCACHE-1198 URL: http://jira.jboss.com/jira/browse/JBCACHE-1198 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 2.1.0.BETA1 Reporter: Brian Stansberry Assigned To: Manik Surtani Seeing WARN logging like this when using PFER with a replicating cache: 22:16:37,931 WARN pessimistic-shared:2839 - replication failure with method_call MethodName: _putForExternalRead; MethodIdInteger: 45; Args: (null, /test/com/foo/test/ENTITY/KEY, item, VALUE1) exception org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/test/com/foo/test/ENTITY/KEY, caller=Thread[Multiplexer-2,5,MultiplexerThreads], lock=write owner=GlobalTransaction:<192.168.1.145:35562>:1 (activeReaders=0, activeWriter=Thread[Thread-7,5,main], waitingReaders=1, waitingWriters=0, waitingUpgrader=0) at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:528) at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:598) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:412) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:348) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:185) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:299) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3958) at org.jboss.cache.CacheImpl._replicate(CacheImpl.java:2826) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:77) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:744) at org.jgroups.JChannel.up(JChannel.java:1137) at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:999) at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1023) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Caused by: org.jboss.cache.lock.TimeoutException: write lock for /test/com/foo/test/ENTITY/KEY could not be acquired after 0 ms. Locks: Read lock owners: [] Write lock owner: GlobalTransaction:<192.168.1.145:35562>:1 (caller=Thread[Multiplexer-2,5,MultiplexerThreads], lock info: write owner=GlobalTransaction:<192.168.1.145:35562>:1 (activeReaders=0, activeWriter=Thread[Thread-7,5,main], waitingReaders=1, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:244) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167) at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497) ... 33 more Issue seems to be that the logic in CacheImpl.putForExternalRead that makes the call a no-op if the node exists and sets the failSilently option otherwise never gets executed on the remote node. Instead the call gets handled by _replicate which just passes the MethodCall into the interceptor chain without setting any options. -- 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

18 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1202) State transfer does not include optimistic node's DataVersion

by Brian Stansberry (JIRA)

State transfer does not include optimistic node's DataVersion ------------------------------------------------------------- Key: JBCACHE-1202 URL: http://jira.jboss.com/jira/browse/JBCACHE-1202 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP5, 1.4.1.SP4, 1.4.1.SP3, 1.4.1.SP2, 1.4.1.SP1, 2.0.0.GA, 1.4.1.GA, 1.4.0.SP1, 1.4.0.GA, 1.3.0.SP4, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0.GA, 2.1.0.BETA1 Reporter: Brian Stansberry Assigned To: Manik Surtani Here's the object that's transferred; doesn't include the DataVersion public class NodeData implements Externalizable { private Fqn<?> fqn = null; private Map<?, ?> attrs = null; } A hack solution that wouldn't affect wire format compatibility would be to store the version in the attrs map. -- 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

18 years, 9 months

2
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1114) JBoss Remoting fails under load

by Tim Fox (JIRA)

JBoss Remoting fails under load ------------------------------- Key: JBMESSAGING-1114 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1114 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.GA Reporter: Tim Fox Assigned To: Tim Fox Priority: Critical Fix For: 1.4.0.SP1 JBoss Remoting fails with various different errors when under extreme load. To replicate this, set up two clustered server nodes, using a MySQL database. These can both be on the same machine, using ServiceBindingManager. On a second machine run Ovidiu's messkit toolki, first to send some messages: mess -stat send -size 10240 50000 And then to receive them back using 50 concurrent consumers: mess -stat -sessions 50 receive all You will notice that JBoss Remoting fails with errors: I believe this is due to remoting incorrectly thinking a connection has failed and shutting down the connection. Perhaps due to the load, the ping does not get through in time to refresh the lease? I would like a remoting solution that *does not ping* from server to client - for us this is unnecessary. It also seems remoting is continually timing out and recreating connections - this could also be a source of error. How do we configure remoting so it does not do 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

18 years, 9 months

2
3
0 / 0

[JBoss JIRA] Closed: (JBAOP-265) Aspectize Java array

by Stale Pedersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-265?page=all ] Stale Pedersen closed JBAOP-265. -------------------------------- Resolution: Done committed and tested > Aspectize Java array > -------------------- > > Key: JBAOP-265 > URL: http://jira.jboss.com/jira/browse/JBAOP-265 > Project: JBoss AOP > Issue Type: Feature Request > Reporter: Ben Wang > Assigned To: Stale Pedersen > Fix For: 2.0.0.beta2 > > > For AOP, we haven't dealt with Java array. Is it possible to provide interception for array? This is required if we need to instrument Java Collection, for example, since they uses array list for internal fields. -- 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

18 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBBUILD-414) Mavenize security project

by Paul Gier (JIRA)

Mavenize security project ------------------------- Key: JBBUILD-414 URL: http://jira.jboss.com/jira/browse/JBBUILD-414 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - App Server The pom of the security project should be updated to fit project standards. -- 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

18 years, 9 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBREM-63) Get rid of the legacy configuration that embeds xml parsing

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-63?page=comments#action_12383509 ] Ron Sigal commented on JBREM-63: -------------------------------- org.jboss.remoting.transport.remoting.Connector can now be configured by way of an org.jboss.remoting.ServerConfiguration. ServerConfiguration holds four components: 1. transport (supplied by constructor) 2. invokerLocatorParameters: the is a map of all parameter names and values that will go into the org.jboss.remoting.InvokerLocator 3. serverParameters: this is a map of parameter names and values that will be used by the server but will not go into the InvokerLocator 4. invocationHandlers: this is a map of invocation handlers. The key is the subsystem, or comma separated list of subsystems. Note that parameter values in invokerLocatorParameters override values in serverParameters, if a parameter appears in both. ServerConfiguration may be used programmatically, but it is primarily intended to be constructed from a jboss-beans.xml file by a microcontainer and injected into a Connector. Unit test: org.jboss.test.remoting.transport.config.POJOConfigurationTestCase. Waiting for cruisecontrol results. > Get rid of the legacy configuration that embeds xml parsing > ----------------------------------------------------------- > > Key: JBREM-63 > URL: http://jira.jboss.com/jira/browse/JBREM-63 > Project: JBoss Remoting > Issue Type: Task > Affects Versions: 1.0.1 beta > Reporter: Scott M Stark > Assigned To: Ron Sigal > Priority: Blocker > Fix For: 2.4.0.Beta1 (Pinto) > > > I see that the org.jboss.remoting.transport.Connector is using the legacy mechanism of using an Element configuration as an attribute and doing the xml parsing within the code. This needs to be removed and replaced with JBossXB constructs. -- 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

18 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4889) jboss-vfs 2.0.0.beta5

by Kabir Khan (JIRA)

jboss-vfs 2.0.0.beta5 --------------------- Key: JBAS-4889 URL: http://jira.jboss.com/jira/browse/JBAS-4889 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: JBossAS-5.0.0.Beta3 -- 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

18 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-418) Figure out why iiop and jmx do not build from the aggregate app server build.

by Paul Gier (JIRA)

Figure out why iiop and jmx do not build from the aggregate app server build. ----------------------------------------------------------------------------- Key: JBBUILD-418 URL: http://jira.jboss.com/jira/browse/JBBUILD-418 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - App Server Currently the jmx and iiop modules build fine by themselves, but do not build correctly during the aggregate build with all the modules. -- 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

18 years, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (JBBUILD-423) Fix microcontainer poms and metatdata in maven repository

by Paul Gier (JIRA)

Fix microcontainer poms and metatdata in maven repository --------------------------------------------------------- Key: JBBUILD-423 URL: http://jira.jboss.com/jira/browse/JBBUILD-423 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - Maint 2007 The 2.0.0.Beta4 release of microcontainer is missing metadata files, and the tag has the incorrect version in a couple places. -- 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

18 years, 9 months

1
2
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 October 2007