October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1068) @Interceptors defined on @Service EJBs do not have @PostConstruct @PreDestroy interceptor methods invoked

by Michael McKibben (JIRA)

@Interceptors defined on @Service EJBs do not have @PostConstruct @PreDestroy interceptor methods invoked --------------------------------------------------------------------------------------------------------- Key: EJBTHREE-1068 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1068 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: AS 4.2.1.GA Reporter: Michael McKibben I've defined an injection-style interceptor class that needs to be called before a @Service EJBs start() method is invoked on service startup. Using @PostConstruct doesn't not work (the container never calls my @PostConstruct annotated method). @AroundInvoke only works for methods defined on the @Local or @Remote business interface, not the @Management interface. Shouldn't @PostConstruct and @PreDestroy be invoked on @Service EJBs? I need my interceptor to behave like the standard injection interceptors do. -- 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, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4905) Resolve EJB3 / Web Service integration issues

by Thomas Diesler (JIRA)

Resolve EJB3 / Web Service integration issues --------------------------------------------- Key: JBAS-4905 URL: http://jira.jboss.com/jira/browse/JBAS-4905 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Thomas Diesler Fix For: JBossAS-4.2.3.GA This is a container for relevant ejb3/jbossws integration issues -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-549) ConnectionTable: spurious Connection instances on concurrent connects

by Bela Ban (JIRA)

ConnectionTable: spurious Connection instances on concurrent connects --------------------------------------------------------------------- Key: JGRP-549 URL: http://jira.jboss.com/jira/browse/JGRP-549 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario: - A attempts to connect to B (new Socket()) - B attempts to connect to A - A accepts B's connection and adds an entry for B into its table - B adds an entry for A into its table - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not ! GOAL: #1 Have only 1 TCP connection between any 2 members #2 Establish a handshaking mechanism, to avoid spurious connections SOLUTION: - When A establishes a connection to B, A needs to get agreement from B first (and vice versa) -- 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, 7 months

4
9
0 / 0

[JBoss JIRA] Created: (JBAS-4558) Connection Timeout Immediately After ACKing A Request

by Mike Millson (JIRA)

Connection Timeout Immediately After ACKing A Request ----------------------------------------------------- Key: JBAS-4558 URL: http://jira.jboss.com/jira/browse/JBAS-4558 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-4.0.2 Final Reporter: Mike Millson Assigned To: Thomas Diesler The customer has an application that periodically sends Web service requests to JBoss AS every 20 secs in sets of 4, to check wether the Web Service is up. They find that JBoss AS occasionally drops the request packets when the HTTP connector timeout is set to 20 seconds. When this happens, the packet sequence is very strange. Attached is an example packet sequence viewable using ethereal/WireShark. #275: Client sends request >20 seconds after #274 acknowledgment #276: Server sends ACK for #275 #277: Server sends connection timeout FIN/ACK #278 Client sends combined ACK for #277 and FIN/ACK #279 Server sends ACK for #278 Packet #275 was more than 20 seconds after the last packet was sent; however, it was received before the server initiated the connection timeout sequence in packets #277-279. It seems to be unaware of the ACK in #276. Almost as if the timeout sequence started, then before the FIN/ACK could be sent, another packet was received and acknowledged. Some sort of timing issue when a request is sent at the same time a connection times out. -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-898) Logging stays silent when a RuntimeException is thrown from preDestroy method

by Carlo de Wolf (JIRA)

Logging stays silent when a RuntimeException is thrown from preDestroy method ----------------------------------------------------------------------------- Key: EJBTHREE-898 URL: http://jira.jboss.com/jira/browse/EJBTHREE-898 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC10 - FD Reporter: Carlo de Wolf Priority: Critical 09:48:47,432 INFO [STDOUT] ContainedBean.preDestroy 09:48:47,432 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_4] TwoPhaseCoordinator.afterCompletion - returned failure for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple@1ccc3ea -- 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, 7 months

6
12
0 / 0

[JBoss JIRA] Created: (EJBTHREE-995) Multiple Synchronizations registered for a SFSB.

by Gavin King (JIRA)

Multiple Synchronizations registered for a SFSB. ------------------------------------------------ Key: EJBTHREE-995 URL: http://jira.jboss.com/jira/browse/EJBTHREE-995 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 GA Reporter: Gavin King It seems that each time a bean that implements SessionSynchronization is called, a new Synchronization is registered with JTA. This results in multiple calls to afterBegin(), beforeCompletion() and afterCompletion() in each transaction. -- 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, 7 months

4
17
0 / 0

[JBoss JIRA] Created: (SECURITY-34) Container Task: Formalize Kerberos offering

by Anil Saldhana (JIRA)

