November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1642) The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored

by John Gonon (JIRA)

The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored ------------------------------------------------------------------------------------------------ Key: EJBTHREE-1642 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1642 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: HEAD Environment: Windows XP JDK 1.6.build10 JBOSS 5.0.0.GA Reporter: John Gonon Priority: Minor The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored. I have tracked were the problem seems to be (at least as I saw it). In the class "org.jboss.ejb3.security.bridge.SecurityDomainMetaDataBridge" there are those lines: //TODO: How to get the merged meta data? Is the following line correct? if(securityDomain == null) securityDomain = beanMetaData.getJBossMetaData().getSecurityDomain(); I replaced them with: if (securityDomain == null) { JBossMetaData metaData = beanMetaData.getJBossMetaData(); securityDomain = metaData.getContainerConfiguration(beanMetaData.determineConfigurationName()) .getSecurityDomain(); if (securityDomain == null) securityDomain = metaData.getSecurityDomain(); } As I understand it, if no "SecurityDomain" annotation is found, then we finish in this class and we do in order: 1. seek for a security domain in the bean's metadata (I guess it is in the EJB declaration) 2. seek for the one in "jboss-app.xml" I inserted between them some code returning the one comming from the container's configuration I hope this helps ... Best regards, Please keep me informed, I hope to remove my "modified" jar with an official one soon. John -- 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

12 years, 11 months

2
5
0 / 0

[JBoss JIRA] (AS7-5873) Servlet response contains DOS-style EOL characters

by Cheng Fang (JIRA)

Cheng Fang created AS7-5873: ------------------------------- Summary: Servlet response contains DOS-style EOL characters Key: AS7-5873 URL: https://issues.jboss.org/browse/AS7-5873 Project: Application Server 7 Issue Type: Bug Components: Web Affects Versions: 7.0.2.SP1 Environment: Mac OS Reporter: Cheng Fang Assignee: Remy Maucherat I'm running AS7 on Mac, but found sometimes my servlet PrintWriter produces output with dos-style eol. When opening the output in vi, there are a couple of ^M at end of line. This does not always happen. After trying out a few samples, I found if the line already contains line.separator, then its eol will be ^M. For example, {code:java} PrintWriter out = response.getWriter(); out.println("From " + System.getProperty("line.separator") + this); {code} {noformat} From test.TestServlet@180ab18^M {noformat} If line.separator is not used when constructing servlet output, then everything looks normal. My guess is the servlet container may first apply a dos-style eol, then does some sort of replacing with native eol by searching for the first occurrence of line.separator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] (AS7-5634) add-user scripts not checking password strength for management users

by Cheng Fang (JIRA)

Cheng Fang created AS7-5634: ------------------------------- Summary: add-user scripts not checking password strength for management users Key: AS7-5634 URL: https://issues.jboss.org/browse/AS7-5634 Project: Application Server 7 Issue Type: Bug Components: Security Affects Versions: 7.2.0.CR1 Reporter: Cheng Fang Assignee: Darran Lofthouse So there is passwd check for app users, like at least x characters long, with mixed letters, numbers, etc. Is the same strength check applied to management user? I would assume management user passwords have more stringent requirement, at least should be the same as app user. But I can create a management user using password that consists of all letters (more than 8 letters). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
1
0 / 0

[JBoss JIRA] (AS7-5872) context list result has Object as the type for TimerService and BeanManager

by Cheng Fang (JIRA)

Cheng Fang created AS7-5872: ------------------------------- Summary: context list result has Object as the type for TimerService and BeanManager Key: AS7-5872 URL: https://issues.jboss.org/browse/AS7-5872 Project: Application Server 7 Issue Type: Bug Components: Naming Affects Versions: 7.2.0.CR1 Reporter: Cheng Fang Assignee: Cheng Fang InitialContext.list methods results have java.lang.Object as the type (in string) for ejb TimerService and cdi BeanManager resources. Need to update them to reflect their proper resource type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] (JBRULES-3678) Drools 5.4 evaluates wrong on repeated execution

by Thomas Kruse (JIRA)

