January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-391) sometimes the parser is not found when doing a parameter reload.

by Kurt Stam (JIRA)

sometimes the parser is not found when doing a parameter reload. ---------------------------------------------------------------- Key: JBESB-391 URL: http://jira.jboss.com/jira/browse/JBESB-391 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 Environment: any Reporter: Kurt Stam Assigned To: Mark Little Fix For: 4.0 When running the deployToSar task of the hello world quickstart on a running jboss, the timestamp on the jbossesb.xml changes and the parameters are reloaded. When this happens sometimes see the following stacktrace: 15:18:25,687 INFO [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 40s:875ms 15:18:47,296 ERROR [STDERR] Exception in thread "Thread-6" 15:18:47,296 ERROR [STDERR] org.apache.xerces.parsers.ObjectFactory$ConfigurationError: Provider org.apache.xerces.parsers.XIncludeAwareParserConfiguration could not be instantiated: java.lang.NullPointerException 15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source) 15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source) 15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source) 15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source) 15:18:47,296 ERROR [STDERR] at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source) 15:18:47,296 ERROR [STDERR] at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source) 15:18:47,296 ERROR [STDERR] at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source) 15:18:47,296 ERROR [STDERR] at org.jboss.soa.esb.listeners.config.XmlValidatorImpl.validate(XmlValidatorImpl.java:160) 15:18:47,296 ERROR [STDERR] at org.jboss.soa.esb.listeners.config.ConfigurationController.processConfiguration(ConfigurationController.java:176) 15:18:47,296 ERROR [STDERR] at org.jboss.soa.esb.listeners.config.ConfigurationController.run(ConfigurationController.java:113) 15:18:47,296 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) 15:19:12,515 ERROR [STDERR] Exception in thread "Thread-15" which is thrown from the line 160 in the XmlValidatorImpl: parser = builderFactory.newDocumentBuilder(); The issue seems to fix it self, as it seems to be successful 5 seconds later. -- 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, 3 months

3
9
0 / 0

[JBoss JIRA] Created: (JBESB-368) Hot redeployment

by Mark Little (JIRA)

Hot redeployment ---------------- Key: JBESB-368 URL: http://jira.jboss.com/jira/browse/JBESB-368 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.0 CR2 Reporter: Mark Little Assigned To: Kurt Stam Fix For: 4.0 Action classes, DRLs, process def scripts, transformation selection rules. -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3546) Change log level on CachedConnectionManager.closeConnection() to warn

by Felipe Leme (JIRA)

Change log level on CachedConnectionManager.closeConnection() to warn --------------------------------------------------------------------- Key: JBAS-3546 URL: http://jira.jboss.com/jira/browse/JBAS-3546 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.4.GA Reporter: Felipe Leme Assigned To: Weston Price Priority: Trivial The feature of the CachedConnectionManager automatically closing connections (and warning about the fact) is pretty useful; in fact, so useful that we would like to receive email notifications when it occurs. But, unfortunatelly, we are not receiving such notifications, as our log4j SMTP appender is set to the WARN threshold, while such warnings are being logged as info: if (e != null) log.info("Closing a connection for you. Please close them yourself: " + c, e); else log.info("Closing a connection for you. Please close them yourself: " + c); m.invoke(c, new Object[]{}); } catch (Throwable t) { log.info("Throwable trying to close a connection for you, please close it yourself", t); } } catch (NoSuchMethodException nsme) { log.info("Could not find a close method on alleged connection objects. Please close your own connections."); } So, I'm proposing these loggings are changed from info() to warn() - I don't think such change will cause any 'logging havoc', as the messages are only logged when the CachedConnectionManager is set to debug them... -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAOP-336) NPE using caller pointcuts from a constructor

by Kabir Khan (JIRA)

NPE using caller pointcuts from a constructor --------------------------------------------- Key: JBAOP-336 URL: http://jira.jboss.com/jira/browse/JBAOP-336 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha2, 1.5.2.GA Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 1.5.3.GA, 2.0.0.alpha3 -- 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, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JBPM-829) added reference from task instance to process instance

by Tom Baeyens (JIRA)

added reference from task instance to process instance ------------------------------------------------------ Key: JBPM-829 URL: http://jira.jboss.com/jira/browse/JBPM-829 Project: JBoss jBPM Issue Type: Task Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM 3.2 beta 2 for easier querieing, it is convenient that there is a direct reference from task instance to process instance. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-787) Invocations time out because remoting mismanages client invokers, sending bussines traffic over client invokers with small timeout

