January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-715) FailoverTest.testFailoverMessageOnServer() fails with "Cannot find delivery to acknowledge" after failover

by Ovidiu Feodorov (JIRA)

FailoverTest.testFailoverMessageOnServer() fails with "Cannot find delivery to acknowledge" after failover ---------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-715 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-715 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Tim Fox Fix For: 1.2.0.Beta2 -- 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

17 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBJMX-101) failed to redeploy MBean dependent web module

by Maxim Gordienko (JIRA)

failed to redeploy MBean dependent web module --------------------------------------------- Key: JBJMX-101 URL: http://jira.jboss.com/jira/browse/JBJMX-101 Project: JBoss JMX Issue Type: Bug Affects Versions: JBossAS-4.0.0 Environment: JBossAS 4.0.4.GA Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) Reporter: Maxim Gordienko Environment: Sar module containing MBean content of META-INF/jboss-service.xml --- CUT --- <?xml version="1.0" encoding="UTF-8"?> <server> <mbean code="dot.com.DummyKPBossService" name="dot.com:service=DummyService"> </mbean> </server> --- END CUT --- War module dependant on MBean from Sar content of WEB-INF/jboss-web.xml --- CUT --- <?xml version="1.0" encoding="UTF-8"?> <jboss-web> <depends>dot.com:service=DummyService"</depends> </jboss-web> --- END CUT --- upon redeployment Sar module JBoss tries to redeploy War module but fail with NPE: java.lang.NullPointerException at org.jboss.web.WebModule.startModule(WebModule.java:82) at org.jboss.web.WebModule.startService(WebModule.java:61) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) 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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) ....... -- 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

17 years, 4 months

4
3
0 / 0

[JBoss JIRA] Created: (JBESB-320) Initial deployment of the sar reports an NPE on the console

by Kevin Conner (JIRA)

Initial deployment of the sar reports an NPE on the console ----------------------------------------------------------- Key: JBESB-320 URL: http://jira.jboss.com/jira/browse/JBESB-320 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 RC1 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.0 Initial deployment of the sar raises an NPE in the Generator.getListeners(boolean) method. The initial service list is null but this is not handled by the code. -- 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

17 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-319) Deferred processing of configuration may cause errors on sar deployment

by Kevin Conner (JIRA)

Deferred processing of configuration may cause errors on sar deployment ----------------------------------------------------------------------- Key: JBESB-319 URL: http://jira.jboss.com/jira/browse/JBESB-319 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.0 RC1 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.0 The initial processing of the configuration file by ConfigurationController is deferred to the worker thread. This leaves a window of opportunity whereby the listener processor may be completed prior to the generation of any new configuration files. If this happens prior to the gateway listener executing then the gateway deployment will fail because of missing services. The first execution of the ConfigurationController should be synchronous. -- 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

17 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3966) Add a VersionNumber attribute on the jboss.system:type=Server mbean

by Dimitris Andreadis (JIRA)

Add a VersionNumber attribute on the jboss.system:type=Server mbean -------------------------------------------------------------------- Key: JBAS-3966 URL: http://jira.jboss.com/jira/browse/JBAS-3966 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Priority: Minor The Version attribute of the jboss.system:type=Server mbean returns build information. Create a new VersionNumber attribute to return only the jboss version (e.g. 5.0.0.GA). It can be used to enable/disable parts of our testsuite depending on the target environment. -- 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

17 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-708) Move SessionState.handleFailoverOnConsumer() consumer failover logic to ClientConsumerDelegate/ConsumerState

by Ovidiu Feodorov (JIRA)

Move SessionState.handleFailoverOnConsumer() consumer failover logic to ClientConsumerDelegate/ConsumerState ------------------------------------------------------------------------------------------------------------ Key: JBMESSAGING-708 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-708 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta2 Remove consumer failover logic from SessionState.handleFailoverOnConsumer() and put it into ClientConsumerDelegate/ConsumerState synchronizeWith(), following the pattern established for connection and session. -- 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

17 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-709) Move SessionState.handleFailoverOnProducer() producer failover logic to ClientProducerDelegate/ProducerState

