[JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4126:
--------------------------------------
Are there any other exceptions earlier in the log? Looking at the code it does not seem obvious how this could be null.
> java.lang.ExceptionInInitializerError when invoking BIRT service
> ----------------------------------------------------------------
>
> Key: WFLY-4126
> URL: https://issues.jboss.org/browse/WFLY-4126
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 and JDK 1.8
> Reporter: Chezy Palani
> Assignee: Stuart Douglas
>
> There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception.
> Context Path:
> /actuatejavacomponent
> Servlet Path:
> /iv
> Path Info:
> null
> Query String:
> __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US
> Stack Trace
> javax.servlet.ServletException: java.lang.ExceptionInInitializerError
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261)
> com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144)
> com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (WFLY-3518) JASPIAuthenticationMechanism#authenticate doesn't check if AuthenticatedSession is null
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-3518?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-3518:
-----------------------------------
Just wondering if there's any update for this issue.
We've been using the extra null check in production since June. At least for our use case we didn't see any side-effects.
> JASPIAuthenticationMechanism#authenticate doesn't check if AuthenticatedSession is null
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3518
> URL: https://issues.jboss.org/browse/WFLY-3518
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: arjan tijms
> Assignee: Darran Lofthouse
> Labels: jaspic
>
> In {{org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism#authenticate}} the variable {{authSession}} in the fragment below is frequently null, leading to null pointer exceptions:
> {code}
> if (sessionManager != null) {
> AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange);
> cachedAccount = authSession.getAccount(); // NPE HAPPENS HERE
> // if there is a cached account we set it in the security context so that the principal is available to
> // SAM modules via request.getUserPrincipal().
> if (cachedAccount != null) {
> jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount);
> }
> }
> {code}
> At another place in Undertow where {{AuthenticatedSession}} is used, there's an extra null check (See {{io.undertow.security.impl.CachedAuthenticatedSessionMechanism#runCached}}).
> I patched the code locally to add an extra null check:
> {code}
> if (sessionManager != null) {
> AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange);
> cachedAccount = authSession == null? null : authSession.getAccount();
> // if there is a cached account we set it in the security context so that the principal is available to
> // SAM modules via request.getUserPrincipal().
> if (cachedAccount != null) {
> jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount);
> }
> }
> {code}
> After a short amount of testing everything seems to be okay with that extra check.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from MODIFIED to ON_QA
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-57:
-----------------------------------------------
Emmanuel Hugonnet (ehsavoie) <ehugonne(a)redhat.com> changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from ON_QA to POST
> Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
> --------------------------------------------------------------------------------
>
> Key: WFCORE-57
> URL: https://issues.jboss.org/browse/WFCORE-57
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha4
> Reporter: Harald Pehl
> Assignee: Emmanuel Hugonnet
> Priority: Minor
> Fix For: 1.0.0.Alpha9
>
>
> When executing
> {code}
> /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
> {code}
> the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
> {code}
> ...
> "acl" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> "model-description" => {"classic" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> ...
> "operations" => undefined,
> "children" => {
> "acl-module" => {
> "description" => "ACL module",
> "model-description" => {"*" => {
> "description" => "List of authentication modules",
> ...
> "operations" => undefined,
> "children" => {}
> }}
> },
> "login-module" => {
> "description" => "Login module",
> "model-description" => {"*" => undefined}
> }
> }
> }}
> },
> ...
> {code}
> However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-654:
------------------------------------
Yes, sorry I forgot to mention this.
You can write this declaratively in the kmodule.xml file of your kproject. if you want you can also generate the kmodule.xml file programmatically and add it to the KieFileSystem, see an example here: https://github.com/droolsjbpm/drools/blob/master/kie-ci/src/test/java/org...
> Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mario Fusco
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić commented on DROOLS-654:
---------------------------------------
Thanks for clearing this up, but, is there another way to:
1. use Drools in Stream mode (I use window:time, so I need this), and
2. have the ability to update rules in runtime ?
> Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mario Fusco
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (DROOLS-657) Salience ignored when no-loop set
by Sebastien Chassande (JIRA)
Sebastien Chassande created DROOLS-657:
------------------------------------------
Summary: Salience ignored when no-loop set
Key: DROOLS-657
URL: https://issues.jboss.org/browse/DROOLS-657
Project: Drools
Issue Type: Bug
Affects Versions: 6.1.0.Final
Environment: Windows x64, java 7, eclipse
Reporter: Sebastien Chassande
Assignee: Mark Proctor
Priority: Blocker
Hello,
When we define the no-loop attribute on rules the salience is ignored. The rule execution order is the declaration order.
Best regards,
Seb
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (WFLY-4130) check for -secmgr in appclient
by Scott Marlow (JIRA)
Scott Marlow created WFLY-4130:
----------------------------------
Summary: check for -secmgr in appclient
Key: WFLY-4130
URL: https://issues.jboss.org/browse/WFLY-4130
Project: WildFly
Issue Type: Feature Request
Components: Application Client, Security Manager
Reporter: Scott Marlow
Assignee: James Perkins
Fix For: 9.0.0.Beta1
We are currently getting a TCK failure due to the security manager not being enabled in our application client container. We can pass the -secmgr option if that could be handled in the app container.
Current TCK error (in ejb30/sec/permsxml:
{quote}
ERROR: Security Manager is NOT enabled and must be for these tests. If you have passed these tests while running with Security Manager enabled, you can use keywords to bypass the running of these tests when Security Manager is disabled.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-654:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mario Fusco
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months