February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2842) Add support for stopping ILs triggering the ExceptionListener

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2842?page=all ] Adrian Brock updated JBAS-2842: ------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Add support for stopping ILs triggering the ExceptionListener > ------------------------------------------------------------- > > Key: JBAS-2842 > URL: http://jira.jboss.com/jira/browse/JBAS-2842 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-4.2.1.CR1 > > > As per the super task which is a fix to make sure client exception listeners > get triggered if somebody stops the server, this same behaviour should > occur if somebody just stops the IL. > This involves making each IL keep track of their respective connections. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1313) RepositorySelector should be integrated into JBoss Server

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1313?page=all ] Dimitris Andreadis updated JBAS-1313: ------------------------------------- Fix Version/s: JBossAS-5.0.1.CR1 (was: JBossAS-4.2.0.CR1) I don't think we can change this in the 4.2.0 timeframe, we just have too many pending items. Maybe better to try this in a 5.x release (even 5.0.0.Beta if someone has the time to look into it). > RepositorySelector should be integrated into JBoss Server > --------------------------------------------------------- > > Key: JBAS-1313 > URL: http://jira.jboss.com/jira/browse/JBAS-1313 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Stan Silvert > Assigned To: Stan Silvert > Priority: Minor > Fix For: JBossAS-5.0.1.CR1 > > Attachments: log4-rs.zip > > > Often, an application will want to have its own log4j configuration and have all log messages generated go to an application-specific log file. Solutions to this problem are documented on this wiki page: http://www.jboss.org/wiki/Wiki.jsp?page=Logging > The log4j RepositorySelector provides a clean solution to this problem without any special classloader settings. However, at the present time, a developer must create his own version of a RepositorySelector and make sure his application initializes it properly. > This can be difficult to accomplish because the RepositorySelector feature is not well known and takes time to understand. It can also be difficult to make sure that the RepositorySelector is initialized before the application makes ANY call to Logger.getLogger(). > We can instead, provide a RepositorySelector implementation as part of the JBoss Application server. If a deployer finds a log4j.xml file in the /META-INF direcotry (or /WEB-INF for WARs) it would add an entry into the RepositorySelector for that application. Then, logging from that application would use the custom log4j configuration. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1984) HttpNamingContextFactory unable to reconnect

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1984?page=all ] Dimitris Andreadis updated JBAS-1984: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > HttpNamingContextFactory unable to reconnect > -------------------------------------------- > > Key: JBAS-1984 > URL: http://jira.jboss.com/jira/browse/JBAS-1984 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming, Remoting > Affects Versions: JBossAS-3.2.7 Final > Environment: XP > Reporter: Bernd Eckenfels > Assigned To: Tom Elrod > Fix For: JBossAS-4.2.1.CR1 > > > Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this: > ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]] > javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]] > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568) > at net.eckenfels.JNDITest.main(JNDITest.java:72) > Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250) > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348) > ... 3 more > Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224) > ... 4 more > Caused by: java.net.UnknownHostException: http: http > at java.net.InetAddress.getAllByName0(InetAddress.java:1128) > at java.net.InetAddress.getAllByName0(InetAddress.java:1098) > at java.net.InetAddress.getAllByName(InetAddress.java:1061) > at java.net.InetAddress.getByName(InetAddress.java:958) > at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61) > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220) > ... 4 more > Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct: > p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory"); > p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory"); > p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); > p.put("jnp.disableDiscovery", "true"); > Context rootCtx = (Context)new InitialContext(p); > while(true) > { > try > { > // rootCtx = new InitialContext(p); > Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi"); > l = jmxCtx.list(""); > while(l.hasMore()) > { > System.out.println(" - " + l.next()); > } > } catch (Throwable t) { > System.out.println("ex: " + t); t.printStackTrace(System.out); > } > try{Thread.sleep(10000);}catch(Throwable t) { } > } > This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling. > The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2412) Update the logging framework

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2412?page=all ] Dimitris Andreadis updated JBAS-2412: ------------------------------------- Fix Version/s: JBossAS-5.0.1.CR1 (was: JBossAS-4.2.0.CR1) No time for it in the 4.2.0 timeframe > Update the logging framework > ---------------------------- > > Key: JBAS-2412 > URL: http://jira.jboss.com/jira/browse/JBAS-2412 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Scott M Stark > Fix For: JBossAS-5.0.1.CR1 > > > Its been a long time since we revisted the logging framework and the use of log4j as the default. I looked at having better seamless integration with the jdk java.util.logging framework using a port of the log4j appenders/layout to jdk handlers/formatters and the initial prototype is in head as mentioned in the linked forum thread. > We need to reevaluate what the default logging implementation should be along with what updates the Log4jService needs. Some things to think about: > 1. Using a log4j implementation that does not suffer from the current deadlock problem > 2. How to nlog4j, slf4j, commons logging fit into the picture > 3. Generalization of the Log4jService into one that works for whatever the default implementation is > 3a. Add support for redirecting stderr, stdout to seperate log files instead of all loggers. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1505) Wrong exception message for missing findByPrimaryKey() method

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1505?page=all ] Dimitris Andreadis updated JBAS-1505: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Wrong exception message for missing findByPrimaryKey() method > ------------------------------------------------------------- > > Key: JBAS-1505 > URL: http://jira.jboss.com/jira/browse/JBAS-1505 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB2 > Affects Versions: JBossAS-4.0.1 SP1 > Environment: Windows 2000 Professional / Sun JDK 1.4.2_04 > Reporter: Torsten Paul > Assigned To: Alexey Loubyansky > Priority: Minor > Fix For: JBossAS-4.2.1.CR1 > > Attachments: testcase.zip > > > When deploying an application including a bean with a missing findByPrimaryKey() method in the home interface the exception message gives not the offending bean > but an arbitrary other bean that possibly has a findByPrimaryKey() method. This makes it hard to find the bean that needs fixing. > (Explained in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48222 but I didn't find a bugtracking entry for 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1808) Expose PreparedStatementCache via JMX

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1808?page=all ] Dimitris Andreadis updated JBAS-1808: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Expose PreparedStatementCache via JMX > ------------------------------------- > > Key: JBAS-1808 > URL: http://jira.jboss.com/jira/browse/JBAS-1808 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Scott M Stark > Assigned To: Weston Price > Priority: Minor > Fix For: JBossAS-4.2.1.CR1 > > > The PreparedStatementCache cache in the JCA layer has no exposure via jmx. Info like the min, max, avg, etc. number of prepared statements are in the cache would be useful. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2558) default virtual host always "localhost"

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2558?page=all ] Dimitris Andreadis updated JBAS-2558: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > default virtual host always "localhost" > --------------------------------------- > > Key: JBAS-2558 > URL: http://jira.jboss.com/jira/browse/JBAS-2558 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Arto Huusko > Assigned To: Remy Maucherat > Priority: Minor > Fix For: JBossAS-4.2.1.CR1 > > > JBoss 4.0.3SP1 admin guide claims that > "When a WAR file is deployed, it is associated by default with the virtual host whose name matches the defaultHost attribute of the containing Engine." > This is false, and thus default WAR deployments are broken when there is no host named "localhost" -- or even if there is such virtual host, but WARs should not be deployed there by default. > It seems that, regardless of what Hosts are configured, and what the defaultHost is, if WAR does not have a jboss-web descriptor that specifies the virtual host, the WAR always deploys to "localhost". If there is no Host with that name configured, the WAR is inaccessible. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3964) DeployerInterceptorEJB3 depends on jboss.ejb3:service=EJB3Deployer