by Ovidiu Feodorov (JIRA)

Move SessionState.handleFailoverOnProducer() producer failover logic to ClientProducerDelegate/ProducerState ------------------------------------------------------------------------------------------------------------ Key: JBMESSAGING-709 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-709 Project: JBoss Messaging Issue Type: Sub-task Components: JMS Clustering Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta2 Remove producer failover logic from SessionState.handleFailoverOnProducer() and put it into ClientProducerDelegate/ProducerState synchronizeWith(), following the pattern established for connection and session. Add step-by-step tests. -- 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

17 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAOP-337) Make it easier to run tests in eclipse

by Kabir Khan (JIRA)

Make it easier to run tests in eclipse -------------------------------------- Key: JBAOP-337 URL: http://jira.jboss.com/jira/browse/JBAOP-337 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan -- 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

17 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3965) JaasSecurityDomainMBean is missing JaasSecurityDomain attributes

by Scott M Stark (JIRA)

JaasSecurityDomainMBean is missing JaasSecurityDomain attributes ---------------------------------------------------------------- Key: JBAS-3965 URL: http://jira.jboss.com/jira/browse/JBAS-3965 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.5.GA Reporter: Scott M Stark Assigned To: Scott M Stark Attachments: JaasSecurityDomain-xmbean.xml The CipherAlgorithm attribute is missing from the JaasSecurityDomainMBean interface. -- 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

17 years, 4 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3198?page=comments#action_12349546 ] Tom Elrod commented on JBAS-3198: ---------------------------------- Fix for /server/src/main/org/jboss/invocation/pooled/interfaces/OptimizedObjectInputStream.java as well as additions to testsuite (see JBAS-3863) have been added to following code branches: https://svn.jboss.org/repos/jbossas/branches/Branch_4_0 https://svn.jboss.org/repos/jbossas/branches/Branch_4_2 https://svn.jboss.org/repos/jbossas/trunk > Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA). > ----------------------------------------------------------------------------------- > > Key: JBAS-3198 > URL: http://jira.jboss.com/jira/browse/JBAS-3198 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ClassLoading > Affects Versions: JBossAS-4.0.5.CR1 > Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5 > Reporter: Eric Hambuch > Assigned To: Tom Elrod > Priority: Critical > Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1 > > Attachments: example.zip > > > When using the pooled invoker (PooledInvokerHA) in the "all" configuration with separated classloaders for each EAR (as described in Wiki:ClassLoadingConfiguration) an invocation to a bean causes confusion to the separated classloaders. > More detailed: > I switched from jrmpha-invoker (which creates a new thread for each request which is really bad) to pooledha invoker in a clustered environment. I have to Stateless Session Beans that share the same bean interface. Each Session Bean is deployed in a separate EAR. In "ear-deployer.xml" I switched "isolated" to "true" to separate the classloaders of the EARs. > When I call the first bean everything works fine. But when I try to call the second bean (same interface, but different bean!) JBoss throws the following exception: > java.rmi.ServerException: RuntimeException; nested exception is: > java.lang.IllegalArgumentException: argument type mismatch > at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:386) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196) > at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:264) > at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) > at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) > at org.jboss.ejb.Container.invoke(Container.java:873) > 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:324) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.invocation.pooled.server.PooledInvokerHA.invoke(PooledInvokerHA.java:146) > at org.jboss.invocation.pooled.server.ServerThread.processInvocation(ServerThread.java:213) > at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:268) > at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:139) > Caused by: java.lang.IllegalArgumentException: argument type mismatch > 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:324) > at org.jboss.invocation.Invocation.performCall(Invocation.java:345) > at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) > at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149) > at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) > at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106) > at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:158) > at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62) > at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154) > at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) > The IllegalArgumentException comes from the fact that the Method.invoke() is called with a class of the wrong classloader (class from other EAR). > With jrmpha-invoker everything works fine. Maybe the thread pool causes a mixture of the classloaders? > I created a minimized example that can be provided if required. -- 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

17 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2007