April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Juraci Paixão Kröhling updated WFLY-3313: ----------------------------------------- Attachment: websocket-different-principals-ejb-vs-socket.png > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Affects Versions: 8.1.0.CR1, 10.0.0.Final > Reporter: Markus D > Assignee: Jason Greene > Attachments: websocket-different-principals-ejb-vs-socket.png > > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Juraci Paixão Kröhling edited comment on WFLY-3313 at 4/13/16 4:19 AM: ----------------------------------------------------------------------- Apparently, this is still happening. Using the [javaee7-samples' "websocket/endpoint-security"|http://blog.arungupta.me/securing-websockets-username-password-servlet-security-techtip49/] as base and using the following code, I get the proper user on the WS Session's principal and anonymous on EJB's session context. {code} @ServerEndpoint(value = "/websocket") @Stateless public class MyEndpoint { @SuppressWarnings("EjbEnvironmentInspection") @Resource SessionContext sessionContext; @OnMessage public String echoText(Session session, String text) { Principal sessionP = session.getUserPrincipal(); Principal p = sessionContext.getCallerPrincipal(); return text; } } {code} was (Author: juraci.costa): Apparently, this is still happening. > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Affects Versions: 8.1.0.CR1, 10.0.0.Final > Reporter: Markus D > Assignee: Jason Greene > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Juraci Paixão Kröhling updated WFLY-3313: ----------------------------------------- Affects Version/s: 10.0.0.Final > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Affects Versions: 8.1.0.CR1, 10.0.0.Final > Reporter: Markus D > Assignee: Jason Greene > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Juraci Paixão Kröhling commented on WFLY-3313: ---------------------------------------------- Apparently, this is still happening. > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Affects Versions: 8.1.0.CR1, 10.0.0.Final > Reporter: Markus D > Assignee: Jason Greene > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1117) After 2 times loading the same Rule 3rd time its not loading, Even No error occured

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1117?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1117. --------------------------------- Resolution: Cannot Reproduce Bug I cannot reproduce this issue. If you can provide a reproducer feel free to reopen this and attach your reproducer here. > After 2 times loading the same Rule 3rd time its not loading, Even No error occured > ----------------------------------------------------------------------------------- > > Key: DROOLS-1117 > URL: https://issues.jboss.org/browse/DROOLS-1117 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.CR2 > Reporter: Vivek Singh > Assignee: Mario Fusco > > While Loading the Rules in Server, After that i removed the Rule from KieBase then again > added the Rule By creating the newJar with different ReleaseId but same Drl filename. > Then i again removed the rule from KieBase using same command > kieBase.removeRule(kiePackage.getName(), ruleName); > But after that when i again added the same Rule it will not adding into the KieBase Knowledge packages. Even i am not getting any error. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1116) After adding new Rule by different drl filename getting error while calling fireRules

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1116?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1116. --------------------------------- Resolution: Cannot Reproduce Bug I cannot reproduce this issue. If you can provide a reproducer feel free to reopen this and attach your reproducer here. > After adding new Rule by different drl filename getting error while calling fireRules > ------------------------------------------------------------------------------------- > > Key: DROOLS-1116 > URL: https://issues.jboss.org/browse/DROOLS-1116 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.CR2 > Reporter: Vivek Singh > Assignee: Mario Fusco > > Issue is similar to https://issues.jboss.org/browse/DROOLS-978 > But its showing its fixed in 6.4.0.Beta1 but i am still lfacing in 6.4.0.CR2 > While Adding the new or Updated Rules by createKieJar. > Even renaming the Drool file. > After that while calling the fireRules i am getting the below error:- > Exception in thread "main" java.lang.NullPointerException > at org.drools.core.reteoo.NodeTypeEnums.isBetaNode(NodeTypeEnums.java:88) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:254) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:65) > at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:1004) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:961) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6513) Provide an option to configure Weld global thread pool size

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6513?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-6513: ------------------------------------ No, it's correct. The thread pool is used primarily for parallel Weld bootstrap in Weld 2.3 (in Weld 3 alphas it's also used for async events - CDI 2.0 preview). That means it is used *during bootstrap* of Weld container *for each CDI-enabled deployment*. > Provide an option to configure Weld global thread pool size > ------------------------------------------------------------ > > Key: WFLY-6513 > URL: https://issues.jboss.org/browse/WFLY-6513 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld > Reporter: Tomas Remes > Assignee: Martin Kouba > Priority: Minor > > As mentioned in https://issues.jboss.org/browse/WFLY-4653 it could be useful to have an option to configure Weld thread pool size e.g. in standalone configuration. Currently the size of the thread pool is hardcoded at https://github.com/wildfly/wildfly/blob/master/weld/src/main/java/org/jbo... > However note that this thread pool is used ONLY during the bootstrap of the Weld container. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6513) Provide an option to configure Weld global thread pool size

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-6513?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda commented on WFLY-6513: ----------------------------------------- does it mean "However note that this thread pool is used ONLY during the bootstrap of the Weld container." from description is not correct ? > Provide an option to configure Weld global thread pool size > ------------------------------------------------------------ > > Key: WFLY-6513 > URL: https://issues.jboss.org/browse/WFLY-6513 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld > Reporter: Tomas Remes > Assignee: Martin Kouba > Priority: Minor > > As mentioned in https://issues.jboss.org/browse/WFLY-4653 it could be useful to have an option to configure Weld thread pool size e.g. in standalone configuration. Currently the size of the thread pool is hardcoded at https://github.com/wildfly/wildfly/blob/master/weld/src/main/java/org/jbo... > However note that this thread pool is used ONLY during the bootstrap of the Weld container. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1119) Timers serialization not working with huge ids

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1119?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1119. ------------------------------- Fix Version/s: 7.0.0.Final Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/dae76dcf996969b1804e4ccf72f67... > Timers serialization not working with huge ids > ---------------------------------------------- > > Key: DROOLS-1119 > URL: https://issues.jboss.org/browse/DROOLS-1119 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 7.0.0.Final > > > Using huge ids for KieSessions corrupts timers serialization -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6513) Provide an option to configure Weld global thread pool size

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6513?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-6513: ------------------------------------ No, it's not shut down because it's shared across all CDI-enabled deployments. > Provide an option to configure Weld global thread pool size > ------------------------------------------------------------ > > Key: WFLY-6513 > URL: https://issues.jboss.org/browse/WFLY-6513 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld > Reporter: Tomas Remes > Assignee: Martin Kouba > Priority: Minor > > As mentioned in https://issues.jboss.org/browse/WFLY-4653 it could be useful to have an option to configure Weld thread pool size e.g. in standalone configuration. Currently the size of the thread pool is hardcoded at https://github.com/wildfly/wildfly/blob/master/weld/src/main/java/org/jbo... > However note that this thread pool is used ONLY during the bootstrap of the Weld container. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 April 2016