by Ovidiu Feodorov (JIRA)

Invocations time out because remoting mismanages client invokers, sending bussines traffic over client invokers with small timeout ---------------------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-787 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-787 Project: JBoss Messaging Issue Type: Bug Components: JMS Remoting Affects Versions: 1.0.1.SP2, 1.0.1.SP3 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.0.1.SP4 -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-691) Application-level invocations are sent over client invokers only supposed to handle PINGs and that unapropriately timeout after 1000 ms

by Ovidiu Feodorov (JIRA)

Application-level invocations are sent over client invokers only supposed to handle PINGs and that unapropriately timeout after 1000 ms --------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-691 URL: http://jira.jboss.com/jira/browse/JBREM-691 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: general Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 2.2.0.Alpha7 -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-559) Package list view

by Michael Neale (JIRA)

Package list view ----------------- Key: JBRULES-559 URL: http://jira.jboss.com/jira/browse/JBRULES-559 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-628) restore should copy old version into new version, not replace

by Michael Neale (JIRA)

restore should copy old version into new version, not replace ------------------------------------------------------------- Key: JBRULES-628 URL: http://jira.jboss.com/jira/browse/JBRULES-628 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBAS-3379) BigIntegerTimerIdGenerator may create dupplicate timer IDs after server crash

by Matt Kleiderman (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3379?page=comments#action_12351878 ] Matt Kleiderman commented on JBAS-3379: --------------------------------------- I'm getting failures to persist timers based on duplicate primary key entries even without a server shutdown. I'm running apps where a bean lives in a loop where it does something, and then schedules the next occurrence. The time between events is variable, so I can't schedule a recurring timer. But if I keep watching the database, I can see timers whose expiration date has past accumulate, and eventually a timer persistence failure. Is what I'm experiencing another manifestation of the same problem? > BigIntegerTimerIdGenerator may create dupplicate timer IDs after server crash > ----------------------------------------------------------------------------- > > Key: JBAS-3379 > URL: http://jira.jboss.com/jira/browse/JBAS-3379 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB2, EJB3 > Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2 > Reporter: Matthias Germann > Assigned To: Scott M Stark > > The BigIntegerTimerIdGenerator may generate a already existing Timer ID after a server crash. > The problem is that the Timer database may contain some Timers at server startup after a server crash (see JBAS-1091). The BigIntegerTimerIdGenerator does not know of these already existing timers. The first ID after a restart is always zero. Therefore, the BigIntegerTimerIdGenerator will create an already existing Timer ID as soon as the ID of a restored and not yet executed Timer is reached. This will lead to the following exception: > 23:22:19,812 ERROR [TimerServiceImpl] Cannot create txtimer > java.lang.IllegalStateException: Unable to persist timer > at org.jboss.ejb.txtimer.DatabasePersistencePolicy.insertTimer(DatabasePersistencePolicy.java:126) > 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.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 $Proxy22.insertTimer(Unknown Source) > at org.jboss.ejb.txtimer.TimerServiceImpl.createTimer(TimerServiceImpl.java:256) > at org.jboss.ejb.txtimer.TimerServiceImpl.createTimer(TimerServiceImpl.java:171) > at ch.dvbern.bpm.test.ejb.service.scheduler.JbpmSchedulerBean.timeoutHandler(JbpmSchedulerBean.java:103) > 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.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112) > at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166) > at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79) > at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) > at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:124) > at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:524) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > Caused by: java.sql.SQLException: Unique constraint violation: in statement [insert into TIMERS (TIMERID,TARGETID,INITIALDATE,TIMERINTERVAL,INSTANCEPK,INFO) values > (?,?,?,?,?,?)] > at org.hsqldb.jdbc.Util.throwError(Unknown Source) > at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source) > at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:95) > at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251) > at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.insertTimer(GeneralPurposeDatabasePersistencePlugin.java:186) > at org.jboss.ejb.txtimer.DatabasePersistencePolicy.insertTimer(DatabasePersistencePolicy.java:122) > ... 43 more > IMHO, the BigIntegerTimerIdGenerator should be replaced by a GUID algorithm or read the maximum Timer ID from the Database at startup. -- 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, 3 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 January 2007