November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-308) Findbugs analysis

by Anil Saldhana (JIRA)

Findbugs analysis ----------------- Key: SECURITY-308 URL: https://jira.jboss.org/jira/browse/SECURITY-308 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: ACL, Identity, JBossSX, Security SPI Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: 2.0.2.GA Simplest way to analyse is to use webstart: http://findbugs.cs.umd.edu/demo/jnlp/findbugs.jnlp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (SECURITY-118) ACL framework integration with AuthorizationManager implementation

by Anil Saldhana (JIRA)

ACL framework integration with AuthorizationManager implementation ------------------------------------------------------------------ Key: SECURITY-118 URL: http://jira.jboss.com/jira/browse/SECURITY-118 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: ACL, JBossSX, Security SPI Affects Versions: 2.0.2-BETA4 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2-BETA5 Implement the JBossAuthorizationManager ->getEntitlements method. Additionally, there is a need for ACLContext. -- 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, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1282) Test XA recovery of temporary topic subscriptions

by Michael Musgrove (JIRA)

Test XA recovery of temporary topic subscriptions ------------------------------------------------- Key: JBMESSAGING-1282 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1282 Project: JBoss Messaging Issue Type: Task Components: AS Integration Affects Versions: AS 5.0 Integration Reporter: Michael Musgrove Assigned To: Tim Fox Priority: Optional After integrating JBossMQ recovery code into build 4.2.3.GA of the app server (see JIRA JBTM-279) XA recovery fails if any of the resources used in a transaction corresponds to a JMS topic that only has temporary subscriptions. What happens is that the TM records the transaction branch and when it replays the branch the JMS server does not have any record of the transaction so the TM can never complete the transaction. It works with durable subscriptions since JMS remembers the transaction id. I've raised this task in order to test the behavior of non-durable subscriptions with JBoss Messaging. The files used to test the feature on MQs are attached to JIRA JBTM-279. -- 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, 8 months

4
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1132) Use blocking mode for callbacks with Remoting http transport

by Ron Sigal (JIRA)

Use blocking mode for callbacks with Remoting http transport ------------------------------------------------------------ Key: JBMESSAGING-1132 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1132 Project: JBoss Messaging Issue Type: Task Reporter: Ron Sigal Assigned To: Tim Fox Fix For: 2.0.0 Alpha In response to JBREM-641 "re-implement the callback polling for http transport to reduce latency", an alternative way of handling callbacks was introduced in Remoting. In particular, instead of the client periodically polling for callbacks, in "blocking" mode, the request to download callbacks blocks on the server until either (1) a callback is available, or (2) the timeout period has expired. The advantage is reduced latency in retrieving callbacks. In fact, some JBM http transport stress tests which fail in "nonblocking" mode now pass in "blocking" mode. 1. The default mode is "nonblocking", so it is necessary to explicitly configure "blocking" mode. One way to do so is to add the appropriate parameter to the metadata map when installing the callback listener. E.g., add the following line to org.jboss.jms.client.remoting.JMSRemotingConnection.createCallbackMetadata(): if (reportPollingStatistics != null) { metadata.put(CallbackPoller.REPORT_STATISTICS, reportPollingStatistics); } metadata.put(ServerInvoker.BLOCKING_MODE, ServerInvoker.BLOCKING); // <<=== add this line metadata.put(ServerInvoker.BLOCKING_TIMEOUT, "7777"); // optional: default is 5000 milliseconds 2. The line <attribute name="callbackPollPeriod" isParam="true">102</attribute> may be removed from remoting-http-service.xml, since it's no longer relevant. -- 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, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1411) Wrong DEFAULT_RECOVER_DELIVERIES_TIMEOUT value

by Takayoshi Kimura (JIRA)

Wrong DEFAULT_RECOVER_DELIVERIES_TIMEOUT value ---------------------------------------------- Key: JBMESSAGING-1411 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1411 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3_CP01 Reporter: Takayoshi Kimura Assignee: Tim Fox org.jboss.messaging.core.impl.MessagingQueue: DEFAULT_RECOVER_DELIVERIES_TIMEOUT = 5 * 60 * 10000; The last number should be 1000. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1281) JBossBytesMessage generates NullPointerException on 0-byte messages

by Patrick Dolan (JIRA)

