January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBMETA-343) Merge old version spec descriptors

by Carlo de Wolf (Created) (JIRA)

Merge old version spec descriptors ---------------------------------- Key: JBMETA-343 URL: https://issues.jboss.org/browse/JBMETA-343 Project: JBoss Metadata Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ejb Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: 7.0.0.Beta16 -- 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

14 years, 3 months

3
2
0 / 0

[JBoss JIRA] (AS7-3457) Server reload results in failed webservices startup

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-3457: ------------------------------------- Summary: Server reload results in failed webservices startup Key: AS7-3457 URL: https://issues.jboss.org/browse/AS7-3457 Project: Application Server 7 Issue Type: Bug Components: Web Services Reporter: Brian Stansberry Assignee: Alessio Soldano Priority: Critical Fix For: 7.1.0.Final Executing the :reload operation from the CLI results in: 17:14:50,681 ERROR [org.jboss.as.controller.management-operation] Operation ("add") failed - address: ([ ("subsystem" => "webservices"), ("endpoint-config" => "Recording-Endpoint-Config"), ("pre-handler-chain" => "recording-handlers") ]) - failure description: "JBAS015588: Cannot add new handler chain of type pre-handler-chain with id recording-handlers. This id is already used in config Recording-Endpoint-Config for another chain." -- 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

14 years, 3 months

2
7
0 / 0

[JBoss JIRA] (AS7-3430) Provide the ability to change the permgen sizes

by Heiko Braun (JIRA)

Heiko Braun created AS7-3430: -------------------------------- Summary: Provide the ability to change the permgen sizes Key: AS7-3430 URL: https://issues.jboss.org/browse/AS7-3430 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.1.0.Final -- 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

14 years, 3 months

1
2
0 / 0

[JBoss JIRA] (AS7-3464) add-user.sh - possibility of setting another Realms should be considered again

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/AS7-3464?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated AS7-3464: ---------------------------------- Fix Version/s: Open To Community Assignee: (was: Anil Saldhana) If anyone in the community would like to contribute what we actually need here is better detection of the name of the security realm in use by the AS instance. By default we ship with the realm named ManagementRealm, however as the digest in the properties file is based on the username, realm and password we would recommend the use of different realms on different installations so that disclosing the properties file from one installation does not necessarily affect other instances that have users with the same username and password but a different realm. The issue is that the name of the realm is defined in the standalone.xml and host.xml so as it stands now these need to be parsed if the server is not running to identify the name of the realm - if the server is running a connection to the server is an option (although a bit messy) to discover the realm. Alternatively the name of the realm used for the digests could be separated from the config and stored in a file adjacent to the properties file, the first time add-user.sh is run the user would be asked to choose a realm name for their installation - that would be stored in the file and used for all subsequent calls to add-user.sh - this way unique realm names could be encouraged without forcing the core configuration to be modified. This alternative location to specify the realm may be better considered for AS 7.2 or beyond when we will hopefully expand on the manageability of users and incorporate it there. > add-user.sh - possibility of setting another Realms should be considered again > ------------------------------------------------------------------------------ > > Key: AS7-3464 > URL: https://issues.jboss.org/browse/AS7-3464 > Project: Application Server 7 > Issue Type: Bug > Components: Security > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Priority: Minor > Fix For: Open To Community > > > I'm aware of add-user.sh isn't general tool for managing an user/groups/roles credential store at all. Is it supposed only as shorthand for quick definition of users access to admin console out of the box. Well.. > According previous paragraph it isn't to much meaningful for me to bring possibility of specify another realm during the invocation of this tool. I think already - Admin console can use another realm than ManagementRealm by change default configuration. I think already too - property file can't contain users definition belong multiple realms. As is stated in comment in the begin of file mgmt-users.properties, this file is for "declaration of users for the realm 'ManagementRealm'". > I think we should avoid to insert new user with different realm there (it is possible now). add-user.sh doesn't manage any other file and other property file(s) can't be specified during invocation. > I think this present situation/behavior should confuse hard our end-users - especially users with their own experiences with other JEE servers (Apache Geronimo, Sun/Oracle GlassFish etc.). > Because we don't provide/support any tool for general CRUD managing of credential store of type like property file(s) - like other JEE app. servers do, we really should use this script/tool only as way to simple very basic user creation in default AS7 environment, because we can't support this tool in any other situation with present behavior and in a such changed environments behavior or final state is hardly understandable (if we create property file (by other way) with the same username, but in different realms, we can't log to admin console never more; if we have users in one realm, switch AS7 instance to use other "admin" realm, we can't add any from existing user to this new realm; we don't know which user belongs to which realm later etc.) > So conclusion - I think we should remove specification of Realm from input process of add-user.sh script at all and use this script only to define users belongs to ManagementRealm realm and manages only properly mgmt-users.properties files (standalone and domain configuration) -- 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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-3322) Need to review how the SSL port is specified for the HTTP management interface.

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-3322: ------------------------------------- Summary: Need to review how the SSL port is specified for the HTTP management interface. Key: AS7-3322 URL: https://issues.jboss.org/browse/AS7-3322 Project: Application Server 7 Issue Type: Task Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 7.1.0.Final -- 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

14 years, 3 months

3
12
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2110) Add flag to enable an optimization to skip serialization/deserialization of Remote interfaces running locally

by Ben Schofield (JIRA)

