November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Juha Lindfors (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12... ] Juha Lindfors commented on JBMESSAGING-407: ------------------------------------------- And obviously: 5) address the issues commented on the original patch > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Assigned To: Juha Lindfors > Priority: Critical > Fix For: 1.0.2.CR1 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Time Spent: 4 days, 4 hours, 30 minutes > Remaining Estimate: 3 hours, 30 minutes > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- 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: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Juha Lindfors (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12... ] Juha Lindfors commented on JBMESSAGING-407: ------------------------------------------- The original patch with comments has been committed to Branch_1_0_XARecovery. The remaining tasks are: 1) Testing integration of JBossTS and JBMessaging with JBossAS as the integration platform. 2) Testing integration of JBossTS and JBMessaging as stand-alone deployments. 3) Testing JBMessaging (XAResource) failure scenarios and recovery 4) Testing JBMessaging (XAResource) recovery in face of tx coordinator failure I'll create separate JIRA tasks for these so they can be prioritized differently and assigned to appropriate releases (e.g. stand-alone integration and integration via AS may not be necessary for same release). > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Assigned To: Juha Lindfors > Priority: Critical > Fix For: 1.0.2.CR1 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Time Spent: 4 days, 3 hours, 30 minutes > Remaining Estimate: 4 hours, 30 minutes > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- 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: (JBRULES-565) String contraints not working

by Marcos Tengelmann (JIRA)

String contraints not working ------------------------------ Key: JBRULES-565 URL: http://jira.jboss.com/jira/browse/JBRULES-565 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.5 Environment: Java5, in Linux and Windows Reporter: Marcos Tengelmann Assigned To: Mark Proctor With These classes Public Class Account { public String getAccountState() {...} } Public Class Receipt { public String getReceiptState() {...} } RULE "DIFFERENT STATES" When Account($aState : accountState) Receipt($rState : receiptState != $aState) Then System.out.println("AccountState:[" + $aState + "]"); System.out.println("ReceiptState:[" + $rState + "]"); End The results are: AccountState:[SP] ReceiptState:[SP] AccountState:[RJ] ReceiptState:[RJ] ....and so on... This means the receiptState != $aState is NOT working as expected, returning TRUE always, regardless of the values of the fields (In the example they are NOT equal) Additionally if I try with receiptState == $aState, the results are exactly the same for receiptState != $aState. Which makes me suspect of some problems in Node Sharing not taking the operator into consideration. -- 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] Created: (JBESB-208) Add an EPR configuration wizard to the Admin console

by Tom Fennelly (JIRA)

Add an EPR configuration wizard to the Admin console ---------------------------------------------------- Key: JBESB-208 URL: http://jira.jboss.com/jira/browse/JBESB-208 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0 Reporter: Tom Fennelly Assigned To: Tom Fennelly Fix For: 4.0 A wizard for configuring and searching EPRs. This may be a view on top of the Registry??? -- 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
7
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1082) Unable to edit properties of portlet instances that ship with Portal

by Peter Johnson (JIRA)

Unable to edit properties of portlet instances that ship with Portal -------------------------------------------------------------------- Key: JBPORTAL-1082 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1082 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.4 Final Environment: Windows XP, MySQL 5.0 & PostgreSQL 8.1., JBossAS 4.0.4GA Reporter: Peter Johnson Assigned To: Julien Viet Fix For: 2.4.1 Final, 2.6.Alpha1 Back in 2.4.0CR3, I was able to create a new instance of the CMSPortlet and set the indexPage preference to some other html page. With 2.4.0GA, and what I loaded from CVS this morning, I can no longer do this. Instead, when I click the Update button after entering in the new html page name, such as /deafult/project.html, I get a huge stack trace. I cannot change the preferences on any of the portlets that ship with the portal. Even if I create new instances. I tried changing a preference for the weather portlet and got the same error. In 2.4.0.CR3, the compoundPortletId for the CMS portlet was local._1 and for the weather portlet was local._9. In 2.4.0.GA, the componentPortletIds are local.portal.CMSPortlet and local.samples.WeatherPortlet. The StatefulPortletInvoker.setProperties method throws an exception if the simple portletId does not start with an underscore. -- 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
4
0 / 0

