[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on JBEE-161:
----------------------------------------------
Dmitrii Tikhomirov <dtikhomi(a)redhat.com> changed the Status of [bug 1292891|https://bugzilla.redhat.com/show_bug.cgi?id=1292891] from POST to MODIFIED
> BeanELResolver does not support methods that use varargs
> --------------------------------------------------------
>
> Key: JBEE-161
> URL: https://issues.jboss.org/browse/JBEE-161
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1
> Reporter: Ingo Weiss
> Assignee: Scott Marlow
> Labels: el
> Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
> Attachments: beanELResolver4VarArgs.zip
>
>
> When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception:
> {code}
> java.lang.IllegalArgumentException: wrong number of arguments
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834)
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:527)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:156)
> at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32)
> at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6443) Inconsistent behavior of journal object store for heuristic state
by Tom Jenkinson (JIRA)
Tom Jenkinson created WFLY-6443:
-----------------------------------
Summary: Inconsistent behavior of journal object store for heuristic state
Key: WFLY-6443
URL: https://issues.jboss.org/browse/WFLY-6443
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Tom Jenkinson
Assignee: Michael Musgrove
Priority: Blocker
Fix For: 10.1.0.Final
We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
Our test case:
* enlist activemq JMS resource
* enlist test XA resource
* prepare JMS resource
* prepare test XA resource
* commit JMS resource
* commit test XA resource
** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
* probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
** expecting one indoubt participant in HEURISTIC state
* calling operation {{recovery}} on all transaction's participants
* do recovery
This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6442:
--------------------------------
Fix Version/s: 10.1.0.Final
> Inconsistent behavior of journal object store for heuristic state
> -----------------------------------------------------------------
>
> Key: WFLY-6442
> URL: https://issues.jboss.org/browse/WFLY-6442
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
> Our test case:
> * enlist activemq JMS resource
> * enlist test XA resource
> * prepare JMS resource
> * prepare test XA resource
> * commit JMS resource
> * commit test XA resource
> ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
> 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
> * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
> ** expecting one indoubt participant in HEURISTIC state
> * calling operation {{recovery}} on all transaction's participants
> * do recovery
> This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
> Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved JBEAP-4001 to WFLY-6442:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6442 (was: JBEAP-4001)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Transactions
(was: Transactions)
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 7.0.0.ER7)
Affects Testing: (was: Regression)
> Inconsistent behavior of journal object store for heuristic state
> -----------------------------------------------------------------
>
> Key: WFLY-6442
> URL: https://issues.jboss.org/browse/WFLY-6442
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
>
> We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
> Our test case:
> * enlist activemq JMS resource
> * enlist test XA resource
> * prepare JMS resource
> * prepare test XA resource
> * commit JMS resource
> * commit test XA resource
> ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
> 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
> * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
> ** expecting one indoubt participant in HEURISTIC state
> * calling operation {{recovery}} on all transaction's participants
> * do recovery
> This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
> Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6349) JMSXGroupId has no effect on JMSProducer
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6349?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6349:
-----------------------------------
You are right: there is indeed a bug in Artemis: https://issues.apache.org/jira/browse/ARTEMIS-462.
The workaround is to set the JMSXGroupID on the Message until Artemis fixes this bug.
Note that JMSXGroupSeq is an optional behaviour and your use case is valid. Messages must be grouped using JMSXGroupId regardless of the presence of the JMSXGroupSeq property
> JMSXGroupId has no effect on JMSProducer
> ----------------------------------------
>
> Key: WFLY-6349
> URL: https://issues.jboss.org/browse/WFLY-6349
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Harald Wellmann
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
>
> h3. Scenario
> I'm setting the {{JMSXGroupID}} on a {{JMSProducer}} to achieve message delivery in the correct order. The consumer is a message-driven bean.
> {code}
> JMSProducer producer = context.createProducer();
> producer = producer.setProperty("JMSXGroupID", "sequential");
> producer = producer.setProperty("foo", "bar");
> for (int i = 0; i < 50; i++) {
> msgNumber++;
> String text = "This is message " + msgNumber;
> producer.send(queue, text);
> }
> {code}
> h3. Expected Behaviour
> The messages are received in the correct order, the properties {{JMSXGroupID}} and {{foo}} are set on the receiver side.
> h3. Actual Behaviour
> The messages are received in random order. Property {{foo}} is set, but property {{JMSXGroupID}} is null on the receiver side.
> h3. Workaround
> Create a {{TextMessage}} and set the properties on the message, not on the producer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ]
Scott Marlow moved JBEAP-3999 to WFLY-6441:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6441 (was: JBEAP-3999)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JPA / Hibernate
(was: JPA / Hibernate)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
9.0.2.Final
JBoss AS7 7.2.0.Final
JBoss AS7 7.1.1.Final
(was: 7.0.0.GA)
> naming context is not setup when starting the persistence unit
> --------------------------------------------------------------
>
> Key: WFLY-6441
> URL: https://issues.jboss.org/browse/WFLY-6441
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 9.0.2.Final, JBoss AS7 7.2.0.Final, JBoss AS7 7.1.1.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> ookup of env-entry throws NameNotFoundException during persistence unit startup
> Version-Release number of selected component (if applicable):
> How reproducible:
> always
> Steps to Reproduce:
> 1. add env-entry in application.xml
> 2. try to lookup during persistent unit startup, e.g.
> public class MyType implements UserType {
> ...
> @Override
> public int[] sqlTypes() {
> try {
> Object ctx = new InitialContext().lookup("java:app/env");
> log.info("java:app/env from JPA = " + ctx);
> } catch (Exception e) {
> log.error("unable to get java:app/env from JPA", e);
> }
> return new int[] { Types.VARCHAR };
> }
> Actual results:
> NameNotFoundException
> Expected results:
> value of env-entry is available
> Additional info:
> On 21.03.2016 23:47, Stuart Douglas wrote:
> > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace
> >
> > Stuart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-6192:
-------------------------------------
As JAXB loads a customer classes, it needs the following permissions granted on the deployment (this cannot be running within a privileged block in JAXB):
{{new ReflectPermission("suppressAccessChecks")}}
{{new RuntimePermission("accessDeclaredMembers")}}
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6349) JMSXGroupId has no effect on JMSProducer
by Harald Wellmann (JIRA)
[ https://issues.jboss.org/browse/WFLY-6349?page=com.atlassian.jira.plugin.... ]
Harald Wellmann commented on WFLY-6349:
---------------------------------------
Thanks for this example - it turns out we're not quite looking at the same problem.
Your example also sets {{JMSXGroupSeq}} in addition to {{JMSXGroupId}}. I didn't set the former, in fact I wasn't aware of it, since it is not mentioned in https://activemq.apache.org/artemis/docs/1.1.0/message-grouping.html, nor in the latest HornetQ manual.
In your example, if you replace
{code}
producer.setProperty("JMSXGroupSeq", i).send(destination, text);
{code}
by
{code}
producer.send(destination, text);
{code}
you will also see the messages being received in random order. (Tried on a local build of 10.1.0-SNAPSHOT.)
But if you set the properties on the messages, not on the producer, the sequential order will be restored:
{code}
String text = "This is message " + (i + 1);
TextMessage textMessage = context.createTextMessage(text);
textMessage.setStringProperty("JMSXGroupID", "sequential");
textMessage.setStringProperty("foo", "bar");
producer.send(destination, textMessage); // textMessage, not text!
{code}
So maybe if this behaviour is coincidental, and if the basic rule is that JMSXGroupID should never be used without JMSGroupSeq, then at least the docs should be updated.
> JMSXGroupId has no effect on JMSProducer
> ----------------------------------------
>
> Key: WFLY-6349
> URL: https://issues.jboss.org/browse/WFLY-6349
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Harald Wellmann
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
>
> h3. Scenario
> I'm setting the {{JMSXGroupID}} on a {{JMSProducer}} to achieve message delivery in the correct order. The consumer is a message-driven bean.
> {code}
> JMSProducer producer = context.createProducer();
> producer = producer.setProperty("JMSXGroupID", "sequential");
> producer = producer.setProperty("foo", "bar");
> for (int i = 0; i < 50; i++) {
> msgNumber++;
> String text = "This is message " + msgNumber;
> producer.send(queue, text);
> }
> {code}
> h3. Expected Behaviour
> The messages are received in the correct order, the properties {{JMSXGroupID}} and {{foo}} are set on the receiver side.
> h3. Actual Behaviour
> The messages are received in random order. Property {{foo}} is set, but property {{JMSXGroupID}} is null on the receiver side.
> h3. Workaround
> Create a {{TextMessage}} and set the properties on the message, not on the producer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6349) JMSXGroupId has no effect on JMSProducer
by Harald Wellmann (JIRA)
[ https://issues.jboss.org/browse/WFLY-6349?page=com.atlassian.jira.plugin.... ]
Harald Wellmann reopened WFLY-6349:
-----------------------------------
> JMSXGroupId has no effect on JMSProducer
> ----------------------------------------
>
> Key: WFLY-6349
> URL: https://issues.jboss.org/browse/WFLY-6349
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Harald Wellmann
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
>
> h3. Scenario
> I'm setting the {{JMSXGroupID}} on a {{JMSProducer}} to achieve message delivery in the correct order. The consumer is a message-driven bean.
> {code}
> JMSProducer producer = context.createProducer();
> producer = producer.setProperty("JMSXGroupID", "sequential");
> producer = producer.setProperty("foo", "bar");
> for (int i = 0; i < 50; i++) {
> msgNumber++;
> String text = "This is message " + msgNumber;
> producer.send(queue, text);
> }
> {code}
> h3. Expected Behaviour
> The messages are received in the correct order, the properties {{JMSXGroupID}} and {{foo}} are set on the receiver side.
> h3. Actual Behaviour
> The messages are received in random order. Property {{foo}} is set, but property {{JMSXGroupID}} is null on the receiver side.
> h3. Workaround
> Create a {{TextMessage}} and set the properties on the message, not on the producer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBEE-166) Permission check failures when running with Security Manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/JBEE-166?page=com.atlassian.jira.plugin.s... ]
Ivo Studensky updated JBEE-166:
-------------------------------
Git Pull Request: https://github.com/jboss/jboss-jaxb-api_spec/pull/4
> Permission check failures when running with Security Manager enabled
> --------------------------------------------------------------------
>
> Key: JBEE-166
> URL: https://issues.jboss.org/browse/JBEE-166
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jaxb-api
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> When running with Security Manager enabled there are two failures due to:
> 1. RuntimePermission("getClassLoader"), see the stacktrace:
> {noformat}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
> 2. and FilePermission("modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar", "read"), the stacktrace is as follows:
> {noformat}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "....../jboss-eap/dist/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar" "read")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.<init>(ZipFile.java:210)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I believe these two places are worth enclosing with a privileged block.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months