by Dimitris Andreadis (JIRA)

DeployerInterceptorEJB3 depends on jboss.ejb3:service=EJB3Deployer ------------------------------------------------------------------ Key: JBAS-3964 URL: http://jira.jboss.com/jira/browse/JBAS-3964 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Reporter: Dimitris Andreadis Assigned To: Thomas Diesler Fix For: JBossAS-4.2.0.CR1 The latest refactoring on Branch_4_2 that replaced jbossws14.sar with jbossws.sar expects the EJB3Deployer to be present. EJB3 is still an optional component in JBossAS, so although we now require jdk5, we may not have EJB3 present. We need to include a jboss-service.xml descriptor that doesn't have this dependency, in the standard (no EJB3) jbossAS config. 20:19:01,166 ERROR [URLDeploymentScanner] Incomplete Deployment listing: --- MBeans waiting for other MBeans --- ObjectName: jboss.ws:service=DeployerInterceptorEJB3 State: CONFIGURED I Depend On: jboss.ejb3:service=EJB3Deployer --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: jboss.ejb3:service=EJB3Deployer State: NOTYETINSTALLED Depends On Me: jboss.ws:service=DeployerInterceptorEJB3 -- 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

19 years, 2 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBAS-1608) Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1608?page=all ] Dimitris Andreadis updated JBAS-1608: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) Assignee: (was: Amit Bhayani) I think I'm talking to myself. > Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean > ------------------------------------------------------------------------------- > > Key: JBAS-1608 > URL: http://jira.jboss.com/jira/browse/JBAS-1608 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Management services > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1 > Environment: Nothing specific > Reporter: Amit Bhayani > Priority: Minor > > The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma). > For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz(a)nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3221) Need to rewrite JBossMQ tests to be more robust

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3221?page=all ] Dimitris Andreadis updated JBAS-3221: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Need to rewrite JBossMQ tests to be more robust > ----------------------------------------------- > > Key: JBAS-3221 > URL: http://jira.jboss.com/jira/browse/JBAS-3221 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service, Test Suite > Affects Versions: JBossAS-4.0.4.GA > Reporter: Scott M Stark > Fix For: JBossAS-4.2.1.CR1 > > > Repeated runs of the JMSContainerInvokerQueueMessageDrivenUnitTestCase on my laptop (1.6GHz Pentium M) will result in the following failure: > <testcase classname="org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase" name="testRestartJMS" time="30.891"> > <error message="Wrong number of messages, expected=2 > got=1" type="java.lang.Exception">java.lang.Exception: Wrong > number of messages, expected=2 got=1 > at org.jboss.test.messagedriven.support.CheckMessageSizeOperation.run(CheckMessageSizeOperation.java:46) > at org.jboss.test.messagedriven.support.BasicMessageDrivenUnitTest.runTest(BasicMessageDrivenUnitTest.java:112) > at org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase.testRestartJMS(JMSContainerInvokerQueueMessageDrivenUnitTestCase.java:67) > From Adrian: > The fundamental problem is waiting on a timeout for asynchronous work which will be subject to all sorts of random failures if for example you run it on your laptop while you are doing compiles or downloading e-mail. > The thread doing the wait (or the server thread doing the work) simply doesn't get scheduled in time because the cpu is busy. > The hard part is when you do a wait and you expect nothing to happen in that wait time. You don't want to slow down the testsuite doing long waits. > In general, these tests can be written better, but doing so also means testing things beyond the spec like looking at service instrumentation to check there is no outstanding work to performed before asserting state. > e.g. The jms queue is empty or a thread pool has no scheduled work, 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

19 years, 2 months

1
0
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 February 2007