Add flag to enable an optimization to skip serialization/deserialization of Remote interfaces running locally ------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2110 URL: https://jira.jboss.org/browse/EJBTHREE-2110 Project: EJB 3.0 Issue Type: Feature Request Reporter: Ben Schofield When an application uses a remote EJB3 interface the call is serialized and deserialized. While mandated by spec this is unnecessary if the EJB is running in the same JVM as the calling client. Having the option to skip serialization would bring JBoss inline with other major JEE vendors. Performance tests on a transactional application that has all business logic in stateless session bean methods is showing 20% cpu overhead just for the serialization. Having 20% more production CPU capacity is more important than claiming strict EJB3 compliance. JBoss AS response times are better too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

5
12
0 / 0

[JBoss JIRA] (AS7-3469) If all servers are stopped the server instance list fails to load

by Heiko Braun (JIRA)

Heiko Braun created AS7-3469: -------------------------------- Summary: If all servers are stopped the server instance list fails to load Key: AS7-3469 URL: https://issues.jboss.org/browse/AS7-3469 Project: Application Server 7 Issue Type: Bug Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Priority: Critical Fix For: 7.1.0.Final Obviously, this leaves the console in a terrible state. -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] (JBFORUMS-295) JBOSS-4.0.4GA generates errors

by Regimantas Kontrimas (JIRA)

Regimantas Kontrimas created JBFORUMS-295: --------------------------------------------- Summary: JBOSS-4.0.4GA generates errors Key: JBFORUMS-295 URL: https://issues.jboss.org/browse/JBFORUMS-295 Project: JBoss Forums Issue Type: Feature Request Environment: JBOSS 4.0.4 GA works on RedHat Reporter: Regimantas Kontrimas Assignee: Luca Stancapiano We have product, which works with jboss-4.0.4GA, and sometimes (recently it happens very often) and all my soft performance is very slow. My jboss-4.0.4GA server generates errors (my caught errors) ****Error 2012-01-26 08:16:16,615 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/xnet].[XNET2]] Servlet.service() for servlet XNET2 threw exception javax.servlet.ServletException: SecurityException at com.thrasys.xnet.servlets.XNetServlet2.doPost(XNetServlet2.java:73) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at com.thrasys.xnet.servlets.XNetServlet.service(XNetServlet.java:406) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at com.thrasys.xnet.servlets.XNetServlet.service(XNetServlet.java:415) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595) ****Error2***** 2012-01-26 09:45:56,182 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing: --- Packages waiting for a deployer --- org.jboss.deployment.DeploymentInfo@95730337 { url=file:/usr/local/special/jboss-4.0.4.GA/server/default/deploy/run.conf } deployer: null status: null state: INIT_WAITING_DEPLOYER watch: file:/usr/local/special/jboss-4.0.4.GA/server/default/deploy/run.conf altDD: null lastDeployed: 1327563956181 lastModified: 1327563956000 mbeans: --- Incompletely deployed packages --- org.jboss.deployment.DeploymentInfo@95730337 { url=file:/usr/local/special/jboss-4.0.4.GA/server/default/deploy/run.conf } deployer: null status: null state: INIT_WAITING_DEPLOYER watch: file:/usr/local/special/jboss-4.0.4.GA/server/default/deploy/run.conf altDD: null lastDeployed: 1327563956181 lastModified: 1327563956000 mbeans: *****Error3**** 12-01-26 09:51:16,035 ERROR [STDERR] java.lang.NullPointerException 2012-01-26 09:51:16,036 ERROR [STDERR] at org.openedix.logging.LogManager.run(LogManager.java:322) 2012-01-26 09:51:16,036 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] (AS7-2273) JPS Output

by Rich Sharples (Created) (JIRA)

JPS Output ---------- Key: AS7-2273 URL: https://issues.jboss.org/browse/AS7-2273 Project: Application Server 7 Issue Type: Enhancement Components: Server Affects Versions: 7.1.0.Alpha1 Environment: all Reporter: Rich Sharples Assignee: Jason Greene Fix For: 7.1.0.Beta1 All JBoss AS processes need to provide jps (JVM Process Status Tool) with a descriptive identifier - currently JPS reports a default domain as : 34151 jboss-modules.jar 34152 jboss-modules.jar 34153 jar 34154 jar The first two are server instances, the last two are the DC and HC. Even a verbose listing (jps -v) doesn't help distinguish server instances from each other or the DC from the HC. Maybe a dummy argument "-Dname="Host Controller" or in the case of a server instance the server nam might help. -- 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

14 years, 3 months

5
5
0 / 0

[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ] Stuart Douglas updated AS7-3199: -------------------------------- Fix Version/s: (was: 7.1.0.Final) I have developed some integration code to make this work: https://github.com/stuartwdouglas/jboss-as/compare/AS7-3199 however this fails due to the linked RESTeasy bug. As a result I am de-scheduling this issue, as it is now out of the AS7 teams control. > RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present > --------------------------------------------------------------------------------------------- > > Key: AS7-3199 > URL: https://issues.jboss.org/browse/AS7-3199 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Stuart Douglas > Priority: Critical > Labels: eap6_prd_req > Attachments: ExampleJAXRS.war > > > If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed." > This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for > more than one application to be deployed +at the same effective servlet mapping+". > If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+. -- 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

14 years, 3 months

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