[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky commented on DROOLS-2122:
-------------------------------------------
Or we could load jar files of the user defined runtime and use its kie api.
> Error when drl file is opened with in project with runtime classes
> -------------------------------------------------------------------
>
> Key: DROOLS-2122
> URL: https://issues.jboss.org/browse/DROOLS-2122
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.3.0.Final
> Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
> Reporter: Tomas David
> Assignee: Kris Verlaenen
> Priority: Blocker
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky edited comment on DROOLS-2122 at 11/10/17 11:34 AM:
----------------------------------------------------------------------
Or we could load jar files of the user defined runtime at runtime and use its kie api.
was (Author: apodhrad):
Or we could load jar files of the user defined runtime and use its kie api.
> Error when drl file is opened with in project with runtime classes
> -------------------------------------------------------------------
>
> Key: DROOLS-2122
> URL: https://issues.jboss.org/browse/DROOLS-2122
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.3.0.Final
> Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
> Reporter: Tomas David
> Assignee: Kris Verlaenen
> Priority: Blocker
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky commented on DROOLS-2122:
-------------------------------------------
Maybe we could change the logic for getting properties from the kie.conf at
{code:title=ServiceDiscoveryImpl [line: 112] loadConfs(URL url)}
private Properties loadConfs(URL url) {
// iterate urls, then for each url split the service key and attempt to register each service
Properties props = new Properties();
try (InputStream is = url.openStream()) {
props.load( is );
log.info("Discovered kie.conf url={} ", url);
} catch (Exception exc) {
throw new RuntimeException("Unable to build kie service url = " + url.toExternalForm(), exc);
}
return props;
}
{code}
> Error when drl file is opened with in project with runtime classes
> -------------------------------------------------------------------
>
> Key: DROOLS-2122
> URL: https://issues.jboss.org/browse/DROOLS-2122
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.3.0.Final
> Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
> Reporter: Tomas David
> Assignee: Kris Verlaenen
> Priority: Blocker
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky commented on DROOLS-2122:
-------------------------------------------
And the original exception
{code}
Caused by: java.lang.ClassNotFoundException: [],
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.kie.api.internal.utils.ServiceDiscoveryImpl.newInstance(ServiceDiscoveryImpl.java:157)
... 34 more
{code}
is cause by
{code:title=jboss-brms-6.4-engine/optaplanner-core-6.5.0.Final-redhat-16.jar META-INF/kie.conf}
[
'assemblers' : [new org.optaplanner.core.impl.solver.kie.KieSolverAssemblerService()],
'weavers' : [],
'runtimes' : [],
'beliefs' : []
]
{code}
with 'runtimes' : [],
> Error when drl file is opened with in project with runtime classes
> -------------------------------------------------------------------
>
> Key: DROOLS-2122
> URL: https://issues.jboss.org/browse/DROOLS-2122
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.3.0.Final
> Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
> Reporter: Tomas David
> Assignee: Kris Verlaenen
> Priority: Blocker
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky commented on DROOLS-2122:
-------------------------------------------
The problem is probably with parsing the file META-INF/kie.conf
{code:title=drools-distribution-6.5.0.Final/binaries/drools-beliefs-6.5.0.Final.jar META-INF/kie.conf}
[
'assemblers' : [ new org.drools.beliefs.bayes.assembler.BayesAssemblerService() ],
'weavers' : [ new org.drools.beliefs.bayes.weaver.BayesWeaverService() ],
'runtimes' : [ new org.drools.beliefs.bayes.runtime.BayesRuntimeService() ],
'beliefs' : [ ]
]
{code}
versus
{code:title=drools-distribution-7.4.1.Final/binaries/drools-beliefs-7.4.1.Final.jar META-INF/kie.conf}
org.kie.api.internal.assembler.KieAssemblers = +org.drools.beliefs.bayes.assembler.BayesAssemblerService
org.kie.api.internal.runtime.KieRuntimes = +org.drools.beliefs.bayes.runtime.BayesRuntimeService
org.kie.api.internal.weaver.KieWeavers = +org.drools.beliefs.bayes.weaver.BayesWeaverService
{code}
In the first case (Drools 6.x) the code fails on
{code:title=ServiceDiscoveryImpl [line: 157] - newInstance(ClassLoader, String)}
Class.forName( className, true, classLoader ).newInstance();
{code}
where className is "[ new org.drools.beliefs.bayes.runtime.BayesRuntimeService() ],"
> Error when drl file is opened with in project with runtime classes
> -------------------------------------------------------------------
>
> Key: DROOLS-2122
> URL: https://issues.jboss.org/browse/DROOLS-2122
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.3.0.Final
> Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
> Reporter: Tomas David
> Assignee: Kris Verlaenen
> Priority: Blocker
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
David Lloyd updated WFCORE-3073:
--------------------------------
Description:
The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal. To achieve a -clean- graceful shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
was:
The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
> Handle TERM gracefully
> ----------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha3
>
>
> The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal. To achieve a -clean- graceful shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-8380) Xerces usage tests fail with security manager on IBM JDK
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-8380?page=com.atlassian.jira.plugin.... ]
Ingo Weiss reassigned WFLY-8380:
--------------------------------
Assignee: Ingo Weiss
> Xerces usage tests fail with security manager on IBM JDK
> --------------------------------------------------------
>
> Key: WFLY-8380
> URL: https://issues.jboss.org/browse/WFLY-8380
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Environment: IBM JDK
> Reporter: Jan Tymel
> Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.xerces.unit.XercesUsageTestCase*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageTestCase -Dsecurity.manager}}
> *org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XercesUsageInWebServiceTestCase -Dsecurity.manager}}
> {code}
> 14:39:06,214 WARN [org.jboss.modules] (ServerService Thread Pool -- 27) Failed to define class org.apache.xerces.impl.xs.XMLSchemaValidator in Module "deployment.xerces-usage-jsf.ear" from Service Module Loader: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1655)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481)
> at java.lang.J9VMInternals$2.run(J9VMInternals.java:259)
> at java.security.AccessController.doPrivileged(AccessController.java:620)
> at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:346)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77)
> at org.jboss.modules.Module.loadModuleClass(Module.java:708)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
> at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 14:39:06,227 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 27) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader")
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:453)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:205)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$734.00000000144B0DE0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$735.00000000143DD4D0.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-usage-jsf.ear/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-usage-jsf.ear" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1655)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:481)
> at java.lang.J9VMInternals$2.run(J9VMInternals.java:259)
> at java.security.AccessController.doPrivileged(AccessController.java:620)
> at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:257)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:346)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:358)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77)
> at org.jboss.modules.Module.loadModuleClass(Module.java:708)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
> at __redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:123)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:402)
> ... 25 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Kris Verlaenen commented on DROOLS-2122:
----------------------------------------
[~tomasdavidorg] which runtime are you using?
> Error when drl file is opened with in project with runtime classes
> -------------------------------------------------------------------
>
> Key: DROOLS-2122
> URL: https://issues.jboss.org/browse/DROOLS-2122
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.3.0.Final
> Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
> Reporter: Tomas David
> Assignee: Kris Verlaenen
> Priority: Blocker
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months