January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7447) PersistentManager for sessions is broken

by Emilio Davis (JIRA)

PersistentManager for sessions is broken ---------------------------------------- Key: JBAS-7447 URL: https://jira.jboss.org/jira/browse/JBAS-7447 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-5.1.0.GA Reporter: Emilio Davis Assignee: Remy Maucherat Using the following context.xml <Context cookies="true" crossContext="true"> <Manager className="org.apache.catalina.session.PersistentManager" maxIdleSwap="1200" saveOnRestart="true"> <Store checkInterval="60" className="org.apache.catalina.session.JDBCStore" connectionURL="jdbc:mysql://localhost:3306/XXX?user=XXX&password=XXX" driverName="com.mysql.jdbc.Driver" sessionAppCol="app_name" sessionDataCol="session_data" sessionIdCol="session_id" sessionLastAccessedCol="last_access" sessionMaxInactiveCol="max_inactive" sessionTable="tomcat_sessions" sessionValidCol="valid_session"/> </Manager> <InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener> </Context> That used to work in jboss4.0.5GA and correct according to tomcat 6 documentation jboss 5.1.0GA fails to start tomcat with the following exception: 2009-11-02 23:11:54,292 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) deplo y, ctxPath=/ 2009-11-02 23:11:55,619 ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] (main) XML error parsing: context.xml org.jboss.xb.binding.JBossXBException: Failed to parse source: Store not found as a child of Manager in unordered_sequence: attributes? at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:183) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133) at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextCo nfig.java:573) at org.jboss.web.tomcat.service.deployers.JBossContextConfig.init(JBossContextConfig.java:536) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.StandardContext.init(StandardContext.java:5436) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4148) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeploymen t.java:310) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:1 42) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) 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:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) 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:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) at $Proxy38.start(Unknown Source) I opened a thread in the tomcat integration forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=163337) but got no response. -- 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

14 years, 11 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-8786) JBoss unpacks all jars from WEB-INF\lib of war file

by Maxym Pendyshchuk (JIRA)

JBoss unpacks all jars from WEB-INF\lib of war file --------------------------------------------------- Key: JBAS-8786 URL: https://issues.jboss.org/browse/JBAS-8786 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Environment: Windows XP x32 Reporter: Maxym Pendyshchuk while starting JBoss AS it unpacks all jar files, which are located in WEB-INF/lib folder of each my war file. It means that in tmp folder mostly I see folder with jar file, and folder with its content. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files: asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar" actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp: asm-3.1.jar-215a36131ebb088e/asm-3.1.jar asm-3.1.jar-14695f157664f00/contents/ but in this case last folder is empty. So it still creates two folders, but does not unpack my library. Also I use exploded deployment so the question is only about jar files, not unpacking ear/war. the problem is that it slows down application server booting (when I repack all my war files as ear and moved war libraries to ear/lib folder then I save 2+ minutes at JBoss 6 booting...). If it is done deliberately (so it improves some performance at runtime), then would be nice to have a configuration option, so during development I can save time to boot my local JBoss AS -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

11
29
0 / 0

[JBoss JIRA] Created: (JBRULES-2289) Support JPA Resource Local EntityTransaction based Transactions

by Michael Youngstrom (JIRA)

Support JPA Resource Local EntityTransaction based Transactions --------------------------------------------------------------- Key: JBRULES-2289 URL: https://jira.jboss.org/jira/browse/JBRULES-2289 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 5.0.1.FINAL Reporter: Michael Youngstrom Assignee: Mark Proctor It would be nice if wherever JPA is used in Drools (drools-flow in particular) there was support for RESOURCE_LOCAL transactions through JPA's EntityTransaction interface as an alternative to JTA. Support for resource local transactions would reduce the base Drools Flow dependency footprint (no need for bitronix) as well as allow Drools to be used in a containerless or Tomcat like environment without a JTA implementation available. Although embeddable solutions are available they are often either buggy or complex. It would be nice to not have to deal with them if possible. If the idea is acceptable I'd be willing to put together an initial patch. -- 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

14 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1771) NotSerializableException is thrown from DayCounter class

by Tyronne Wickramarathne (JIRA)

NotSerializableException is thrown from DayCounter class -------------------------------------------------------- Key: JBMESSAGING-1771 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1771 Project: JBoss Messaging Issue Type: Bug Components: Configuration and Management Affects Versions: 1.4.0.SP3.CP08 Environment: JBoss-SOA-4.3_CP2, JBM-1.4.0.SP3-CP08.patch01 Reporter: Tyronne Wickramarathne Even though the MessageCounter class implements Serializable interface as per JBMESSAGING-1430; the NotSerializableException is still thrown when accessing MessageCounter via JMX console. The root cause seems to be the DayCounter 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

14 years, 11 months

4
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1791) ConcurrentModificationException at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally

by Tamas Cserveny (JIRA)

