November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-9416) EJB3 SFSB performace problem: parallel calls are sequenced

by Radim Hanus (JIRA)

EJB3 SFSB performace problem: parallel calls are sequenced ---------------------------------------------------------- Key: JBAS-9416 URL: https://issues.jboss.org/browse/JBAS-9416 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: Radim Hanus When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced. Works fine in jboss-5.1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

9
26
0 / 0

[JBoss JIRA] Created: (AS7-1581) tomcatAuthentication attribute on the AJP connector

by Brett Prucha (JIRA)

tomcatAuthentication attribute on the AJP connector --------------------------------------------------- Key: AS7-1581 URL: https://issues.jboss.org/browse/AS7-1581 Project: Application Server 7 Issue Type: Feature Request Components: Server Affects Versions: 7.0.0.Final Environment: Windows Server 2003 32 bit, IIS 6, tomcat connector 1.2.28 used as an extension Reporter: Brett Prucha Assignee: Jason Greene Priority: Minor In JBoss 5.1.0 I could set the tomcatAuthentication attribute of the AJP connector to false to allow IIS to handle the authentication and pass that along to JBoss. I'm wanting to upgrade to JBoss 7 but unable to set this attribute in version 7.0.0 final to make this work. This attribute is descibed in the tomcat documentation at http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
8
0 / 0

[JBoss JIRA] (AS7-5875) Re-review CLI server certificate acceptance.

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-5875: ------------------------------------- Summary: Re-review CLI server certificate acceptance. Key: AS7-5875 URL: https://issues.jboss.org/browse/AS7-5875 Project: Application Server 7 Issue Type: Task Components: CLI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.2.0.Alpha1 Can we remove the call loop and manage the user prompt and trust store replacement all within the trust manager? -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5874) Update JGroups UDP stack to use MERGE3

by Paul Ferraro (JIRA)

Paul Ferraro created AS7-5874: --------------------------------- Summary: Update JGroups UDP stack to use MERGE3 Key: AS7-5874 URL: https://issues.jboss.org/browse/AS7-5874 Project: Application Server 7 Issue Type: Enhancement Components: Clustering Affects Versions: No Release Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 7.2.0.Alpha1 -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-9245) Passivation of a @Stateful session bean with an @Inject'ed @Stateless session bean fails with not-serializable error.

by Felix Ullrich (JIRA)

Passivation of a @Stateful session bean with an @Inject'ed @Stateless session bean fails with not-serializable error. --------------------------------------------------------------------------------------------------------------------- Key: JBAS-9245 URL: https://issues.jboss.org/browse/JBAS-9245 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Reporter: Felix Ullrich Assignee: Carlo de Wolf I've the same problem described in this issue https://issues.jboss.org/browse/JBAS-8384 Could you please resolve it (maybe in 6.1.0) and dont just close it. Thank you -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-9433) JBoss-6.1.0-SNAPSHOT - Adding @WebService causes EJBException "Named query not found"

by Ralf Battenfeld (JIRA)

JBoss-6.1.0-SNAPSHOT - Adding @WebService causes EJBException "Named query not found" ------------------------------------------------------------------------------------- Key: JBAS-9433 URL: https://issues.jboss.org/browse/JBAS-9433 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Environment: Windows Vista 32-bit, JDK 1.6.0_21-b07 Reporter: Ralf Battenfeld Assignee: Carlo de Wolf Attachments: TestNamedQueryException.zip We faced an issue when a webservice annotation is added to a session bean and there are two persistence units defined. All of them are in the same ejb module defined and packed in an ear. The behaviour is not predictable, some times it works but most of the times, not. Without the @Webservice annotation, we don't have deployment issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-9391) EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored

by Pierre Kobylanski (JIRA)

EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored --------------------------------------------------------------------------------------------- Key: JBAS-9391 URL: https://issues.jboss.org/browse/JBAS-9391 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Environment: $ uname -a Linux tumlatum 2.6.38-2-686-bigmem #1 SMP Sun May 8 15:43:39 UTC 2011 i686 GNU/Linux Reporter: Pierre Kobylanski Assignee: Carlo de Wolf ejb 3.1 spec [4.8.4 Singleton Error Handling] says that "Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance." I tried to raise a system exception in the @PostConstruct method of a singleton bean. Logs show the deployment error. But I then can access and call the singleton methods. -- Full paragraph 4.8.4: ----------------------------- Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance. Possible initialization errors include injection failure, a system exception thrown from a PostConstruct method, or the failure of a PostConstruct method container-managed transaction to successfully commit. If a singleton fails to initialize, attempted invocations on the Singleton result in an exception as defined by Section 3.4.3 and Section 3.4.4. ------------------------------------------------------ I tested to raise a system exception (throw new RuntimeException()) in the @PostConstruct method. -- Logs show the error ------------------------------- ERROR [AbstractKernelController] Error installing to Start: name=startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter aliases=[startup-singleton-initiator:bean=counter,topLevelUnit=ts.ear,unit=testSingletonEjb.jar] state=Create: java.lang.RuntimeException: Could not invoke PostConstruct on the newly created bean instance at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28] ... Caused by: testsingleton.exn.SE // class SE extends RuntimeException{} at testsingleton.ejb.CounterEjb.pc(CounterEjb.java:28) DEPLOYMENTS IN ERROR: Deployment "startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter" is in error due to the following reason(s): testsingleton.exn.SE at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1228) [:2.2.0.GA] ------------------------------------------------------ However, it is after that possible to access the singleton through a JNDI lookup and successfully call its methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2255) @SecurityDomain has no equivalent for <security-domain/>

by Richard Kennard (JIRA)

@SecurityDomain has no equivalent for <security-domain/> -------------------------------------------------------- Key: EJBTHREE-2255 URL: https://issues.jboss.org/browse/EJBTHREE-2255 Project: EJB 3.0 Issue Type: Bug Environment: JBoss 6.0.0.Final Reporter: Richard Kennard Test case attached. We have found it useful to turn off the security-domain for certain EJBs so that they can be accessed from unauthenticated clients. We can do this in jboss.xml using <security-domain /> but not, it seems, from an EJB using the @SessionDomain annotation. A @SessionDomain( "" ) is simply ignored. We're not a big fan of hard-coding security domain names inside EJBs, but it seems fine to be able to say 'this EJB has no security domain at all'. Should the annotation work for this? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
8
0 / 0

[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, 1 month

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, 1 month

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2012