December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-552) Outline problems in DRL editor

by Dirk Bergstrom (JIRA)

Outline problems in DRL editor ------------------------------ Key: JBRULES-552 URL: http://jira.jboss.com/jira/browse/JBRULES-552 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.4 Reporter: Dirk Bergstrom Assigned To: Mark Proctor Priority: Minor Two (possibly related) problems with the outline view in the DRL editor: *) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline. *) Clicking on the name of a rule highlights some text near that rule. I assume it's supposed to highight the title of the rule, but it misses. Same thing affects the imports. -- 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

13 years, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1137) ClusterChooserInterceptor does not support transaction failover authorisations

by Galder Zamarreno (JIRA)

ClusterChooserInterceptor does not support transaction failover authorisations ------------------------------------------------------------------------------ Key: EJBTHREE-1137 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1137 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.2.GA, AS 5.0.0.Beta3 Reporter: Galder Zamarreno org.jboss.aspects.remoting.ClusterChooserInterceptor does not contain logic to deal with transaction failover authorisations, contrary to legacy JRMP invoker or Unified invoker. The reason I'm entering this as a bug rather than as a feature request is because not having such logic is allowing failovers when they shouldn't happen. -- 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

13 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1141) LoadBalancePolicy that tries to pin all requests associated with a tx to one server

by Galder Zamarreno (JIRA)

LoadBalancePolicy that tries to pin all requests associated with a tx to one server ----------------------------------------------------------------------------------- Key: EJBTHREE-1141 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1141 Project: EJB 3.0 Issue Type: Feature Request Components: Clustering Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Create EJB3 transaction sticky load balance policies. -- 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

13 years, 4 months

4
3
0 / 0

[JBoss JIRA] Created: (JBAS-4514) CLONE -Deadlock when logging trace

by chris effenberger (JIRA)

CLONE -Deadlock when logging trace ---------------------------------- Key: JBAS-4514 URL: http://jira.jboss.com/jira/browse/JBAS-4514 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: chris effenberger Assigned To: Scott M Stark SourceForge Submitter: genman . This was caused when trace was enabled. I imagine it was caused by the classloader trying to load a class while it was being rendered (?) to disk. Probably not a big issue, unless trace-logging is enabled. Java stack information for the threads listed above: =================================================== "SMPP-TIMER-0": at com.logica.smpp.util.ByteBuffer.getHexDump(ByteBuffer.java:379) at com.logica.smpp.util.ByteBuffer.toString(ByteBuffer.java:387) at org.apache.log4j.or.DefaultRenderer.doRender(DefaultRenderer.java:26) at org.apache.log4j.or.RendererMap.findAndRender(RendererMap.java:70) at org.apache.log4j.spi.LoggingEvent.getRenderedMessage(LoggingEvent.java:288) at org.apache.log4j.helpers.PatternParser$BasicPatternConverter.convert(PatternParser.java:395) at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:56) at org.apache.log4j.PatternLayout.format(PatternLayout.java:495) at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:292) at org.apache.log4j.WriterAppender.append(WriterAppender.java:150) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221) - locked <0x473874c8> (a org.apache.log4j.ConsoleAppender) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57) at org.apache.log4j.Category.callAppenders(Category.java:187) - locked <0x46829180> (a org.apache.log4j.spi.RootCategory) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.debug(Category.java:241) at com.logica.smpp.debug.Log4JDebug.write(Log4JDebug.java:79) at com.logica.smpp.TCPIPConnection.send(TCPIPConnection.java:301) at com.logica.smpp.Transmitter.send(Transmitter.java:81) at com.logica.smpp.Session.send(Session.java:983) at com.logica.smpp.Session.bind(Session.java:452) at ... "SMSC-Accept-16910": at org.apache.log4j.Category.callAppenders(Category.java:185) - waiting to lock <0x46829180> (a org.apache.log4j.spi.RootCategory) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.log(Category.java:864) at org.jboss.logging.Log4jLoggerPlugin.trace(Log4jLoggerPlugin.java:96) at org.jboss.logging.Logger.trace(Logger.java:113) at org.jboss.mx.loading.UnifiedClassLoader3.attempt(UnifiedClassLoader3.java:242) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:126) - locked <0x472e2f38> (a org.jboss.mx.loading.UnifiedClassLoader3) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked <0x472e2f38> (a org.jboss.mx.loading.UnifiedClassLoader3) at com.proteusmobile.smsgw.server.ServerService.listen(ServerService.java:187) at com.proteusmobile.smsgw.server.ServerService.access$3(ServerService.java:46) at com.proteusmobile.smsgw.server.ServerService$Listener.run0(ServerService.java:163) at com.proteusmobile.smsgw.server.ServerService$Listener.run(ServerService.java:154) at java.lang.Thread.run(Thread.java:536) Found 1 deadlock. -- 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

13 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1037) JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)

by Mariusz Olejnik (JIRA)

JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint) ---------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1037 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037 Project: JBoss Messaging Issue Type: Patch Components: Messaging Core Persistence Affects Versions: 1.4.0.CR1 Environment: Windows XP / Oracle 10g Reporter: Mariusz Olejnik Assigned To: Tim Fox Priority: Critical Fix For: 1.4.0.CR1 Reference should be inserted after message because: oracle-persistence-service.xml CREATE TABLE JBM_MSG_REF ( CHANNEL_ID INTEGER, MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) [...] -- 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

13 years, 4 months

5
5
0 / 0

[JBoss JIRA] Created: (JBFORUMS-122) Links should be recognized

by Thomas Diesler (JIRA)

Links should be recognized -------------------------- Key: JBFORUMS-122 URL: http://jira.jboss.com/jira/browse/JBFORUMS-122 Project: JBoss Forums Issue Type: Feature Request Components: Forum Enhancements Reporter: Thomas Diesler Assigned To: Sohil Shah Instead of [url]http://jira.jboss.com/jira/secure/CreateIssue.jspa[/url] I like to simply use http://jira.jboss.com/jira/secure/CreateIssue.jspa There are a lot of user provided links that I cannot click on. -- 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

13 years, 5 months

4
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1152) service-ref in ejb-jar.xml is ignored

by Thomas Diesler (JIRA)

service-ref in ejb-jar.xml is ignored ------------------------------------- Key: EJBTHREE-1152 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1152 Project: EJB 3.0 Issue Type: Bug Reporter: Thomas Diesler Fix For: AS 5.0.0.Beta3 [tdiesler@tddell trunk]$ ant -Dtest=org.jboss.test.ws.jaxws.samples.serviceref.ServiceRefEJBTestCase one-test one-test: [junit] Running org.jboss.test.ws.jaxws.samples.serviceref.ServiceRefEJBTestCase [junit] Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 8.761 sec [junit] Test org.jboss.test.ws.jaxws.samples.serviceref.ServiceRefEJBTestCase FAILED Caused by: javax.naming.NameNotFoundException: service1 not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:542) at org.jnp.server.NamingServer.getBinding(NamingServer.java:550) at org.jnp.server.NamingServer.getObject(NamingServer.java:556) at org.jnp.server.NamingServer.lookup(NamingServer.java:296) at org.jnp.server.NamingServer.lookup(NamingServer.java:270) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:776) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.jboss.test.ws.jaxws.samples.serviceref.EJBClient.echo(EJBClient.java:52) <ejb-jar version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"> <enterprise-beans> <session> <ejb-name>EJBClient</ejb-name> <remote>org.jboss.test.ws.jaxws.samples.serviceref.EJBRemote</remote> <ejb-class>org.jboss.test.ws.jaxws.samples.serviceref.EJBClient</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <service-ref> <service-ref-name>service1</service-ref-name> <service-interface>javax.xml.ws.Service</service-interface> <wsdl-file>META-INF/wsdl/TestEndpoint.wsdl</wsdl-file> <service-qname xmlns:ns1="http://serviceref.samples.jaxws.ws.test.jboss.org/">ns1:TestEndpointService</service-qname> </service-ref> <service-ref> <service-ref-name>service2</service-ref-name> <service-interface>org.jboss.test.ws.jaxws.samples.serviceref.TestEndpointService</service-interface> <wsdl-file>META-INF/wsdl/TestEndpoint.wsdl</wsdl-file> <service-qname xmlns:ns1="http://serviceref.samples.jaxws.ws.test.jboss.org/">ns1:TestEndpointService</service-qname> <port-component-ref> <service-endpoint-interface>org.jboss.test.ws.jaxws.samples.serviceref.TestEndpoint</service-endpoint-interface> <enable-mtom>true</enable-mtom> </port-component-ref> </service-ref> </session> </enterprise-beans> </ejb-jar> -- 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

13 years, 5 months

4
13
0 / 0

[JBoss JIRA] Created: (JGRP-619) Change getState semantics

by Vladimir Blagojevic (JIRA)

Change getState semantics ------------------------- Key: JGRP-619 URL: http://jira.jboss.com/jira/browse/JGRP-619 Project: JGroups Issue Type: Task Affects Versions: 2.5, 2.4, 2.3, 2.2.9 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 3.0 Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer. We have to simplify this process! State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener. This issue is closely related to revamping of channel state transfer callbacks - JGRP-563 -- 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

13 years, 5 months

2
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1026) Refactor extended persistence context

by Carlo de Wolf (JIRA)

Refactor extended persistence context ------------------------------------- Key: EJBTHREE-1026 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1026 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD -- 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

13 years, 5 months

3
19
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-184) Explore use of ClusteredCacheLoader to avoid state transfer

by Brian Stansberry (JIRA)

Explore use of ClusteredCacheLoader to avoid state transfer ----------------------------------------------------------- Key: JBCLUSTER-184 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-184 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry With CCL a cache miss results in a get call around the cluster. Can eliminate the need for in-memory state transfer. Won't work with buddy replication, but could be very interesting with total replication. Need to think through issues with things like passivation. -- 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

13 years, 5 months

1
4
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