JBossBytesMessage generates NullPointerException on 0-byte messages ------------------------------------------------------------------- Key: JBMESSAGING-1281 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1281 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.SP3 Environment: JBoss 4.3.0GA on RHEL Reporter: Patrick Dolan Assigned To: Tim Fox Priority: Minor Sometimes we get sent zero-byte BytesMessages through our system via user error or other and when such a message is read by JBoss Messaging and converted into a JBossBytesMessage object, a NullPointerException occurs. The source of the error is in the checkRead method: bais = new ByteArrayInputStream(payloadAsByteArray); In this case the payloadAsByteArray object is not initialized since the message was empty and the BAIS throws a NullPointerException. This is certainly not a high-priority issue but it might be better to either check that condition or throw a more meaningful JMS exception when empty messages are encountered. -- 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, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1279) ServerSessionEndpoint: Verbose logging

by Jesper Pedersen (JIRA)

ServerSessionEndpoint: Verbose logging -------------------------------------- Key: JBMESSAGING-1279 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1279 Project: JBoss Messaging Issue Type: Task Components: Messaging Core Affects Versions: 1.4.1.CR1 Reporter: Jesper Pedersen Assigned To: Clebert Suconic I'm getting a lot 09:59:21,442 INFO [ServerSessionEndpoint] Received send for ID:JBM-fd27f536-cf76-4280-a367-847d5443f04f reliable: true 09:59:21,456 INFO [ServerSessionEndpoint] Done send with 1.4.1.CR1. Could you change them to TRACE instead ? -- 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, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1430) org.jboss.jms.server.messagecounter.MessageCounter class is not Serializable

by Ji-Woong Choi (JIRA)

org.jboss.jms.server.messagecounter.MessageCounter class is not Serializable ---------------------------------------------------------------------------- Key: JBMESSAGING-1430 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1430 Project: JBoss Messaging Issue Type: Bug Components: Configuration and Management Affects Versions: 1.4.0.SP3_CP03 Environment: JBoss Messaging 1.4.0 SP3_CP03 in JBoss EAP4.3 HP-UX B11.23 JDK 1.5.0_14 Reporter: Ji-Woong Choi Assignee: Tim Fox Hi~ Tim There is a problem with class serialization of org.jboss.jms.server.messagecounter.MessageCounter during I am making a GUI QueueBrowser outside of JBoss container. I found that MessageCounter class was not implemented java.io.Serializable. I have to get total message count after server startup and current message count in queue for displaying data. This is the access code thru JMX: QueueMBean queueMBean = (QueueMBean) MBeanServerInvocationHandler .newProxyInstance(server, objName, QueueMBean.class, false); currentMessageCount = queueMBean.getMessageCount(); totalMessageCount = queueMBean.getMessageCounter().getCount(); Exception is following : Created LoginContext jboss.messaging.destination:service=Queue,name=testQueue java.lang.reflect.UndeclaredThrowableException at $Proxy1.getMessageCounter(Unknown Source) at com.jboss.monitor.QueueBrowser.retrieve(QueueBrowser.java:49) at com.jboss.monitor.QueueBrowser.main(QueueBrowser.java:69) Caused by: java.io.NotSerializableException: org.jboss.jms.server.messagecounter.MessageCounter at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at java.rmi.MarshalledObject.<init>(MarshalledObject.java:92) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:423) 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 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:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy0.getAttribute(Unknown Source) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:175) ... 3 more Is there any reason for this(not serialization)? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1377) Typo in default HSQL persistence config

by Tim Fox (JIRA)

Typo in default HSQL persistence config --------------------------------------- Key: JBMESSAGING-1377 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1377 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.SP3_CP03, Stable branch There is a typo in the default HSQL config in JDBCPersistenceManager.java: map.put("CREATE_ID_CACHE", "CREATE TABLE JBM_ID_CACHE (NODE_ID INTEGER, CNTR INTEGER, JBM_ID VARCHAR(255), PRIMARY KEY(NODEID, CNTR))"); should be: map.put("CREATE_ID_CACHE", "CREATE TABLE JBM_ID_CACHE (NODE_ID INTEGER, CNTR INTEGER, JBM_ID VARCHAR(255), PRIMARY KEY(NODE_ID, CNTR))"); -- 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, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1239) http example should use JNDI via HTTP

by David Smiley (JIRA)

http example should use JNDI via HTTP ------------------------------------- Key: JBMESSAGING-1239 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1239 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3 Reporter: David Smiley Assigned To: Tim Fox The http example uses the http connector to for JMS transport. However, the example is using the typical JNDI configuration which is jnp's protocol. Instead, a complete HTTP transport should be used, even for JNDI. To fix this, simply change jndi.properties to this: java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory java.naming.provider.url=http://localhost:8080/invoker/JNDIFactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces -- 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, 8 months

3
6
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 2008