September 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMETA-90) Inconsistent jaxb api dependency

by Scott M Stark (JIRA)

Inconsistent jaxb api dependency -------------------------------- Key: JBMETA-90 URL: https://jira.jboss.org/jira/browse/JBMETA-90 Project: JBoss Metadata Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.0.CR1 Reporter: Scott M Stark Fix For: 1.0.0.Beta35 The metadata jaxb api dependency is: <dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.1</version> <scope>compile</scope> </dependency> but it needs to be updated to be consistent with what we are validating in jbossas as part of the tck: <dependency> <groupId>sun-jaxb</groupId> <artifactId>jaxb-api</artifactId> <version>2.1.4</version> </dependency> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
9
0 / 0

[JBoss JIRA] Created: (JBMDR-42) AccessControl exception using findMethod

by Adrian Brock (JIRA)

AccessControl exception using findMethod ---------------------------------------- Key: JBMDR-42 URL: https://jira.jboss.org/jira/browse/JBMDR-42 Project: JBoss MetaData Repository Issue Type: Bug Components: Loader Reporter: Adrian Brock Assignee: Adrian Brock We need to introduce privileged blocks into AnnotatedMetaDataLoader otherwise user code that calls code that tries to access private method/field annotations is going to fail with an AccessControlException. e.g. aop might do this and the forum thread shows an example of a test creating BeanMetaData from an annotated class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAOP-634) UnmodifiableEmptyCollections$LockedArrayList is not truly unmodifiable

by Kabir Khan (JIRA)

UnmodifiableEmptyCollections$LockedArrayList is not truly unmodifiable ---------------------------------------------------------------------- Key: JBAOP-634 URL: https://jira.jboss.org/jira/browse/JBAOP-634 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR16 Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 2.0.0.GA Need to override a few more add() methods -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-680) receive_on_all_interfaces requires every NIC to be configured

by Edward Kuns (JIRA)

receive_on_all_interfaces requires every NIC to be configured ------------------------------------------------------------- Key: JGRP-680 URL: http://jira.jboss.com/jira/browse/JGRP-680 Project: JGroups Issue Type: Bug Affects Versions: 2.6.1 Environment: Windows Server 2003 Reporter: Edward Kuns Assigned To: Bela Ban In UDP with receive_on_all_interfaces="true", if any interface is not configured -- say, the network cable is unplugged -- then JGroups will refuse to start by throwing an exception (IP addresses changed to protect the innocent): Caused by: org.jgroups.ChannelException: failed to start protocol stack at org.jgroups.JChannel.startStack(JChannel.java:1445) at org.jgroups.JChannel.connect(JChannel.java:356) at org.jgroups.blocks.NotificationBus.start(NotificationBus.java:126) at the application making use of JGroups Caused by: java.lang.Exception: problem creating sockets (bind_addr=xxxxxxxx/11.22.33.44, mcast_addr=224.1.2.3:4444) at org.jgroups.protocols.UDP.start(UDP.java:363) at org.jgroups.stack.Configurator.startProtocolStack(Configurator.java:75) at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:301) at org.jgroups.JChannel.startStack(JChannel.java:1442) ... 9 more Caused by: java.net.SocketException: bad argument for IP_MULTICAST_IF2: No IP addresses bound to interface at java.net.PlainDatagramSocketImpl.join(Ljava.net.InetAddress;Ljava.net.NetworkInterface;)V(Native Method) at java.net.PlainDatagramSocketImpl.joinGroup(PlainDatagramSocketImpl.java:196) at java.net.MulticastSocket.joinGroup(MulticastSocket.java:357) at org.jgroups.protocols.UDP.bindToInterfaces(UDP.java:525) at org.jgroups.protocols.UDP.createSockets(UDP.java:470) at org.jgroups.protocols.UDP.start(UDP.java:359) ... 12 more Simply taking every NIC whose status is "network cable unplugged" and disabling that interface allows JGroups to start. This may be a feature request and not a bug report, but this seems unnecessarily strict. With the setting of receive_on_all_interfaces="true", if at least one interface comes up, then that should be enough for JGroups to function. In the application where I encountered this, I have both receive_on_all_interfaces="true" and send_on_all_interfaces="false". The reason is that if send_on_all_interfaces is true but JGroups fails to be able to send a message, there is no notification of this failure. (That is, if the message cannot be sent on any interface at all.) By sending on one interface by receiving on all, I appear to get the best of all worlds where a cluster of machines with multiple NICs should be able to communicate with one another no matter what the binding order of the NICs and no matter what order Java presents the interfaces. Except that receive_on_all_interfaces="true" requires EVERY NIC that is not disabled to be perfectly functioning or you cannot do anything at all. Which means unplug one NIC cable and now the application cannot function at all, despite the fact that there's another network on which the clustered machines are all available. Preferred behavior: If ** at least one ** interface successfully opens a socket when receive_on_all_interfaces="true", then succeed. If ** all ** interfaces fail as shown above, then throw the exception shown above. -- 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