Thomas Kruse created JBRULES-3678: ------------------------------------- Summary: Drools 5.4 evaluates wrong on repeated execution Key: JBRULES-3678 URL: https://issues.jboss.org/browse/JBRULES-3678 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.4.0.Final Reporter: Thomas Kruse Assignee: Mark Proctor Priority: Critical Regression in Drools 5.4: On repeated evaluation Drools starts to (not) fire rules. It seems like a knowledge session is getting corrupted over time. Perhaps related to the JIT? Disabling JIT in mvel did not mitigate the problem, change to Drools 5.3.0 does. I will add a test project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] (AS7-5609) RaRemove does not handle rollback

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5609: ------------------------------------- Summary: RaRemove does not handle rollback Key: AS7-5609 URL: https://issues.jboss.org/browse/AS7-5609 Project: Application Server 7 Issue Type: Bug Components: Domain Management, JCA Affects Versions: 7.1.3.Final (EAP) Reporter: Brian Stansberry Assignee: Stefano Maestri A rollback handling callback needs to be added to the Stage.RUNTIME context.completeStep() call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
1
0 / 0

[JBoss JIRA] (AS7-4714) Reintroduce the feature to allow EJB invocations over HTTP

by jaikiran pai (JIRA)

jaikiran pai created AS7-4714: --------------------------------- Summary: Reintroduce the feature to allow EJB invocations over HTTP Key: AS7-4714 URL: https://issues.jboss.org/browse/AS7-4714 Project: Application Server 7 Issue Type: Feature Request Components: EJB Affects Versions: 7.1.1.Final Reporter: jaikiran pai Assignee: jaikiran pai Fix For: 7.2.0.Alpha1 There have been requests from users to resurrect the feature from previous JBoss AS versions to allow EJB invocation over HTTP. Most recent discussion about this is here http://lists.jboss.org/pipermail/jboss-as7-dev/2012-April/005808.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

8
10
0 / 0

[JBoss JIRA] (JGRP-1529) RELAY2: Intra-site view not being accepted upon inter-site installation failure

by Radim Vansa (JIRA)

Radim Vansa created JGRP-1529: --------------------------------- Summary: RELAY2: Intra-site view not being accepted upon inter-site installation failure Key: JGRP-1529 URL: https://issues.jboss.org/browse/JGRP-1529 Project: JGroups Issue Type: Bug Reporter: Radim Vansa Assignee: Bela Ban When a node becomes coordinator, it sends the VIEW_CHANGE event up the stack. This should result in Receiver.viewAccepted(...) method call. However, when RELAY2 is in stack and the coordinator cannot be reached, it blocks the thread (sending discovery pings) and, therefore, the viewAccepted event is postponed. In my opinion the inter-site stack should be created and handled in different thread. Context: In my case, the coordinator for both local cluster and the global (inter-site) cluster was killed. The FD_SOCK on inter-site stack somehow failed to notice that the coordinator has crashed (more investigation required) and the nodes in global cluster still reported the crashed node as the global coordinator. Therefore, the new coordinator of local cluster failed to join the global cluster (obviously got no response from the dead global coordinator). The restarted node joined the local cluster and then tried to join the local Infinispan cache with a new local view ID. However, the coordinator failed to notice (in Infinispan viewAccepted handler which was not called) that he had already installed a new JGroups view and it did not respond to the cache join request because it was waiting until it got the new JGroups view (again, which was installed in JGroups but the viewAccepted did not notified Infinispan about that). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
3
0 / 0

[JBoss JIRA] (JGRP-1528) RELAY2: batch messages forwarded to remote sites

by Bela Ban (JIRA)

Bela Ban created JGRP-1528: ------------------------------ Summary: RELAY2: batch messages forwarded to remote sites Key: JGRP-1528 URL: https://issues.jboss.org/browse/JGRP-1528 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.3 If a site is down, then forwarding a message to it will block the thread (actually: wait) for max_forward_attempts * forward_sleep milliseconds. If we have many incoming messages (from the local site) to be forwarded to the remote site, then having every thread sleep for (say) 10 seconds will increase the thread pool. We should therefore add *batching* to RELAY2; messages to be forwarded are queued until a certain time has elapsed or the accumulated total size of all queued messages exceeds a certain threshold. Incoming messages to be forwarded would be added to the queue (allowing the sending thread to be returned to the thread pool). A separate thread (or task) would monitor the queue and do the forwarding, and it would also notice that a site is down and send unreachable messages back to the original senders. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
5
0 / 0

[JBoss JIRA] (AS7-5870) Services should only be created when the resource adapter is activated

by Jesper Pedersen (JIRA)

Jesper Pedersen created AS7-5870: ------------------------------------ Summary: Services should only be created when the resource adapter is activated Key: AS7-5870 URL: https://issues.jboss.org/browse/AS7-5870 Project: Application Server 7 Issue Type: Bug Components: JCA Affects Versions: 7.1.3.Final (EAP) Reporter: Jesper Pedersen Assignee: Stefano Maestri Priority: Critical Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) The ResourceAdapterDeploymentService class creates services for the resource adapter deployment even though the resource adapter isn't activated -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
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 2012