ConcurrentModificationException at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally ----------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1791 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1791 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.SP3 Environment: JBoss AS 4.2.3.GA Release (JBossESB 4.7) jboss.messaging.jmsVersion=1.1 jboss.messaging.jmsMajorVersion=1 jboss.messaging.jmsMinorVersion=1 jboss.messaging.jmsProviderName=JBoss Messaging jboss.messaging.providerVersion=1.4.0.SP3 jboss.messaging.providerMajorVersion=1 jboss.messaging.providerMinorVersion=4 jboss.messaging.providerIncrementingVersion=21 Reporter: Tamas Cserveny Hi, I found a CME in the JBoss-messageing. Test scenario: Vanilla JBossESB 4.7 with a simple flow. (file -> queue, bridge queue to another queue, queue -> file) I kept this server running on a 2 core system with a load of 10 messages / sec. (ca 3kb messages). I received many of these exception during the test. It caused some messages to stuck into the queue, but eventually they were redelivered. (Not after 5s, but after some other messages). They were counted in the 'DeliveringCount', and stayed like that. Cheers, Tamas 2010-02-26 00:00:50,083 ERROR [org.jboss.jms.client.container.ClientConsumer] Failed to deliver message javax.jms.JMSException: There is no transaction with id LocalTx[m0r-676r546g-1-2tbmq36g-nq5p47-51zk6a] at org.jboss.jms.tx.ResourceManager.addAck(ResourceManager.java:186) at org.jboss.jms.client.container.SessionAspect.handlePreDeliver(SessionAspect.java:293) at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect19.invoke(SessionAspect19.java) at org.jboss.jms.client.delegate.ClientSessionDelegate$preDeliver_5548846795541436298.invokeNext(ClientSessionDelegate$preDeliver_5548846795541436298.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientSessionDelegate$preDeliver_5548846795541436298.invokeNext(ClientSessionDelegate$preDeliver_5548846795541436298.java) at org.jboss.jms.client.delegate.ClientSessionDelegate.preDeliver(ClientSessionDelegate.java) at org.jboss.jms.client.container.ClientConsumer.callOnMessage(ClientConsumer.java:152) at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(ClientConsumer.java:976) at org.jboss.messaging.util.JBMExecutor$TCLExecutor.run(JBMExecutor.java:78) at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89) at java.lang.Thread.run(Thread.java:619) 2010-02-26 00:03:22,084 ERROR [org.jboss.messaging.util.ExceptionUtil] ConnectionEndpoint[uip-txvw446g-1-2tbmq36g-nq5p47-51zk6a] sendTransaction [f6r-ghfu546g-1-2tbmq36g-nq5p47-5 java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally(ServerSessionEndpoint.java:1474) at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoint.java:810) at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:473) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java) at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:195) -- 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

14 years, 11 months

4
13
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1795) HTTPS transport support for JBM

by Tyronne Wickramarathne (JIRA)

HTTPS transport support for JBM ------------------------------- Key: JBMESSAGING-1795 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1795 Project: JBoss Messaging Issue Type: Task Components: JMS Remoting Affects Versions: 1.4.0.SP3.CP10 Environment: JBoss-EAP-4.3_CP7 Reporter: Tyronne Wickramarathne Priority: Minor Fix For: 1.4.0.SP3.CP11 At present HTTPS transport support isn't available by default for JBM. However, as per Remoting manual, it is possible to configure HTTPS transport for JBM -- 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

14 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2230) Create an EJB 3 implementation for AS 7

by Carlo de Wolf (JIRA)

Create an EJB 3 implementation for AS 7 --------------------------------------- Key: EJBTHREE-2230 URL: https://issues.jboss.org/browse/EJBTHREE-2230 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Assignee: Carlo de Wolf Priority: Critical Fix For: 2.0.0-alpha-1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-619) Change getState semantics

by Vladimir Blagojevic (JIRA)

Change getState semantics ------------------------- Key: JGRP-619 URL: http://jira.jboss.com/jira/browse/JGRP-619 Project: JGroups Issue Type: Task Affects Versions: 2.5, 2.4, 2.3, 2.2.9 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 3.0 Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer. We have to simplify this process! State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener. This issue is closely related to revamping of channel state transfer callbacks - JGRP-563 -- 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

14 years, 11 months

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-8797) Logging with SLF4J produces wrong output when using multiple parameters in format

by Jens Reimann (JIRA)

Logging with SLF4J produces wrong output when using multiple parameters in format --------------------------------------------------------------------------------- Key: JBAS-8797 URL: https://issues.jboss.org/browse/JBAS-8797 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: 6.0.0.Final Environment: Ubuntu Linux 64bit Reporter: Jens Reimann Assignee: David Lloyd Logging with SLF4J and passing parameters as Object[] produces wrong output in the JBoss log: e.g.: logger.debug ( "Logging - Level: {}, Action: {}, Result: {}, UserData: {}, Reference: {}/{}", new Object[] { level, action, result, data, referenceType, referenceId } ); produces Logging - Level: <parameter #1 as Object[]>, Action: {}, Result: {}, .... It seems to me that instead of handling the Object[] that is passed as array is used later on as simple Object which reduces the provided parameters to 1 instead. There seems to be no problem with the log calls that take one or two objects (which are separate methods in SLF4J). I would consider it major since it scrambles all logging messages using the Object[] methods. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-8813) Upgrade to slf4j-jboss-logmanager 1.0.0.GA

by David Lloyd (JIRA)

Upgrade to slf4j-jboss-logmanager 1.0.0.GA ------------------------------------------ Key: JBAS-8813 URL: https://issues.jboss.org/browse/JBAS-8813 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Logging Reporter: David Lloyd Assignee: David Lloyd Fix For: 6.0.1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

2
3
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 January 2011