15 years, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBAOP-630) Deadlock in beforeafter tutorial example

by Flavia Rainone (JIRA)

Deadlock in beforeafter tutorial example ---------------------------------------- Key: JBAOP-630 URL: https://jira.jboss.org/jira/browse/JBAOP-630 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR16 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 2.0.0.GA There is a deadlock occuring in this example: [java] Full thread dump Java HotSpot(TM) Server VM (1.5.0_12-b04 mixed mode): [java] [java] "DEPOSIT: A R$ 50,00" prio=1 tid=0x8c9a34e0 nid=0x3301 in Object.wait() [0x8c77b000..0x8c77c0b0] [java] at java.lang.Object.wait(Native Method) [java] - waiting on <0xade15de0> (a java.lang.Object) [java] at java.lang.Object.wait(Object.java:474) [java] at MutexAspect.beforeAdvice(MutexAspect.java:40) [java] - locked <0xade15de0> (a java.lang.Object) [java] at JoinPoint_run_N_8003352271541955702_1.invokeJoinpoint(JoinPoint_run_N_8003352271541955702_1.java) [java] at Deposit$DepositAdvisor.run_N_8003352271541955702(Deposit$DepositAdvisor.java) [java] at Deposit.run(Transaction.java) [java] at java.lang.Thread.run(Thread.java:595) [java] [java] "Low Memory Detector" daemon prio=1 tid=0x8c902888 nid=0x32ff runnable [0x00000000..0x00000000] [java] [java] "CompilerThread1" daemon prio=1 tid=0x8c901488 nid=0x32fe waiting on condition [0x00000000..0x8c8fe198] [java] [java] "CompilerThread0" daemon prio=1 tid=0x8c9004e8 nid=0x32fd waiting on condition [0x00000000..0x8cafe018] [java] [java] "AdapterThread" daemon prio=1 tid=0x09598238 nid=0x32fc waiting on condition [0x00000000..0x00000000] [java] [java] "Signal Dispatcher" daemon prio=1 tid=0x095b9818 nid=0x32fb waiting on condition [0x00000000..0x00000000] [java] [java] "Finalizer" daemon prio=1 tid=0x0949e6c0 nid=0x32fa in Object.wait() [0x8d68b000..0x8d68be30] [java] at java.lang.Object.wait(Native Method) [java] - waiting on <0xae2fd4c0> (a java.lang.ref.ReferenceQueue$Lock) [java] at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) [java] - locked <0xae2fd4c0> (a java.lang.ref.ReferenceQueue$Lock) [java] at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) [java] at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) [java] [java] "Reference Handler" daemon prio=1 tid=0x0949cfe0 nid=0x32f9 in Object.wait() [0x8d70c000..0x8d70d0b0] [java] at java.lang.Object.wait(Native Method) [java] - waiting on <0xae2ae7a0> (a java.lang.ref.Reference$Lock) [java] at java.lang.Object.wait(Object.java:474) [java] at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) [java] - locked <0xae2ae7a0> (a java.lang.ref.Reference$Lock) [java] [java] "main" prio=1 tid=0x093f7838 nid=0x32f2 in Object.wait() [0xbfe36000..0xbfe36268] [java] at java.lang.Object.wait(Native Method) [java] - waiting on <0xae284760> (a java.lang.Thread) [java] at java.lang.Thread.join(Thread.java:1095) [java] - locked <0xae284760> (a java.lang.Thread) [java] at java.lang.Thread.join(Thread.java:1148) [java] at Driver.main(Driver.java:69) [java] [java] "VM Thread" prio=1 tid=0x0949aaa8 nid=0x32f8 runnable [java] [java] "GC task thread#0 (ParallelGC)" prio=1 tid=0x094118b8 nid=0x32f6 runnable [java] [java] "GC task thread#1 (ParallelGC)" prio=1 tid=0x09412508 nid=0x32f7 runnable [java] [java] "VM Periodic Task Thread" prio=1 tid=0x8c904450 nid=0x3300 waiting on condition -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
5
0 / 0

