July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JGRP-236) Combine join and state transfer

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-236?page=all ] Bela Ban updated JGRP-236: -------------------------- Fix Version/s: 2.5 (was: 2.4) > Combine join and state transfer > ------------------------------- > > Key: JGRP-236 > URL: http://jira.jboss.com/jira/browse/JGRP-236 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9.2, 2.2.9.1, 2.2.8, 2.2.9, 2.3 > Reporter: Bela Ban > Assigned To: Vladimir Blagojevic > Priority: Critical > Fix For: 2.5 > > > Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase. > The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener. > - The JOIN_REQ contains the boolean > - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending > the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK), > we send it back to the joining member(s), and the RESUME sending messages -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-178) Run TCK continuously in top of JBoss Messaging

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-178?page=comments#action_12... ] Ovidiu Feodorov commented on JBMESSAGING-178: --------------------------------------------- A framework needs to be put in place to run TCK continuously and automatically > Run TCK continuously in top of JBoss Messaging > ---------------------------------------------- > > Key: JBMESSAGING-178 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-178 > Project: JBoss Messaging > Issue Type: Task > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.0.2 > > -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-668) IllegalArgumentException during deserialization

by Felix Mayer (JIRA)

IllegalArgumentException during deserialization ----------------------------------------------- Key: EJBTHREE-668 URL: http://jira.jboss.com/jira/browse/EJBTHREE-668 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Environment: Windows XP SP2, JDK 1.5.0_06, JBoss 4.0.4.GA-Patch1 Reporter: Felix Mayer Under specific circumstances I get the exception below when making a call to an EJB3 stateless session bean. I debugged JBoss and found that the object passed to java.lang.reflect.Method.invoke() was not of the correct class; the method is readResolve(). The circumstances are as follows: - The bean's remote interface must be looked up from inside of the JBoss EJB container. If we use the local interface inside of the container or the remote interface from outside, everything is fine. - The deserialized graph must contain a org.geotools.referencing.crs.DefaultProjectedCRS, which contains a bunch of other Geotools objects. This behavior is reproducible 100% of the time. If necessary, I should be able to provide a standalone test case, but since this requires the Geotools libraries I have not done it right away. java.lang.IllegalArgumentException: object is not an instance of declaring class 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.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:426) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841) at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353) at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273) at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841) at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353) at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273) at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841) at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353) at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273) at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841) at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353) at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273) at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841) at org.jboss.serial.io.MarshalledObjectForLocalCalls.get(MarshalledObjectForLocalCalls.java:60) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) at $Proxy150.createCoordinateReferenceSystem(Unknown Source) at com.lggi.esp.services.ejb.spatial.core.coordinatesystem.CoordinateSystemWorker.createCoordinateReferenceSystem_aroundBody10(CoordinateSystemWorker.java:120) at com.lggi.esp.services.ejb.spatial.core.coordinatesystem.CoordinateSystemWorker$AjcClosure11.run(CoordinateSystemWorker.java:1) at org.aspectj.runtime.reflect.JoinPointImpl.proceed(JoinPointImpl.java:101) at com.lggi.esp.services.aspects.security.SecurityAspect.aroundSecuredMethods(SecurityAspect.aj:104) at com.lggi.esp.services.ejb.spatial.core.coordinatesystem.CoordinateSystemWorker.createCoordinateReferenceSystem(CoordinateSystemWorker.java:1) at com.lggi.esp.services.ejb.spatial.core.coordinatesystem.CoordinateSystemBean.createCoordinateReferenceSystem(CoordinateSystemBean.java:94) 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.invocation.Invocation.performCall(Invocation.java:359) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169) at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:64) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136) at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648) at org.jboss.ejb.Container.invoke(Container.java:954) at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) 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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420) at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:595) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3421) AcceptNonWarDirs attribute of AbstractWebContainerMBean not exposed for .war deployer

by Dimitris Andreadis (JIRA)

