March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6670) Missing JSP or EL privileged action(s)

by Remy Maucherat (JIRA)

[ https://issues.jboss.org/browse/AS7-6670?page=com.atlassian.jira.plugin.s... ] Remy Maucherat commented on AS7-6670: ------------------------------------- Ok, good catch, that will be included in the next web build. > Missing JSP or EL privileged action(s) > -------------------------------------- > > Key: AS7-6670 > URL: https://issues.jboss.org/browse/AS7-6670 > Project: Application Server 7 > Issue Type: Bug > Components: Web > Reporter: David Lloyd > Assignee: Remy Maucherat > Fix For: 8.0.0.Alpha1 > > > When running with a security manager, we're seeing an access control problem with this stack trace: > {noformat} > 18:21:08,471 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/web-secure].[jsp]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader") > at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) [rt.jar:1.7.0_15] > at java.security.AccessController.checkPermission(AccessController.java:560) [rt.jar:1.7.0_15] > at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_15] > at java.lang.Thread.getContextClassLoader(Thread.java:1451) [rt.jar:1.7.0_15] > at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final] > at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final] > at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final] > at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.jasper.runtime.JspApplicationContextImpl.getInstance(JspApplicationContextImpl.java:77) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.jasper.runtime.JspFactoryImpl.getJspApplicationContext(JspFactoryImpl.java:197) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.jsp.login_jsp._jspInit(login_jsp.java:22) > at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:51) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:151) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:320) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:242) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final.jar:1.0.2.Final] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_15] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_15] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_15] > at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_15] > at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:263) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:261) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15] > at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) [rt.jar:1.7.0_15] > at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:295) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:155) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:288) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:59) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:197) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:620) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:553) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:69) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:84) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15] > at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:474) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:372) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:265) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:447) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > {noformat} > It looks like javax.el should probably be getting TCCL from a privileged block, or else org.apache.jasper.runtime.JspApplicationContextImpl.<init> should be executing in a privileged context. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1595) STABLE: send stable messages to coordinator only

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1595?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1595: --------------------------- Summary: STABLE: send stable messages to coordinator only (was: STABLE2) Added flag send_stable_msg_to_coord_only, which (if true) sends STABLE messages to the coord only, instead of to all cluster members (reducing traffic) > STABLE: send stable messages to coordinator only > ------------------------------------------------ > > Key: JGRP-1595 > URL: https://issues.jboss.org/browse/JGRP-1595 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > While JGRP-1570 only changes the default for desired_avg_gossip and max_bytes (not scaling them with the cluster size), this issue is about a new stable protocol, STABLE2, which works well in large clusters without generating too much traffic. > It works as follows: > * A dedicated member (the coord) periodically multicast a STABLE message > * Everyone replies with a (unicast) STABLE message and when the coord has received STABLE replies from everyone, it multicasts a STABILITY message > * This would only require a multicast from the coord to everyone, establishing TCP connections from the coord to everyone (usually already exists because of the VIEW-CHANGE multicast), but everyone would reuse the same TCP connection to send the reply > Another solution could be that every member sends its STABLE message to the current coordinator (triggered by time or size), and when the coordinator has received STABLE messages from all members, it multicasts a STABILITY message -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1595) STABLE2

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1595?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1595: -------------------------------- Didn't add a new protocol, but instead added send_stable_msgs_to_coord_only to STABLE, which toggles sending messages to all members, or only to the coordinator > STABLE2 > ------- > > Key: JGRP-1595 > URL: https://issues.jboss.org/browse/JGRP-1595 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > While JGRP-1570 only changes the default for desired_avg_gossip and max_bytes (not scaling them with the cluster size), this issue is about a new stable protocol, STABLE2, which works well in large clusters without generating too much traffic. > It works as follows: > * A dedicated member (the coord) periodically multicast a STABLE message > * Everyone replies with a (unicast) STABLE message and when the coord has received STABLE replies from everyone, it multicasts a STABILITY message > * This would only require a multicast from the coord to everyone, establishing TCP connections from the coord to everyone (usually already exists because of the VIEW-CHANGE multicast), but everyone would reuse the same TCP connection to send the reply > Another solution could be that every member sends its STABLE message to the current coordinator (triggered by time or size), and when the coordinator has received STABLE messages from all members, it multicasts a STABILITY message -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6677) Cannot deploy application using datasource with empty password value

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/AS7-6677?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen closed AS7-6677. -------------------------------- Resolution: Incomplete Description Reopen with complete information in this JIRA > Cannot deploy application using datasource with empty password value > -------------------------------------------------------------------- > > Key: AS7-6677 > URL: https://issues.jboss.org/browse/AS7-6677 > Project: Application Server 7 > Issue Type: Bug > Components: JCA > Environment: 7.2.0.Final prerelase > Reporter: Tomas Remes > Assignee: Jesper Pedersen > > I think you can use arbitrary application with JPA (e.g some of the JBoss AS quickstarts) -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-305) Upgrade to JBoss Cache 3.2.12

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-305?page=com.atlassian.jira.plu... ] Bartosz Baranowski updated JBCLUSTER-305: ----------------------------------------- Summary: Upgrade to JBoss Cache 3.2.12 (was: Upgrade to JBC 3.2.12) > Upgrade to JBoss Cache 3.2.12 > ----------------------------- > > Key: JBCLUSTER-305 > URL: https://issues.jboss.org/browse/JBCLUSTER-305 > Project: JBoss Clustering > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Paul Ferraro > > Upgrade to JBoss Cache 3.2.12 is required. This is because of changes in 304 and fact that in AS5 cluster runs against 3.2.11, while it's compiled against 3.2.5. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-305) Upgrade to JBC 3.2.12

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-305?page=com.atlassian.jira.plu... ] Bartosz Baranowski updated JBCLUSTER-305: ----------------------------------------- Description: Upgrade to JBoss Cache 3.2.12 is required. This is because of changes in 304 and fact that in AS5 cluster runs against 3.2.11, while it's compiled against 3.2.5. > Upgrade to JBC 3.2.12 > --------------------- > > Key: JBCLUSTER-305 > URL: https://issues.jboss.org/browse/JBCLUSTER-305 > Project: JBoss Clustering > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Paul Ferraro > > Upgrade to JBoss Cache 3.2.12 is required. This is because of changes in 304 and fact that in AS5 cluster runs against 3.2.11, while it's compiled against 3.2.5. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1570) STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1570?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1570. ---------------------------- Resolution: Done > STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters > ------------------------------------------------------------------------------------------------------------ > > Key: JGRP-1570 > URL: https://issues.jboss.org/browse/JGRP-1570 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > The time computed for the sending of STABLE is desired_avg_gossip * cluster-size *2. While this is OK for small clusters, it may be too big for large clusters. > On the other hand, if every member simply multicasts a STABLE message every (say) 30 seconds on average, then the number of messages sent grows with increasing cluster size. > Investigate a way to set a lower and upper limit for the making and delivery of *STABILITY* messages, e.g. the goal is to receive 1 stability message every 60s. > Besides increased traffic, however, this requires everyone to have a TCP connection to everybody else in the cluster in case of a TCP transport. > A better solution might be to have only a dedicated member (the coord) periodically multicast a STABLE message. Everyone replies with a (unicast) STABLE message and when the coord has received STABLE replies from everyone, it multicasts a STABILITY message. This would only require a multicast from the coord to everyone, establishing TCP connections from the coord to everyone (usually already exists because of the VIEW-CHANGE multicast), but everyone would reuse the same TCP connection to send the reply. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-305) Upgrade to JBC 3.2.12

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-305?page=com.atlassian.jira.plu... ] Bartosz Baranowski updated JBCLUSTER-305: ----------------------------------------- Issue Type: Component Upgrade (was: Enhancement) > Upgrade to JBC 3.2.12 > --------------------- > > Key: JBCLUSTER-305 > URL: https://issues.jboss.org/browse/JBCLUSTER-305 > Project: JBoss Clustering > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Paul Ferraro > -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-305) Upgrade to JBC 3.2.12

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBCLUSTER-305: -------------------------------------------- Summary: Upgrade to JBC 3.2.12 Key: JBCLUSTER-305 URL: https://issues.jboss.org/browse/JBCLUSTER-305 Project: JBoss Clustering Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Bartosz Baranowski Assignee: Paul Ferraro -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-304) Align ha-server-cache-jbc with latest cache

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-304?page=com.atlassian.jira.plu... ] Bartosz Baranowski commented on JBCLUSTER-304: ---------------------------------------------- Patch requires update to new version of JBC, 3.2.12.Something > Align ha-server-cache-jbc with latest cache > ------------------------------------------- > > Key: JBCLUSTER-304 > URL: https://issues.jboss.org/browse/JBCLUSTER-304 > Project: JBoss Clustering > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: HA-Server-Cache-JBC > Affects Versions: HA-Server-Cache-JBC 2.0.3.Final > Reporter: Bartosz Baranowski > Assignee: Paul Ferraro > Fix For: HA-Server-Cache-JBC 2.4.0.Final > > Attachments: JBCLUSTER-304.patch > > -- 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

13 years, 4 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 March 2013