August 2016 - jboss-jira - Jboss List Archives

[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 updated WFCORE-1686: ----------------------------------- Priority: Major (was: Blocker) > 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 > > {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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-6907) Add log message with information that there is replacement (Credential Store) for Vaults

by Hynek Švábek (JIRA)

Hynek Švábek created WFLY-6907: ---------------------------------- Summary: Add log message with information that there is replacement (Credential Store) for Vaults Key: WFLY-6907 URL: https://issues.jboss.org/browse/WFLY-6907 Project: WildFly Issue Type: Enhancement Components: Security Reporter: Hynek Švábek Assignee: Peter Skopek There will be replacement for deprecated Password Vault System. It would be nice add there some log message e.g.: "Vaults are deprecated, please check Credential Store". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6906) Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated."

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6906?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6906: --------------------------------- Description: Integrate MANUAL mode introduced in ISPN-6911. > Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated." > ------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6906 > URL: https://issues.jboss.org/browse/WFLY-6906 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Integrate MANUAL mode introduced in ISPN-6911. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6906) Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated."

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6906?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6906: --------------------------------- Description: Integrate MANUAL eviction strategy introduced in ISPN-6911. (was: Integrate MANUAL mode introduced in ISPN-6911.) > Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated." > ------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6906 > URL: https://issues.jboss.org/browse/WFLY-6906 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Integrate MANUAL eviction strategy introduced in ISPN-6911. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6906) Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated."

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6906: ------------------------------------ Summary: Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated." Key: WFLY-6906 URL: https://issues.jboss.org/browse/WFLY-6906 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

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