AcceptNonWarDirs attribute of AbstractWebContainerMBean not exposed for .war deployer ------------------------------------------------------------------------------------- Key: JBAS-3421 URL: http://jira.jboss.com/jira/browse/JBAS-3421 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.4.GA Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 When the .war deployer was xmbean-ized the AcceptNonWarDirs attribute of AbstractWebContainerMBean was dropped, so re-instantiate it in the xmbean descriptor. -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBAS-3101) Javassist only client side dependencies for proxy frameworks

by Fernando Lozano (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3101?page=comments#action_12340266 ] Fernando Lozano commented on JBAS-3101: --------------------------------------- And if I need to continue using cglib, how can this be configured with jboss 4.0.4? > Javassist only client side dependencies for proxy frameworks > ------------------------------------------------------------ > > Key: JBAS-3101 > URL: http://jira.jboss.com/jira/browse/JBAS-3101 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web Services, Build System, Hibernate service > Affects Versions: JBossAS-4.0.4.CR2 > Reporter: Scott M Stark > Priority: Critical > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.4.GA > > > With client side proxy factory dependencies showing up, we need to restrict this to a single framework. javassit is the most widely used in terms of overall dependencies, so it should be the default proxy factory framework as well. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBESB-31) Create programmers guide

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-31?page=all ] Mark Little updated JBESB-31: ----------------------------- Summary: Create programmers guide (was: Create development guide) > Create programmers guide > ------------------------ > > Key: JBESB-31 > URL: http://jira.jboss.com/jira/browse/JBESB-31 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: ESB Core, Documentation > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.0 Beta 1 > > Time Spent: 6 hours > Remaining Estimate: 0 minutes > > Document how developers can checkout, build and develop plugins/enhancements/etc to JBossESB. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBESB-37) Architecture and code diagrams

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-37?page=all ] Mark Little reassigned JBESB-37: -------------------------------- Assignee: Mark Little (was: Esteban Schifman) > Architecture and code diagrams > ------------------------------ > > Key: JBESB-37 > URL: http://jira.jboss.com/jira/browse/JBESB-37 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.0 Beta 1 > > Time Spent: 2 days > Remaining Estimate: 0 minutes > > For the rebadged Rosetta ESB codebase. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBIDE-305) -service.xml editor (extends WTP XML editor)

by Max Andersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBIDE-305?page=comments#action_12340251 ] Max Andersen commented on JBIDE-305: ------------------------------------ what about mircocontainer files ? > -service.xml editor (extends WTP XML editor) > -------------------------------------------- > > Key: JBIDE-305 > URL: http://jira.jboss.com/jira/browse/JBIDE-305 > Project: JBoss IDE > Issue Type: Feature Request > Components: JBossAS Adapter > Reporter: Marshall Culpepper > Assigned To: Robert Stryker > Fix For: 2.0.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > A custom xxx-service.xml editor that includes: > - auto completion of properties names of mbeans > - ctrl-click navigation to reference mbean classes > - ctrl-click navigation to reference required mbeans -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-21) Add stress tests

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-21?page=comments#action_12340250 ] Tom Elrod commented on JBREM-21: --------------------------------- Now two ant targets for stress tests: tests.stress - just jboss transports tests.stress.all - all transports including jboss and raw > Add stress tests > ---------------- > > Key: JBREM-21 > URL: http://jira.jboss.com/jira/browse/JBREM-21 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.0.1 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.0.0.CR1 (Boon) > > > stress test based on the performance test > that sets the # of threads and calls in PerformanceTest to a very high > number -- 200 client threads and 10000 call iterations for example. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-686) PojoCache handling undo of Collection classes properly

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-686?page=all ] Ben Wang resolved JBCACHE-686. ------------------------------ Resolution: Done Finished with TxUndoInterceptor that has specific method to undo Collection field replacement. > PojoCache handling undo of Collection classes properly > ------------------------------------------------------ > > Key: JBCACHE-686 > URL: http://jira.jboss.com/jira/browse/JBCACHE-686 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: POJOCache > > > Currently in 2.0, the undo is completed for regular attach. But for attachment involving the Collection classes, nothing has been done yet. Mostly, we need to handle the CollectionInterceptor.attach and detach. We will wait until the interal refactoring is completed first. -- 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, 10 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 July 2006