[JBoss JIRA] (WFCORE-1686) Standalone server logs FATAL message on --help
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1686?page=com.atlassian.jira.plugi... ]
Petr Kremensky moved JBEAP-5503 to WFCORE-1686:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1686 (was: JBEAP-5503)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Server
(was: Server)
Affects Version/s: 3.0.0.Alpha4
(was: 7.1.0.DR1)
Affects Testing: (was: Regression)
> Standalone server logs FATAL message on --help
> ----------------------------------------------
>
> Key: WFCORE-1686
> URL: https://issues.jboss.org/browse/WFCORE-1686
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 3.0.0.Alpha4
> Reporter: Petr Kremensky
> Assignee: Jason Greene
> Priority: Blocker
>
> {noformat}
> 15:07:56,793 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}
> appears at the end of help for standalone server.
> *reproduce*
> {noformat}
> bash standalone.sh --help
> {noformat}
> The issues is a regression against 7.0.0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-396) Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
by Kenny Wottrich (JIRA)
[ https://issues.jboss.org/browse/DROOLS-396?page=com.atlassian.jira.plugin... ]
Kenny Wottrich edited comment on DROOLS-396 at 8/2/16 9:08 AM:
---------------------------------------------------------------
-I had the same issue, and determined that it was caused by attempting to use Spring to inject a rules engine into a class that had other dependencies autowired in (as in, the rules engine was not autowired in, but all of the other dependencies were). The fix for me was to put all dependencies into the XML config, and not mix and match autowire and XML-
EDIT: Never mind. This fixed the issue for one bean, but did NOT fix the issue for another bean. I'm still searching for a solution.
was (Author: kenny.wottrich):
I had the same issue, and determined that it was caused by attempting to use Spring to inject a rules engine into a class that had other dependencies autowired in -- as in, the rules engine was not autowired in, but all of the other dependencies were. In our Spring XML config, I had:
<bean id="myBean" class="com.example.myBeanImpl" scope="request">
<aop:scoped-proxy />
<property name="rulesEngine" ref="rulesEngineDef" />
</bean>
I think the {{<aop:scoped-proxy />}} was causing it to try to set dependencies with different scopes.
*The fix for me was to put all dependencies into the XML config, and not mix and match autowire and XML*:
<bean id="myBean" class="com.example.myBeanImpl" scope="request">
<aop:scoped-proxy />
<property name="otherDependency" ref="otherDependencyDef" />
...
<property name="rulesEngine" ref="rulesEngineDef" />
</bean>
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-396
> URL: https://issues.jboss.org/browse/DROOLS-396
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: leonardo lizana
> Assignee: Petr Široký
> Priority: Critical
> Attachments: noclassdeffound.zip
>
>
> I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in org/drools/event/DebugProcessEventListener. instead of "org.drools.core.event.DebugProcessEventListener"
> is there anything that i'm doing bad?
> * with drools 5.5 everything is working OK.
> Here is my pom.xml
> --------------------------
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>knowledge-api</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-spring</artifactId>
> <version>5.5.0.Final</version>
> </dependency>
> here is the log error:
> ----------------------------
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
> at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
> at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
> at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
> at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
> at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
> at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
> at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
> at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
> Here is the contex-drools.xml
> -------------------------------------
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:context="http://www.springframework.org/schema/context"
> xmlns:drools="http://drools.org/schema/drools-spring"
> xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
> http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
> http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-containe..."
> default-autowire="byName">
>
> <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>
> <drools:kbase id="kBaseEnergyUsage">
> <drools:resources>
> <drools:resource ref="rulesEnergyUsage"/>
> </drools:resources>
> </drools:kbase>
> <drools:ksession id="kSessionEnergyUsage" kbase="kBaseEnergyUsage" type="stateful"/>
> </beans>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky commented on WFCORE-1682:
-------------------------------------------
We should revert WFCORE-1487 and JBEAP-4270. Apparently it introduces more problems than it fixes. There is a valid reason behind those issues but it seems they have to addressed differently.
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Petr Kremensky commented on WFCORE-1682:
----------------------------------------
I agree. What about JBEAP-5313 and JBEAP-4270. I can re-open JBEAP-5313, 7.0.2 is currently blocked by JBEAP-3602 so there should be enought time to revert PR for JBEAP-4270 as well.
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-462) DirContext suppliing service to be used in LDAP realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-462?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-462:
---------------------------
Description:
There will be DirContext suppling service, which will be referenced by realm:
* output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext()
was:
UPDATE: There will be DirContext suppling service, which will be referenced by realm:
* output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext()
> DirContext suppliing service to be used in LDAP realm
> -----------------------------------------------------
>
> Key: ELY-462
> URL: https://issues.jboss.org/browse/ELY-462
> Project: WildFly Elytron
> Issue Type: Task
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> There will be DirContext suppling service, which will be referenced by realm:
> * output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months