December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1367) Upgrade MVEL for improvements, fixes and classloader caching fix

by Michael Neale (JIRA)

Upgrade MVEL for improvements, fixes and classloader caching fix ---------------------------------------------------------------- Key: JBRULES-1367 URL: http://jira.jboss.com/jira/browse/JBRULES-1367 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: All Reporter: Michael Neale Assigned To: Michael Neale Fix For: 4.1.0 Not sure if this is needed for 4.0.x, no demand right now, but is needed for trunk -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-869) CLONE -Eliminate delay in MicroSocketClientInvoker.getConnection() (JBREM-860)

by Ron Sigal (JIRA)

CLONE -Eliminate delay in MicroSocketClientInvoker.getConnection() (JBREM-860) ------------------------------------------------------------------------------ Key: JBREM-869 URL: http://jira.jboss.com/jira/browse/JBREM-869 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection() currently calls Thread.sleep(1000) after each unsuccessful attempt to retrieve a connection from the connection pool. This introduced an unnecessary delay in general, and, in particular, makes the use of a connection pool of size one impractical. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-867) CLONE -Verify IPv6 addresses are handled correctly

by Ron Sigal (JIRA)

CLONE -Verify IPv6 addresses are handled correctly -------------------------------------------------- Key: JBREM-867 URL: http://jira.jboss.com/jira/browse/JBREM-867 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 Need to make sure that Remoting can bind ServerSockets to IPv6 addresses. This issue is related to http://jira.jboss.com/jira/browse/JBREM-645. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-521) Rule relationships

by Michael Neale (JIRA)

Rule relationships ------------------ Key: JBRULES-521 URL: http://jira.jboss.com/jira/browse/JBRULES-521 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale Have the ability to have a reference (multiple) from any rule to another rule, purely for informational purposes. -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-5053) Access to a TransactionManager from Database*LoginModule should only be required if suspendResume is true

by Scott M Stark (JIRA)

Access to a TransactionManager from Database*LoginModule should only be required if suspendResume is true --------------------------------------------------------------------------------------------------------- Key: JBAS-5053 URL: http://jira.jboss.com/jira/browse/JBAS-5053 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.Beta3 The suspendResume option to suspend/resume transactions during database operations should control whether access to a TransactionManager is required. Currently if a TransactionManager cannot be obtained an IllegalStateException is thrown regardless of the suspendResume value. -- 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

2
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1839) problem with deployment of clustered portal

by Prabhat Jha (JIRA)

problem with deployment of clustered portal ------------------------------------------- Key: JBPORTAL-1839 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1839 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.3 Final Reporter: Prabhat Jha Assigned To: Thomas Heute Fix For: 2.6.3 Final portal-ha.sar is not geting deployed correctly. I first tried with hypersonic, then with mysql5. Please see the server log at http://reports.qa.atl.jboss.com/reports/portal_perf/server.log.zip --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: portal:service=ApprovePublish,type=Workflow State: FAILED Reason: org.jbpm.JbpmException: couldn't find process definition 'approval_workflow' I Depend On: portal:service=Workflow,type=WorkflowService portal:service=Module,type=IdentityServiceController ObjectName: portal:service=Hibernate,type=Instance State: FAILED Reason: org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >) I Depend On: jboss.jca:service=DataSourceBinding,name=PortalDS portal:service=TreeCacheProvider,type=hibernate Depends On Me: portal:service=InstanceContainerContext ObjectName: portal:service=Hibernate,type=Portlet State: FAILED Reason: org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >) I Depend On: jboss.jca:service=DataSourceBinding,name=PortalDS portal:service=TreeCacheProvider,type=hibernate Depends On Me: portal.wsrp:service=PersistenceManager portal:service=PersistenceManager,type=Producer ObjectName: portal:service=Hibernate,type=PortalObject State: FAILED Reason: org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >) I Depend On: jboss.jca:service=DataSourceBinding,name=PortalDS portal:service=TreeCacheProvider,type=hibernate Depends On Me: portal:container=PortalObject The error I see is : 2007-12-06 13:50:35,740 WARN [org.jboss.system.ServiceController] Problem starting service portal:service=Hibernate,type=Portlet org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a12008d:913e:4758440a:41 status: ActionStatus.ABORT_ONLY >) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94) at org.jboss.portal.jems.hibernate.SessionFactoryBinder.startService(SessionFactoryBinder.java:229) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) at org.jboss.portal.jems.as.system.AbstractJBossService.start(AbstractJBossService.java:73) at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.portal.jems.as.system.JBossServiceModelMBean$ServiceMixin.execute(JBossServiceModelMBean.java:486) -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1184) Durable subscription failover with preconf client ids fails

by Tim Fox (JIRA)