[JBoss JIRA] Created: (HIBERNATE-49) No way to specify CACHE_PROVIDER_CONFIG in HibernateMBean

by Amit Bhayani (JIRA)

No way to specify CACHE_PROVIDER_CONFIG in HibernateMBean --------------------------------------------------------- Key: HIBERNATE-49 URL: http://jira.jboss.com/jira/browse/HIBERNATE-49 Project: Hibernate Issue Type: Feature Request Reporter: Amit Bhayani Assigned To: Steve Ebersole HibernateMBean doesn't have any attribute to specify hibernate.cache.provider_configuration_file_resource_path. For example if user makes use of EhCache, he/she has to fall back on default implementation of EhCache to find ehcache.xml file. Look at Hibernate JIRA http://opensource.atlassian.com/projects/hibernate/browse/HHH-2246 -- 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 Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3198?page=all ] Dimitris Andreadis updated JBAS-3198: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 JBossAS-4.2.0.CR1 JBossAS-4.0.5.SP1 Priority: Critical (was: Major) Raising the priority to fix it in the 4.0.x branch for 4.0.5.SP1. Should it be fixed in 4.2.x and 5.0.x, too. > 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 > > > 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] Updated: (BPEL-193) template for new projects

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/BPEL-193?page=all ] Alejandro Guizar updated BPEL-193: ---------------------------------- Fix Version/s: jBPM BPEL 1.1.1 (was: jBPM BPEL 1.1) > template for new projects > ------------------------- > > Key: BPEL-193 > URL: http://jira.jboss.com/jira/browse/BPEL-193 > Project: JBoss jBPM BPEL > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documents > Reporter: Alejandro Guizar > Assigned To: Alejandro Guizar > Fix For: jBPM BPEL 1.1.1 > > > Burr Sutter wrote: > "I was only hoping for an easy way to build, modify and redeploy HelloWorld or ATM with the least amount of effort. Something like > 1. Edit BPEL file > 2. Deploy > 3. In the browser view the WSDL > Having Ant tasks that make it this easy and a template project and build script for getting started would be great for the first release of our BPEL engine." -- 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: (BPEL-85) Docu on the purpose of BPEL

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/BPEL-85?page=all ] Alejandro Guizar updated BPEL-85: --------------------------------- Fix Version/s: jBPM BPEL 1.1.1 (was: jBPM BPEL 1.1) > Docu on the purpose of BPEL > --------------------------- > > Key: BPEL-85 > URL: http://jira.jboss.com/jira/browse/BPEL-85 > Project: JBoss jBPM BPEL > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documents > Affects Versions: jBPM BPEL 1.0 alpha 4 > Reporter: Thomas Diesler > Assigned To: Alejandro Guizar > Fix For: jBPM BPEL 1.1.1 > > > Please expand the user documentation to a section about the purpose of BPEL. It should show a not so trivial use case that illustrates (with pictures) why I should care about BPEL -- 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: (BPEL-85) Docu on the purpose of BPEL

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/BPEL-85?page=all ] Alejandro Guizar updated BPEL-85: --------------------------------- Comment: was deleted > Docu on the purpose of BPEL > --------------------------- > > Key: BPEL-85 > URL: http://jira.jboss.com/jira/browse/BPEL-85 > Project: JBoss jBPM BPEL > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documents > Affects Versions: jBPM BPEL 1.0 alpha 4 > Reporter: Thomas Diesler > Assigned To: Alejandro Guizar > Fix For: jBPM BPEL 1.1 > > > Please expand the user documentation to a section about the purpose of BPEL. It should show a not so trivial use case that illustrates (with pictures) why I should care about BPEL -- 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