November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3624) <security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans

by David Green (JIRA)

<security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans ------------------------------------------------------------------------------------------------------------------------- Key: JBAS-3624 URL: http://jira.jboss.com/jira/browse/JBAS-3624 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.0.4.GA Reporter: David Green Assigned To: Bill Burke Specifying a <security-domain> in the jboss-app.xml incorrectly sets the @SecurityDomain on EJB3 session beans. In the jboss-app.xml the security domain is specified as follows: <jboss-app> <security-domain>java:/jaas/hch</security-domain> </jboss-app> In Ejb3DescriptorHandler the security-domain is copied directly into the SecurityDomainImpl instance as "java:/jaas/hch", however the @SecurityDomain annotation should be populated with the value "hch" (without the leading "java:/jaas/" prefix). This causes the EJB3 session bean authentication to behave unexpectedly, since the authentication for the bean reverts to the default domain instead of the specified one. The only way I've found to workaround this issue is to specify the @SecurityDomain individually on every session bean in the project. -- 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

16 years, 1 month

5
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-341) ComponentRefGraphLicenseVisitor needs to externalize the repository url

by Scott M Stark (JIRA)

ComponentRefGraphLicenseVisitor needs to externalize the repository url ----------------------------------------------------------------------- Key: JBBUILD-341 URL: http://jira.jboss.com/jira/browse/JBBUILD-341 Project: JBoss Build System Issue Type: Bug Components: JBossBuild Reporter: Scott M Stark ComponentRefGraphLicenseVisitor always looks to URL("http://repository.jboss.com/licenses/") to obtain the license text. This should be looking to the location passed into the project build so that if can be overriden by the local build properties. -- 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

16 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1117) Request for feature to close connections on server side by ip address and by connection id

by Jay Howell (JIRA)

Request for feature to close connections on server side by ip address and by connection id ------------------------------------------------------------------------------------------ Key: JBMESSAGING-1117 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1117 Project: JBoss Messaging Issue Type: Feature Request Components: Configuration and Management Affects Versions: 1.4.0.GA Reporter: Jay Howell Assigned To: Tim Fox Several customers have asked for a management method to drop client connections from the server by ip address and by client id. So there would be two cases. By ipaddress - this would stop the pinger and also close all connections associated with that client ip address. Only one pinger exists for an ip address, so this would require closging of the pinger connection also. By clientid - this would close the pinger thread only if there are no other connections present. In each of the cases, clients should get an asynchronous onException call. The person writing the client will have to have this in mind. If a client has 1000 connections and the connection logic on the client reconnects. When the server drops the ip address, then that machine will try to reconnect all 1000 clients. I really depends on how the connection pooling on the client works. -- 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

16 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1022) Implement expired message reaper

by Tim Fox (JIRA)

Implement expired message reaper -------------------------------- Key: JBMESSAGING-1022 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1022 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta 1 We should implement an expired message reaper which traverse the queues to see if messages are expired and sends them to the expiry queue. Currently we only expire messages on delivery. -- 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

16 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3997) getManagedConnection retries

by Adrian Brock (JIRA)

getManagedConnection retries ---------------------------- Key: JBAS-3997 URL: http://jira.jboss.com/jira/browse/JBAS-3997 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Reporter: Adrian Brock Assigned To: Weston Price We should add the ability to retry getManagedConnection() when there is a resource exception from the pool. This will allow the ConnectionManagers to be more tolerant of transient failures. I'd suggest two new attributes on the connection manager, with the suggested defaults: <allocate-retry>1</allocate-retry> <allocate-retry-wait-millis>5000</allocate-retry-wait-millis> I also think the connection manager needs a "shutdown" boolean (maintained by start/stop) i.e. so don't wait 5 seconds if we get a resource exception caused by the CM/Pool getting undeployed, e.g. at JBoss shutdown. This would turn into the following *untested* code in BaseConnectionManager2: protected ConnectionListener getManagedConnection(Transaction transaction, Subject subject, ConnectionRequestInfo cri) throws ResourceException { ResourceException failure = null; if (shutdown.get()) throw new ResourceException("The connection manager is shutdown " + jndiName); // First attempt try { return poolingStrategy.getConnection(transaction, subject, cri); } catch (ResourceException e) { failure = e; // Retry? for (int i = 0; i < allocationRetries; ++i) { if (shutdown.get()) throw new ResourceException("The connection manager is shutdown " + jndiName); try { if (allocationWait != 0) wait(allocationWait); return poolingStrategy.getConnection(transaction, subject, cri); } catch (ResourceException e1) { failure = e1; } catch (InterruptedException e1) { JBossResourceException.rethrowAsResourceException("getManagedConnection retry wait was interrupted " + jndiName, e1); } } } // If we get here all retries failed, throw the lastest failure throw failure; } -- 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

16 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-4588) DeploymentSorter in the new profile service based deployment scanner

by Adrian Brock (JIRA)

DeploymentSorter in the new profile service based deployment scanner -------------------------------------------------------------------- Key: JBAS-4588 URL: http://jira.jboss.com/jira/browse/JBAS-4588 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployment services Reporter: Adrian Brock Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.Beta3 As per the related [JBMICROCONT-168] there should be a deployment sorter in the new scanner of JBoss5. -- 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

16 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1070) dlqhandler fails on redelivery for messages missing the JMS property "JMSXDeliveryCount"

by Danilo Guerra (JIRA)

dlqhandler fails on redelivery for messages missing the JMS property "JMSXDeliveryCount" ----------------------------------------------------------------------------------------- Key: EJBTHREE-1070 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1070 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.1.GA Reporter: Danilo Guerra GenericDLQHandler fails when handling redelivery of messages missing the property "JMSXDeliveryCount" when using non JbossMQ providers. excerpt from the class: org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler protected boolean handleDelivery(Message msg) { ..... try { if (msg.propertyExists(PROPERTY_DELIVERY_COUNT)) count = msg.getIntProperty(PROPERTY_DELIVERY_COUNT) - 1; } catch (JMSException ignored) { count = incrementResentCounter(id); } ... } This code fails because the property PROPERTY_DELIVERY_COUNT is checked and the exception is never thrown. As a result the resent counter is not incremented and the message will not be sent to the DLQ. -- 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

16 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4752) Session Expiration should also flush the JBoss Authentication Cache

by Anil Saldhana (JIRA)

Session Expiration should also flush the JBoss Authentication Cache ------------------------------------------------------------------- Key: JBAS-4752 URL: http://jira.jboss.com/jira/browse/JBAS-4752 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Security, Web (Tomcat) service Affects Versions: JBossAS-4.2.0.GA Reporter: Anil Saldhana Assigned To: Scott M Stark Fix For: JBossAS-4.2.2.GA, JBossAS-5.0.1.CR1 -- 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

16 years, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3916) Update source code headers.

by Dimitris Andreadis (JIRA)

Update source code headers. --------------------------- Key: JBAS-3916 URL: http://jira.jboss.com/jira/browse/JBAS-3916 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta2 Update the source code headers, like it was done for Branch_4_0 in JBAS-3601 -- 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

16 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1774) CMS metadata is lost on export

by Martin Putz (JIRA)

CMS metadata is lost on export ------------------------------ Key: JBPORTAL-1774 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1774 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.2 Final, 2.4.1 SP1 Reporter: Martin Putz Assigned To: Sohil Shah CMS metadata, such as title or description, is not being exported. If you do an export/import cycle of CMS data, you will therefore lose information. -- 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

16 years, 2 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007