Container Task: Formalize Kerberos offering ------------------------------------------- Key: SECURITY-34 URL: http://jira.jboss.com/jira/browse/SECURITY-34 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 1.x, 2.0 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0 Spoken to Chris Delashmutt about formalizing the initial work he did for Kerberos/spnego. http://wiki.jboss.org/wiki/Wiki.jsp?page=NegotiateKerberos This jira task is a container task for overall kerberos silent authentication tasks. -- 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, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-523) Implement topic hierarchies

by Tim Fox (JIRA)

Implement topic hierarchies --------------------------- Key: JBMESSAGING-523 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-523 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 Implement topic hierarchies so a subscription can subscribe to a wildcard, e.g. news.* and will receive all messages sent to topics news.uk, news.usa, news.usa.local etc etc -- 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, 7 months

5
8
0 / 0

[JBoss JIRA] Created: (JBAS-4012) ClassLoaderUtils recurses into .war directories

by David (JIRA)

ClassLoaderUtils recurses into .war directories ----------------------------------------------- Key: JBAS-4012 URL: http://jira.jboss.com/jira/browse/JBAS-4012 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.0.5.GA Environment: windows xp, java 1.5.0_09 Reporter: David Assigned To: Scott M Stark Priority: Minor ClassLoaderUtils has logic that is supposed to prevent indexing/scanning of .war directories. This was an issue fixed earlier in 3.2.6, reported in a support case: 00002351 The following patch is also needed in order to fully prevent indexing in .war directories: $ diff -u src/org/jboss/mx/loading/ClassLoaderUtils.java /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java --- src/org/jboss/mx/loading/ClassLoaderUtils.java 2007-01-24 14:27:27.607071000 -0500 +++ /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java 2006-10-16 23:37:24.000000000 -0400 @@ -472,27 +472,21 @@ String name = start.getName(); // Don't recurse into wars boolean isWar = name.endsWith(".war"); - if( isWar ) { - log.trace("war, not recursing"); + if( isWar ) currentListing = new File[0]; - } - else { + else currentListing = start.listFiles(); - } } FileIterator(File start, FileFilter filter) { String name = start.getName(); // Don't recurse into wars boolean isWar = name.endsWith(".war"); - if( isWar ) { - log.trace("war, not recursing"); + if( isWar ) currentListing = new File[0]; - } - else { + else currentListing = start.listFiles(filter); - this.filter = filter; - } + this.filter = filter; } File getNextEntry() @@ -503,13 +497,7 @@ do { File nextDir = (File) subDirectories.removeFirst(); - if (nextDir.getName().endsWith(".war")) { - log.trace("war, not recursing"); - currentListing = new File[0]; - } - else { - currentListing = nextDir.listFiles(filter); - } + currentListing = nextDir.listFiles(filter); } while( currentListing.length == 0 && subDirectories.size() > 0 ); index = 0; } The stack trace during startup is here: "main" prio=6 tid=0x1bcadc70 nid=0xec4 runnable [0x1c02e000..0x1c02fb18] at java.io.WinNTFileSystem.list(Native Method) at java.io.File.list(File.java:937) at java.io.File.listFiles(File.java:1093) at org.jboss.mx.loading.ClassLoaderUtils$FileIterator.getNextEntry(ClassLoaderUtils.java:500) at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.getNextEntry(ClassLoaderUtils.java:617) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:319) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:253) at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap(UnifiedLoaderRepository3.java:783) at org.jboss.mx.loading.UnifiedLoaderRepository3.addRepositoryClassLoader(UnifiedLoaderRepository3.java:740) - locked <0x07aafcf0> (a EDU.oswego.cs.dl.util.concurrent.CopyOnWriteArraySet) at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader(UnifiedLoaderRepository3.java:662) at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader(UnifiedLoaderRepository3.java:946) at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader(UnifiedLoaderRepository3.java:168) at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.deployment.DeploymentInfo.createClassLoaders(DeploymentInfo.java:280) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:874) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) - locked <0x07e0e0d8> (a org.jboss.deployment.scanner.URLDeploymentScanner) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) - locked <0x07ec9400> (a org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) - locked <0x07af6660> (a org.jboss.system.ServiceController) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:490) at java.lang.Thread.run(Thread.java:595) with trace logging on you see: -- 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, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-340) Major overhaul of GossipRouter

by Bela Ban (JIRA)

Major overhaul of GossipRouter ------------------------------ Key: JGRP-340 URL: http://jira.jboss.com/jira/browse/JGRP-340 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Things to be done: - Use of Streamable rather than Externalizable - Currently we use 1 thread per request rather than a thread pool, e.g. Executor ! - Better logging and diagnostics (JMX) -- 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, 7 months

2
18
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007