[JBoss JIRA] (DROOLS-1203) OptaPlanner on KIE Server running on Wildfly 9.0.2 throwing IllegalArgumentException on startup
by Jonathan Holmström (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1203?page=com.atlassian.jira.plugi... ]
Jonathan Holmström updated DROOLS-1203:
---------------------------------------
Affects Version/s: 6.4.0.Final
> OptaPlanner on KIE Server running on Wildfly 9.0.2 throwing IllegalArgumentException on startup
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-1203
> URL: https://issues.jboss.org/browse/DROOLS-1203
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Environment: Wildfly 9.0.2
> Reporter: Jonathan Holmström
> Assignee: Mark Proctor
>
> The following exception is thrown at startup. The server still starts successfully.
> [31m04:08:44,729 ERROR [org.kie.server.services.impl.KieServerImpl] (ServerService Thread Pool -- 65) Error when initializing server extension of type OptaPlanner KIE Server extension: java.lang.IllegalArgumentException
> at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1307)
> at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1195)
> at org.kie.server.services.optaplanner.OptaplannerKieServerExtension.init(OptaplannerKieServerExtension.java:75)
> at org.kie.server.services.impl.KieServerImpl.<init>(KieServerImpl.java:108)
> at org.kie.server.services.impl.KieServerLocator.<clinit>(KieServerLocator.java:20)
> at org.kie.server.services.Bootstrap.contextInitialized(Bootstrap.java:50)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1203) OptaPlanner on KIE Server running on Wildfly 9.0.2 throwing IllegalArgumentException on startup
by Jonathan Holmström (JIRA)
Jonathan Holmström created DROOLS-1203:
------------------------------------------
Summary: OptaPlanner on KIE Server running on Wildfly 9.0.2 throwing IllegalArgumentException on startup
Key: DROOLS-1203
URL: https://issues.jboss.org/browse/DROOLS-1203
Project: Drools
Issue Type: Bug
Environment: Wildfly 9.0.2
Reporter: Jonathan Holmström
Assignee: Mark Proctor
The following exception is thrown at startup. The server still starts successfully.
[31m04:08:44,729 ERROR [org.kie.server.services.impl.KieServerImpl] (ServerService Thread Pool -- 65) Error when initializing server extension of type OptaPlanner KIE Server extension: java.lang.IllegalArgumentException
at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1307)
at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1195)
at org.kie.server.services.optaplanner.OptaplannerKieServerExtension.init(OptaplannerKieServerExtension.java:75)
at org.kie.server.services.impl.KieServerImpl.<init>(KieServerImpl.java:108)
at org.kie.server.services.impl.KieServerLocator.<clinit>(KieServerLocator.java:20)
at org.kie.server.services.Bootstrap.contextInitialized(Bootstrap.java:50)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-1869) TP.registerProbeHandler not thread safe
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1869?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1869:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1336088|https://bugzilla.redhat.com/show_bug.cgi?id=1336088] from MODIFIED to ON_QA
> TP.registerProbeHandler not thread safe
> ---------------------------------------
>
> Key: JGRP-1869
> URL: https://issues.jboss.org/browse/JGRP-1869
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> TP.registerProbeHandlers is not thread safe since it modifies preregistered_probe_handlers outside of any synchronization.
> If a thread calls this method while another thread is inside startDiagnostics (which can happen easily with a shared transport), it can cause a NullPointerException when startDiagnostics is looping through preregistered_probe_handlers.
> Access to preregistered_probe_handlers should be synchronized.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6402:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1310908|https://bugzilla.redhat.com/show_bug.cgi?id=1310908] from MODIFIED to ON_QA
> EJBs accessible too early (spec violation)
> ------------------------------------------
>
> Key: WFLY-6402
> URL: https://issues.jboss.org/browse/WFLY-6402
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Fedor Gavrilov
> Labels: downstream_dependency
> Attachments: auto-test-reproducer.zip
>
>
> {code}
> EJB 3.1 spec, section 4.8.1:
> "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
> {code}
> Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-64) Filesystem deployment scanner deployment failure removes unrelated deployments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-64?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-64:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1291710|https://bugzilla.redhat.com/show_bug.cgi?id=1291710] from MODIFIED to ON_QA
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFCORE-64
> URL: https://issues.jboss.org/browse/WFCORE-64
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: ehsavoie Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-904) The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-904?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-904:
----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1330677|https://bugzilla.redhat.com/show_bug.cgi?id=1330677] from MODIFIED to ON_QA
> The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-904
> URL: https://issues.jboss.org/browse/WFLY-904
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Environment: Eclipse Juno SR2 with JBoss Tools, Mac OS X, Sun JDK 6
> Reporter: Fernando Nasser
> Assignee: Darran Lofthouse
> Labels: eap6, investigation_required
> Fix For: 9.0.0.CR1
>
> Attachments: NPEinSimpleSecurityManager, PBOX000075, QSecuredEJB.jar, QSecuredEJB.zip, SecurityRelatedSettings
>
>
> Description of problem:
> If one tries and use security enabled EJBs from a remote client (authenticated connection) before connecting first from a servlet both a Server NPE and an erroneous exception are thrown. However, if one uses some servlet-based authentication first, the missing field is "primed" and from that point on the remote application can use the secure EJBs normally, proper Role authorization is checked and enforced etc. With absolutely no changes in configuration, code (incl. annotation) whatsoever. Any number of remote client connections will succeed until you restart the server. Then the errors are back, until you "prime" the Server by connecting using a Servlet.
> More complete data is attached, but here are some info:
> NPE is thrown at:
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:394)
> Bean method invocation fails with exceptions containing the message:
> JBAS011048: Failed to construct component instance
> I am using the "other" security context for testing.
> I am running the Server in standalone mode.
> When I say remote I mean not in the Server, but I am running my client from localhost.
> Version-Release number of selected component (if applicable): Seen on EAP 6.1.0 alpha (apparently present on AS 7.1.1 as well).
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1495) server instances cannot find keytab during domain startup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1495?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1495:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1328997|https://bugzilla.redhat.com/show_bug.cgi?id=1328997] from MODIFIED to ON_QA
> server instances cannot find keytab during domain startup
> ---------------------------------------------------------
>
> Key: WFCORE-1495
> URL: https://issues.jboss.org/browse/WFCORE-1495
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Derek Horton
> Assignee: Vlado Pakan
> Fix For: 3.0.0.Alpha2
>
> Original Estimate: 4 days
> Time Spent: 3 days, 4 hours
> Remaining Estimate: 4 hours
>
> In domain mode, the server instances cannot find the keytab if the ApplicationRealm is configured to use kerberos as the server-identity:
> {code}
> <security-realm name="ApplicationRealm">
> <server-identities>
> <kerberos>
> <keytab principal="remote/imahost.imadomain.net@VM29" path="/path/to/keytab"/>
> </kerberos>
> </server-identities>
> <authentication>
> <kerberos remove-realm="true"/>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
> </authorization>
> </security-realm>
> {code}
> This results in the following error and the server instances fail to start:
> [Server:server-one] 15:10:35,360 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("validate-authentication") failed - address: ([
> [Server:server-one] ("core-service" => "management"),
> [Server:server-one] ("security-realm" => "ApplicationRealm")
> [Server:server-one] ]) - failure description: "WFLYDM0094: Kerberos is enabled for authentication on security realm 'ApplicationRealm' but no Keytab has been added to the server-identity."
> [Server:server-one] 15:10:35,376 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-64) Filesystem deployment scanner deployment failure removes unrelated deployments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-64?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-64:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1327093|https://bugzilla.redhat.com/show_bug.cgi?id=1327093] from MODIFIED to ON_QA
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFCORE-64
> URL: https://issues.jboss.org/browse/WFCORE-64
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: ehsavoie Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years