Durable subscription failover with preconf client ids fails ----------------------------------------------------------- Key: JBMESSAGING-1184 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1184 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.SP2 If you try to failover a connection with a preconfigured (either by connection factory or jms user) client id it fails. Also if you fail over a connection with a durable sunscriber onto a node already with another durable subscriber with same id and name it fails. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4009) Add tests to validate mc-bean, jmx-bean property reference usage

by Scott M Stark (JIRA)

Add tests to validate mc-bean, jmx-bean property reference usage ---------------------------------------------------------------- Key: JBAS-4009 URL: http://jira.jboss.com/jira/browse/JBAS-4009 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JMX, MicroContainer bus Reporter: Scott M Stark Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta2 Right now there are some differences in property case that show up as unexpected exceptions when one uses javabean vs jmx attribute naming conventions due to the stricter jmx case sensitivity. We needs tests to cover the range of usecases where mbean attributes are injected into mc bean properties and vice versa. -- 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

3
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1180) Provide failover for Subscriptions

by Jay Howell (JIRA)

Provide failover for Subscriptions ---------------------------------- Key: JBMESSAGING-1180 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1180 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Affects Versions: 1.4.0.SP2 Reporter: Jay Howell Assigned To: Tim Fox We should be able to set a switch in the TopicConnectionFactory that will allow us to configure multiple subscribers with the same clientid. Currently I see no easy way to failover if you have a subscription. Normally in a clustered situation, I would have several servers that would act as failover/loadbalanancing. For the fail over part, I would have MDBs scattered accross my cluster which would give me redundancy. If I have a durable subscriber MDB(with a specified clientid), I can only deploy that mdb on one of the nodes due to the limitations imposed by the spec. The only way to currently do this in jboss would be to deploy the mdb in the hasingleton. Then as the master went down, the mdb would fire up on the secondary. Basically the connection would abruptly end and then another server would try to establish the connection using the same client id. The problem is that we would have to wait for the connection on the serverside to timeout, before the new master could connect. If the failover happens to quickly, we could get an exception that the clientid is already registered. This work around works great for jboss serverside failover, but doesn't do much for external clients. For example, If I have a BEA cluster that wants durable subscription failover using JBM, they would have to come up with a way to host a singleton in their cluster. It would be easier to provide this with JBM. I would propose that we add a switch to the TopicConnectionFactory that relaxes this limitation set by the spec. It would allow multiple subscribers to share the same subscription with the limitation that only one of them will ever get messages. If that one connection goes down, then JBM will start publishing the messages to one of the other subscribers that share that same subscription. I encountered this in another messaging system and it seems like a way to provide better failover outside of the jboss app server. This would also simplify the clustering of durable subscriptions. A user could come up with their mdbs(with client ids defined) and could just copy the deployment to each server in the cluster, without having to take their durable subscriber mdbs and put them in HASingleton. -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1838) WSRP config problem

by Prabhat Jha (JIRA)

WSRP config problem ------------------- Key: JBPORTAL-1838 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1838 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.3 Final Reporter: Prabhat Jha Assigned To: Chris Laprun Fix For: 2.6.3 Final - Login as admin and go to WSRP page - Click configuration page for self consumer - Erase local registration - It stays on the same window and prompts to erase registration again - It should take you back to the configuration page After that , I keep seeing following error in server side: Caused by: org.jboss.portal.wsrp.core.OperationFailedFault at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.newInstance(RtElementHandler.java:1014) at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.startElement(RtElementHandler.java:748) at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.startParticle(RtElementHandler.java:89) at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:593) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:324) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:175) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:126) at org.jboss.ws.core.jaxrpc.binding.jbossxb.JBossXBUnmarshallerImpl.unmarshal(JBossXBUnmarshallerImpl.java:61) at org.jboss.ws.core.jaxrpc.binding.JBossXBDeserializer.deserialize(JBossXBDeserializer.java:103) at org.jboss.ws.core.jaxrpc.binding.JBossXBDeserializer.deserialize(JBossXBDeserializer.java:62) at org.jboss.ws.core.jaxrpc.SOAPFaultHelperJAXRPC.getSOAPFaultException(SOAPFaultHelperJAXRPC.java:147) at org.jboss.ws.core.jaxrpc.SOAP11BindingJAXRPC.throwFaultException(SOAP11BindingJAXRPC.java:68) at org.jboss.ws.core.CommonSOAPBinding.unbindResponseMessage(CommonSOAPBinding.java:553) at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:371) at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:517) at org.jboss.ws.core.jaxrpc.client.CallImpl.invoke(CallImpl.java:277) at org.jboss.ws.core.jaxrpc.client.PortProxy.invoke(PortProxy.java:151) at $Proxy220.register(Unknown Source) at org.jboss.portal.wsrp.consumer.ProducerInfo.register(ProducerInfo.java:786) at org.jboss.portal.wsrp.consumer.ProducerInfo.internalRefresh(ProducerInfo.java:349) at org.jboss.portal.wsrp.consumer.ProducerInfo.detailedRefresh(ProducerInfo.java:254) -- 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

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007