[JBoss JIRA] Commented: (JBPORTAL-2102) cms admin ui testing

by Viliam Rockai (JIRA)

[ https://jira.jboss.org/jira/browse/JBPORTAL-2102?page=com.atlassian.jira.... ] Viliam Rockai commented on JBPORTAL-2102: ----------------------------------------- issue in jboss portal 2.6.6 GA: when i create new file, after clicking the "create" submit button i'm in the "Manage Content" screen, where it is possible to click on the language link. but clicking this language link raises an NullPointerException. > cms admin ui testing > -------------------- > > Key: JBPORTAL-2102 > URL: https://jira.jboss.org/jira/browse/JBPORTAL-2102 > Project: JBoss Portal > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Prabhat Jha > Assignee: Viliam Rockai > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4871) TransactionIsolation is not reset when Connection is returned to the pool

by Diego Belfer (JIRA)

TransactionIsolation is not reset when Connection is returned to the pool ------------------------------------------------------------------------- Key: JBAS-4871 URL: http://jira.jboss.com/jira/browse/JBAS-4871 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Reporter: Diego Belfer TransactionIsolation is not being reset when the JDBC connection is returned to the pool. Bug is indicated in the code. This was also reported in http://jira.jboss.com/jira/browse/JBAS-1123 and marked as closed but the bug is still there. public void cleanup() throws ResourceException { synchronized (handles) { for (Iterator i = handles.iterator(); i.hasNext(); ) { WrappedConnection lc = (WrappedConnection)i.next(); lc.setManagedConnection(null); } handles.clear(); } //reset all the properties we know about to defaults. synchronized (stateLock) { jdbcAutoCommit = true; jdbcReadOnly = readOnly; if (jdbcTransactionIsolation != transactionIsolation) { try { con.setTransactionIsolation(jdbcTransactionIsolation); <-- BUG: It should be con.setTransactionIsolation(transactionIsolation); jdbcTransactionIsolation = transactionIsolation; } catch (SQLException e) { mcf.log.warn("Error resetting transaction isolation ", e); } } } } -- 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

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMAN-22) Update jboss-test to 1.1.1.GA

by Adrian Brock (JIRA)

Update jboss-test to 1.1.1.GA ----------------------------- Key: JBMAN-22 URL: https://jira.jboss.org/jira/browse/JBMAN-22 Project: JBoss Managed Issue Type: Component Upgrade Reporter: Adrian Brock Assignee: Adrian Brock -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMAN-21) Update jboss-common-core to 2.2.8.GA

by Adrian Brock (JIRA)

Update jboss-common-core to 2.2.8.GA ------------------------------------ Key: JBMAN-21 URL: https://jira.jboss.org/jira/browse/JBMAN-21 Project: JBoss Managed Issue Type: Component Upgrade Reporter: Adrian Brock Assignee: Adrian Brock -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMAN-18) AbstractManagedObjectFactory doesn't compile and even if it did, it would loop

by Adrian Brock (JIRA)

AbstractManagedObjectFactory doesn't compile and even if it did, it would loop ------------------------------------------------------------------------------ Key: JBMAN-18 URL: https://jira.jboss.org/jira/browse/JBMAN-18 Project: JBoss Managed Issue Type: Bug Components: managedobject Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossMan.2.0.0.CR1 AbstractManagedObjectFactory doesn't compile [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure /home/ejort/jboss-man/managed/src/main/java/org/jboss/managed/plugins/factory/AbstractManagedObjectFactory.java:[750,40] incomparable types: java.lang.Class<T> and java.lang.Class<java.lang.Object> Even if it did, it would loop forever if it doesn't find the InstanceClassFactory @SuppressWarnings("unchecked") public <T extends Serializable> InstanceClassFactory<T> getInstanceClassFactory(Class<T> clazz) { synchronized (instanceFactories) { Class<?> c = clazz; InstanceClassFactory factory = instanceFactories.get(c); - while(factory == null && clazz != Object.class) + while(factory == null && c != Object.class) { c = c.getSuperclass(); factory = instanceFactories.get(c); } if (factory != null) return factory; } InstanceClassFactory<T> factory = (InstanceClassFactory<T>) defaultInstanceFactory; return factory; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2008