April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-576) Testsuite tasks (tracking)

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-576?page=com.atlassian.jira.plugin.s... ] Jason Greene moved AS7-2007 to WFLY-576: ---------------------------------------- Project: WildFly (was: Application Server 7) Key: WFLY-576 (was: AS7-2007) Component/s: Test Suite (was: Test Suite) > Testsuite tasks (tracking) > -------------------------- > > Key: WFLY-576 > URL: https://issues.jboss.org/browse/WFLY-576 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Attachments: checkMissedTests.sh > > > Post-7.1.1 jiras: AS7-4067 > Arquillian tasks affecting the testsuite: https://docspace.corp.redhat.com/docs/DOC-71831 > Maven wishes for summer: > * https://jira.codehaus.org/browse/MNG-5194 - Expression-based profile activation. > * http://jira.codehaus.org/browse/SUREFIRE-803 [IMPLEMENTED] > * http://jira.codehaus.org/browse/SUREFIRE-806 [IMPLEMENTED] > * http://jira.codehaus.org/browse/SUREFIRE-808 [OBSOLETED] or > * http://jira.codehaus.org/browse/SUREFIRE-809 [IMPLEMENTED] > * http://jira.codehaus.org/browse/MNG-5218 - ${basedir} in a property is re-resolved for each submodule; We need to have it optionally fixed. > * http://jira.codehaus.org/browse/MOJO-1812 - XML plugin's <onIdenticalResult>fail > * http://jira.codehaus.org/browse/SUREFIRE-827 - Regression in Surefire 2.12; Fixed in 2.12.1 > * http://jira.codehaus.org/browse/MANTRUN-172 - Properties passed to Maven as -D don't get passed to <ant> invocations when a profile sets the same property > * John's directory plugin [IMPLEMENTED]: http://repo1.maven.org/maven2/org/commonjava/maven/plugins/directory-mave... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-574) Find better solution to AS7-2815 than using EnumValidator to store the allowed value

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-574?page=com.atlassian.jira.plugin.s... ] Jason Greene moved AS7-3611 to WFLY-574: ---------------------------------------- Project: WildFly (was: Application Server 7) Key: WFLY-574 (was: AS7-3611) Component/s: Domain Management (was: Domain Management) Fix Version/s: 9.0.0.CR1 (was: 9.0.0.CR1) > Find better solution to AS7-2815 than using EnumValidator to store the allowed value > ------------------------------------------------------------------------------------ > > Key: WFLY-574 > URL: https://issues.jboss.org/browse/WFLY-574 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 9.0.0.CR1 > > > AS7-2815 solution uses a hack in EnumValidator to store the allowed value instead of the user provided value. That goes beyond the contract of a "validate" method. See if something better can be found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-575) Remove WriteAttributeHandlers

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-575?page=com.atlassian.jira.plugin.s... ] Jason Greene moved AS7-6205 to WFLY-575: ---------------------------------------- Project: WildFly (was: Application Server 7) Key: WFLY-575 (was: AS7-6205) Component/s: Domain Management (was: Domain Management) Fix Version/s: 9.0.0.CR1 (was: 9.0.0.CR1) > Remove WriteAttributeHandlers > ----------------------------- > > Key: WFLY-575 > URL: https://issues.jboss.org/browse/WFLY-575 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 9.0.0.CR1 > > > Parent task deprecates in 7.2; this task is to remove. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6205) Remove WriteAttributeHandlers

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/AS7-6205?page=com.atlassian.jira.plugin.s... ] Jason Greene updated AS7-6205: ------------------------------ Parent: (was: AS7-6201) Issue Type: Task (was: Sub-task) > Remove WriteAttributeHandlers > ----------------------------- > > Key: AS7-6205 > URL: https://issues.jboss.org/browse/AS7-6205 > Project: Application Server 7 > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 9.0.0.CR1 > > > Parent task deprecates in 7.2; this task is to remove. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-3611) Find better solution to AS7-2815 than using EnumValidator to store the allowed value

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/AS7-3611?page=com.atlassian.jira.plugin.s... ] Jason Greene updated AS7-3611: ------------------------------ Parent: (was: AS7-2815) Issue Type: Task (was: Sub-task) > Find better solution to AS7-2815 than using EnumValidator to store the allowed value > ------------------------------------------------------------------------------------ > > Key: AS7-3611 > URL: https://issues.jboss.org/browse/AS7-3611 > Project: Application Server 7 > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 9.0.0.CR1 > > > AS7-2815 solution uses a hack in EnumValidator to store the allowed value instead of the user provided value. That goes beyond the contract of a "validate" method. See if something better can be found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-193) JCA workmanager and bootstrap-context "name" attributes should not support expressions

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-193?page=com.atlassian.jira.plugin.s... ] Jason Greene moved AS7-6222 to WFLY-193: ---------------------------------------- Project: WildFly (was: Application Server 7) Key: WFLY-193 (was: AS7-6222) Component/s: Domain Management JCA (was: Domain Management) (was: JCA) Fix Version/s: 8.0.0.Alpha1 (was: EAP 6.1.0.Alpha (7.2.0.Final)) > JCA workmanager and bootstrap-context "name" attributes should not support expressions > -------------------------------------------------------------------------------------- > > Key: WFLY-193 > URL: https://issues.jboss.org/browse/WFLY-193 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, JCA > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > These "name" attributes represent part of the address of a resource. Resource address elements cannot support expressions, because their value needs to be resolvable > 1) before all system property values are known > 2) on the master host controller, which may have different resolution sources from other HCs or the servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6790) Multi-JSF doesn't understand new modules structure

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/AS7-6790?page=com.atlassian.jira.plugin.s... ] Stan Silvert updated AS7-6790: ------------------------------ Git Pull Request: https://github.com/jbossas/jboss-as/pull/4425 Instead of installing JSF impls wherever you wish, it is recommended that you install into the root of the modules directory. However, if you do this then "main", which ships with AS, will no longer get added as a valid JSF configuration. Submitted https://github.com/jbossas/jboss-as/pull/4425 to make sure that "main" is always one of the valid JSF impl slots. A couple of updates are needed to the tool that creates the *.cli JSF impl install files. But since that tool is not part of the AS code base, I'm going to go ahead and close this jira once the PR is merged. > Multi-JSF doesn't understand new modules structure > -------------------------------------------------- > > Key: AS7-6790 > URL: https://issues.jboss.org/browse/AS7-6790 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Stan Silvert > Assignee: Stan Silvert > > With the new modules structure, Multi-JSF is looking for JSF implementations in the root of the modules directory instead of in modules/system/layers/base. The reason is that Multi-JSF relies on the module.path property which points to the root by default. > The workaround is to go ahead and install the new JSF impl wherever you wish and add that directory to JBOSS_MODULEPATH in the startup script. > See https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature#comment-11789 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-365) Java EE 7 Related Metadata

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/JBMETA-365?page=com.atlassian.jira.plugin... ] Eduardo Martins updated JBMETA-365: ----------------------------------- Git Pull Request: https://github.com/jboss/metadata/pull/46, https://github.com/jboss/metadata/pull/47 (was: https://github.com/jboss/metadata/pull/46) > Java EE 7 Related Metadata > -------------------------- > > Key: JBMETA-365 > URL: https://issues.jboss.org/browse/JBMETA-365 > Project: JBoss Metadata > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: client, common, ear, ejb, web > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > Provide support for Java EE 7: > - support new namespaces > - add new metadata + parsers/mergers for app client, ear, ejb and web > - add module for permissions.xml with metadata and parsers > - add unit tests for all the new stuff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6972) JBAS014884: No operation named 'composite' exists at address

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6972?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6972: --------------------------------------- Tomaz, no, composite is not a global op. > JBAS014884: No operation named 'composite' exists at address > ------------------------------------------------------------ > > Key: AS7-6972 > URL: https://issues.jboss.org/browse/AS7-6972 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Environment: RHEL 6, JDK 1.7 > Reporter: Van Halbert > Assignee: Tomaz Cerar > > I'm using EAP 6.1 ER5, and trying to execute the following using CLI: > > /profile=ha/subsystem=security/security-domain=teiid-security:add(cache-type=default) > /profile=ha/subsystem=security/security-domain=teiid-security/authentication=classic/:add(login-modules=[{"code"=>"org.jboss.security.auth.spi.UsersRolesLoginModule", "flag"=>"required", "module-options"=>[("usersProperties"=>"${jboss.domain.config.dir}/teiid-security-users.properties"), ("rolesProperties"=>"${jboss.domain.config.dir}/teiid-security-roles.properties")]}]) > but I get the message: > … > "failure-description" => "JBAS014884: No operation named 'composite' exists at address [ > … > (see forum for full discussion) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-107) NPE when inserting through rule (object already present as derived class)

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-107?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-107: --------------------------------------- Could you please try master (5.5.1-SNAPSHOT) ? I tried to reproduce it but I didn't get any exception. To be fair, I had to simplify Triple due to some missing dependencies, so I may have removed the bug as well :) > NPE when inserting through rule (object already present as derived class) > ------------------------------------------------------------------------- > > Key: DROOLS-107 > URL: https://issues.jboss.org/browse/DROOLS-107 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: % java -version > java version "1.7.0_21" > Java(TM) SE Runtime Environment (build 1.7.0_21-b11) > Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) > % uname -a > Linux oem-laptop 3.5.0-28-generic #47-Ubuntu SMP Tue Apr 9 19:03:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > Reporter: Jean-Marc Vanel > Assignee: Mark Proctor > > NPE : unit test which depends only on 3 non Drools simple classes : Assignment, Triple, TripleUser > unit test has 2 rules , 5 inserts, 3 fireAllRules : the last one makes the NPE. > TestDroolsNPE.testRunRulesBefore > testRunRulesBefore(eulergui.project.TestDroolsNPE) > Exception executing consequence for rule "project-java-rules2.n3 0" in project_java_rules2_n3_1: java.lang.NullPointerException > at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) > at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1297) > at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) > at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) > at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) > at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) > at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) > at eulergui.project.TestDroolsNPE.testRunRulesBefore(TestDroolsNPE.java:110) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at junit.framework.TestCase.runTest(TestCase.java:176) > at junit.framework.TestCase.runBare(TestCase.java:141) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:255) > at junit.framework.TestSuite.run(TestSuite.java:250) > at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.lang.NullPointerException > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:196) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:245) > at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:210) > at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:205) > at project_java_rules2_n3_1.Rule_project_java_rules2_n3_0_dd5596b676034b1fb5b32877015997e3.defaultConsequence(Rule_project_java_rules2_n3_0_dd5596b676034b1fb5b32877015997e3.java:12) > at project_java_rules2_n3_1.Rule_project_java_rules2_n3_0_dd5596b676034b1fb5b32877015997e3DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) > at project_java_rules2_n3_1.Rule_project_java_rules2_n3_0_dd5596b676034b1fb5b32877015997e3DefaultConsequenceInvoker.evaluate(Unknown Source) > at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) > ... 25 more > in class NamedEntryPoint : > > protected FactHandle insert(final Object object, > final Object tmsValue, > final boolean dynamic, > boolean logical, > final Rule rule, > final Activation activation) throws FactException { > if ( object == null ) { > // you cannot assert a null object > return null; > } > > try { > this.wm.startOperation(); > > ObjectTypeConf typeConf = this.typeConfReg.getObjectTypeConf( this.entryPoint, > object ); > if ( logical && !typeConf.isTMSEnabled()) { > enableTMS(object, typeConf); > } > > InternalFactHandle handle = null; > > if ( this.wm.isSequential() ) { > handle = createHandle( object, > typeConf ); > insert( handle, > object, > rule, > activation, > typeConf ); > return handle; > } > try { > this.lock.lock(); > this.ruleBase.readLock(); > // check if the object already exists in the WM > handle = this.objectStore.getHandleForObject( object ); > > if ( typeConf.isTMSEnabled() ) { > > EqualityKey key; > > TruthMaintenanceSystem tms = wm.getTruthMaintenanceSystem(); > if ( handle == null ) { > // lets see if the object is already logical asserted > key = tms.get( object ); > } else { > // Object is already asserted, so check and possibly correct its > // status and then return the handle > key = handle.getEqualityKey(); > > if ( key.getStatus() == EqualityKey.STATED ) { > > // key == null here !!!!!!!!!!!!!!!!!!! > // conf.setAssertBehaviour( AssertBehaviour.EQUALITY ); > > when rule inserts Triple : > <file:/home/jmv/src/eulergui-code/eulergui/test/import.n3p.n3> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2002/07/owl#Ontology> . > > that is already present, as a TripleUser extends Triple, but equals() and hashCode() are the same ; > this object is both asserted and inferred as a Triple object -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 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 April 2013