November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-642) Maintaining ackMode per individual acknowledment instance is unnecessary

by Ovidiu Feodorov (JIRA)

Maintaining ackMode per individual acknowledment instance is unnecessary ------------------------------------------------------------------------ Key: JBMESSAGING-642 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-642 Project: JBoss Messaging Issue Type: Task Components: JMS Facade Affects Versions: 1.0.1.GA Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 1.2.1 When sending acknowledment on close, the ackMode can be obtained from session directly (it doen't varies among individual acknowledgments). Maintaining this information per individual acknowledgment is unnecessary and wasteful. -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-769) exception in destroy method results in "javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean"

by Gavin King (JIRA)

exception in destroy method results in "javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean" --------------------------------------------------------------------------------------------------------- Key: EJBTHREE-769 URL: http://jira.jboss.com/jira/browse/EJBTHREE-769 Project: EJB 3.0 Issue Type: Bug Reporter: Gavin King This affects JBoss 4.0.5. When a system exception occurs in a @Destroy method of a SFSB, the bean gets removed (because of the @Destroy annotation), then the container tries to remove it a second time (because of the exception), and this results in the swallowing of the original exception, with an EJBNoSuchObjectException taking its place. Solution: the interceptor that handles the @Destroy annotation should not try to remove the SFSB when the destroy method throws an exception. -- 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, 8 months

3
4
0 / 0

[JBoss JIRA] Updated: (JBAS-62) JMX work for JBoss-5.0.0.Beta

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-62?page=all ] Scott M Stark updated JBAS-62: ------------------------------ Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) > JMX work for JBoss-5.0.0.Beta > ----------------------------- > > Key: JBAS-62 > URL: http://jira.jboss.com/jira/browse/JBAS-62 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Adrian Brock > Priority: Blocker > Fix For: JBossAS-5.0.0.Beta2 > > > Schedule -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3170) ProfileService Bootstrapping of the MC

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3170?page=all ] Scott M Stark updated JBAS-3170: -------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) > ProfileService Bootstrapping of the MC > -------------------------------------- > > Key: JBAS-3170 > URL: http://jira.jboss.com/jira/browse/JBAS-3170 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: MicroContainer bus > Reporter: Scott M Stark > Assigned To: Scott M Stark > Priority: Blocker > Fix For: JBossAS-5.0.0.Beta2 > > > Tasks for bootstrapping the mc using the profile service. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-63) MicroContainer work for JBoss-5.0.0.Beta

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-63?page=all ] Scott M Stark updated JBAS-63: ------------------------------ Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) > MicroContainer work for JBoss-5.0.0.Beta > ---------------------------------------- > > Key: JBAS-63 > URL: http://jira.jboss.com/jira/browse/JBAS-63 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: MicroContainer bus > Reporter: Adrian Brock > Priority: Blocker > Fix For: JBossAS-5.0.0.Beta2 > > > Schedule -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3413) Port WARDeployer and complete JavaEE5 support

by Scott M Stark (JIRA)

Port WARDeployer and complete JavaEE5 support --------------------------------------------- Key: JBAS-3413 URL: http://jira.jboss.com/jira/browse/JBAS-3413 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Deployment services, Web (Tomcat) service Reporter: Scott M Stark Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta The WARDeployer needs to be ported to the new VDF and the JavaEE 5 changes completed -- 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, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-618) Support CallbackPoller configuration.

by Ron Sigal (JIRA)

Support CallbackPoller configuration. ------------------------------------- Key: JBREM-618 URL: http://jira.jboss.com/jira/browse/JBREM-618 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) JBREM-617 suggests CallbackPoller needs its own time thread. It can be scheduled by Timer.scheduleAtFixedRate() or Timer.schedule(). This choice could be made available to the application. Also, it would be useful to log the number of callbacks arriving at each polling round, the number of callbacks waiting to be processed, and the number of callbacks waiting to be acknowledged. These statistics could help an application determine an appropriate polling frequency. -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] Commented: (JBPM-165) process instance versioning

by Syed Arshad (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-165?page=comments#action_12347277 ] Syed Arshad commented on JBPM-165: ---------------------------------- Thanks for changing the priority of this item, we are looking forward for the release of this feature ASAP. Also, in case there is no immediate plan to release this feature, probably I can start some work on this as discussed in the forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=74618&postdays=0... where you also commented about a possible implementation. If this is fine, I can send you design spec about this implementation and if it is convincing to you then I can go and implement? > process instance versioning > --------------------------- > > Key: JBPM-165 > URL: http://jira.jboss.com/jira/browse/JBPM-165 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > > i think jbpm could offer some degree of assistence in process instance versioning. > when a new version of a process is deployed, jbpm could do the following conversion for a process instance : > * input required: mapping of the nodes from the old to the new definition. > * cancel the old process instance > * create a new process instance and copy the runtime (exe) information such as tokens and process variables from the old process instance. > * then establish a special link between the 2 process instances to indicate that the new process instance is the continuation of the old process instance. > this way we can avoid the problematic conversion of logs, while still keeping them in the system. -- 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, 8 months

1
0
0 / 0

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

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3198?page=all ] Adrian Brock updated JBAS-3198: ------------------------------- Affects Version/s: JBossAS-4.0.5.CR1 (was: JBossAS-4.0.3 SP1) > 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 > > 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

19 years, 8 months

1
0
0 / 0

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

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3198?page=comments#action_12347276 ] Adrian Brock commented on JBAS-3198: ------------------------------------ The above analysis is incorrect. The comment in the pooled invoker just says that something else sets the classloader, which is true, it is set during this method in the above stacktrace: at org.jboss.ejb.Container.invoke(Container.java:873) Since this is a remote invocation, the unmarshalling is done lazily i.e. when somebody invokes PooledMarshalledInvocation.getArguments() public Object[] getArguments() { if (this.args == null) { try { this.args = (Object[]) pooledMarshalledArgs.get(); } catch (Exception e) { e.printStackTrace(); } } return args; } The most obvious problem is that this shares the same bug as JBAS-1911 i.e. the problem is that the arguments could not be unmarshalled due to missing classes, but instead of throwing an error, it is eating the error and returning an empty array. It is also not clear to me why this PooledMarshalledInvocation overrides this and other methods anyway? For the return type, the PooledInvoker is missing the code that wraps the result in a MarshalledObject, i.e. // The cl on the thread should be set in another interceptor Object obj = serverAction.invoke(mbean, "invoke", new Object[] { invocation }, Invocation.INVOKE_SIGNATURE); - return obj; + return new MarshalledObject(obj); Compare with the JRMP invoker. > 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.3 SP1 > Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5 > Reporter: Eric Hambuch > Assigned To: Scott M Stark > > 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

19 years, 8 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 November 2006