November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2487) Missing test for management API version 1.2

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-2487: ------------------------------------ Summary: Missing test for management API version 1.2 Key: WFLY-2487 URL: https://issues.jboss.org/browse/WFLY-2487 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.0.0.Beta1 Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 8.0.0.CR1 https://github.com/wildfly/wildfly/pull/5443#issuecomment-28098182 -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-336) Property Reactivity fails on phreak

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-336?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-336: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1029071 > Property Reactivity fails on phreak > ----------------------------------- > > Key: DROOLS-336 > URL: https://issues.jboss.org/browse/DROOLS-336 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > In LeftInputAdapterNode a modifyByPass happens, for a sink that has not been reached before. So it thinks it's new, and thus propagates as an insert > The real bug comes in doInsertObject method. It creates a child LT here, even though once it enters doInsertSegmentMemory the mask intersect fails. This leaves a child LT, that is not propagated. Next time update is called, as the LT is there it thinks it's a modify and propagates as a modify - but it never reached the beta node or the LeftMemory, and thus the memory corruption. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-336) Property Reactivity fails on phreak

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-336?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-336: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> made a comment on [bug 1029071|https://bugzilla.redhat.com/show_bug.cgi?id=1029071] In LeftInputAdapterNode a modifyByPass happens, for a sink that has not been reached before. So it thinks it's new, and thus propagates as an insert The real bug comes in doInsertObject method. It creates a child LT here, even though once it enters doInsertSegmentMemory the mask intersect fails. This leaves a child LT, that is not propagated. Next time update is called, as the LT is there it thinks it's a modify and propagates as a modify - but it never reached the beta node or the LeftMemory, and thus the memory corruption. I managed to isolate the problem with the failing test case I am pasting below. Note that if you remove the @PropertyReactive annotation from the Hero class the test becomes green. @Test public void testWumpus() { String drl = "import org.drools.compiler.integrationtests.Misc2Test.Hero;\n" + "import org.drools.compiler.integrationtests.Misc2Test.StepForwardCommand;\n" + "import org.drools.compiler.integrationtests.Misc2Test.ChangeDirectionCommand;\n" + "\n" + "rule RotateLeft when\n" + " $h : Hero( goingRight == true )\n" + " $dc : ChangeDirectionCommand()\n" + "then\n" + " retract ( $dc ); \n" + " modify ( $h ) { setGoingRight( false ) };\n" + "end\n" + "\n" + "rule RotateRight when\n" + " $h : Hero( goingRight == false )\n" + " $dc : ChangeDirectionCommand()\n" + "then\n" + " retract ( $dc ); \n" + " modify ( $h ) { setGoingRight( true ) };\n" + "end\n" + "\n" + "rule StepLeft when\n" + " $h : Hero( goingRight == false )\n" + " $sc : StepForwardCommand()\n" + "then\n" + " retract ( $sc ); \n" + " modify ( $h ) { setPos( $h.getPos()-1 ) };\n" + "end\n" + "\n" + "rule StepRight when\n" + " $h : Hero( goingRight == true )\n" + " $sc : StepForwardCommand()\n" + "then\n" + " retract ( $sc );\n" + " modify ( $h ) { setPos( $h.getPos()+1 ) };\n" + "end\n"; KnowledgeBuilderConfiguration kbConf = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(); KnowledgeBase kbase = loadKnowledgeBaseFromString( kbConf, drl ); StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession(); Hero hero = new Hero(1); ksession.insert(hero); ksession.fireAllRules(); ksession.insert(new StepForwardCommand()); ksession.fireAllRules(); ksession.insert(new StepForwardCommand()); ksession.fireAllRules(); assertEquals(3, hero.getPos()); ksession.insert(new ChangeDirectionCommand()); ksession.fireAllRules(); ksession.insert(new StepForwardCommand()); ksession.fireAllRules(); assertEquals(2, hero.getPos()); } @PropertyReactive public static class Hero { private int pos = 1; private boolean goingRight = true; public Hero(int pos) { this.pos = pos; } public int getPos() { return pos; } public void setPos(int pos) { this.pos = pos; } public boolean isGoingRight() { return goingRight; } public void setGoingRight(boolean goingRight) { this.goingRight = goingRight; } } public static class ChangeDirectionCommand { } public static class StepForwardCommand { } > Property Reactivity fails on phreak > ----------------------------------- > > Key: DROOLS-336 > URL: https://issues.jboss.org/browse/DROOLS-336 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > In LeftInputAdapterNode a modifyByPass happens, for a sink that has not been reached before. So it thinks it's new, and thus propagates as an insert > The real bug comes in doInsertObject method. It creates a child LT here, even though once it enters doInsertSegmentMemory the mask intersect fails. This leaves a child LT, that is not propagated. Next time update is called, as the LT is there it thinks it's a modify and propagates as a modify - but it never reached the beta node or the LeftMemory, and thus the memory corruption. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-140) KIE module injection through CDI does not work in container

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-140?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-140: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> made a comment on [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193] Hi Kanchan, I propose the following changes to the doc text: Cause: The KIE module injection through CDI did not work in container as the new Drools resource loading mechanism was incompatible with the JBoss EAP application server environment which uses the JBoss VFS. Consequence: Drools was unable to load the KieModule on the web application classpath as the KieModule's pom.properties file could not be located by Drools resource loading mechanism when using JBoss VFS. Fix: The Drools resource loading mechanism has been updated to handle VFS resources correctly. Result: CDI injection of Drools KieBase and KieSession with EAP is now working. > KIE module injection through CDI does not work in container > ----------------------------------------------------------- > > Key: DROOLS-140 > URL: https://issues.jboss.org/browse/DROOLS-140 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.0.CR1 > > > Description of problem: > Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject. > Version-Release number of selected component (if applicable): > BRMS 6.0.0.Beta1 > EAP 6.0, 6.1.ER4 > How reproducible: > Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log): > 15:40:29,923 INFO [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml > 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found > /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar > The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong. > Steps to Reproduce: > 1. Deploy attached reproducer WAR on EAP 6. > 2. Watch server.log for deployment errors. > > Actual results: > Deployment fails due to failed injection. > Expected results: > Application deploys successfully and writes INFO message into server.log. > Additional info: > This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI). -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2383) resource-adapter id attribute has to match ra name otherwise MDB is not deployed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2383: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] from ON_QA to ASSIGNED > resource-adapter id attribute has to match ra name otherwise MDB is not deployed > -------------------------------------------------------------------------------- > > Key: WFLY-2383 > URL: https://issues.jboss.org/browse/WFLY-2383 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2383) resource-adapter id attribute has to match ra name otherwise MDB is not deployed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2383: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] Ok, it seems that this works for creating modules but this does not work for archive deployments. You have to set the id of resource adapter to name of archive with or without ".rar". Otherwise the rar is not loaded for the MDB. But I would suppose that it should be possible to set whatever string to the id. At least it worked in EAP 6.1.1.GA. When you configure resource adapter as archive then you can set it like: <subsystem xmlns="urn:jboss:domain:ejb3:1.4"> <mdb> <resource-adapter-ref resource-adapter-name="activemq.file.rar"/> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/> </mdb> ... <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"> <resource-adapters> <resource-adapter id="activemq.file">  <archive>activemq.file.rar</archive> > resource-adapter id attribute has to match ra name otherwise MDB is not deployed > -------------------------------------------------------------------------------- > > Key: WFLY-2383 > URL: https://issues.jboss.org/browse/WFLY-2383 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2428) MDBs should use the full identifier of the resource adapter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2428?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2428: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] from ON_QA to ASSIGNED > MDBs should use the full identifier of the resource adapter > ----------------------------------------------------------- > > Key: WFLY-2428 > URL: https://issues.jboss.org/browse/WFLY-2428 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Fix For: 8.0.0.CR1 > > > The .rar suffix shouldn't be stripped anymore, as the resource adapters are registered under their full name. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2428) MDBs should use the full identifier of the resource adapter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2428?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2428: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] Ok, it seems that this works for creating modules but this does not work for archive deployments. You have to set the id of resource adapter to name of archive with or without ".rar". Otherwise the rar is not loaded for the MDB. But I would suppose that it should be possible to set whatever string to the id. At least it worked in EAP 6.1.1.GA. When you configure resource adapter as archive then you can set it like: <subsystem xmlns="urn:jboss:domain:ejb3:1.4"> <mdb> <resource-adapter-ref resource-adapter-name="activemq.file.rar"/> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/> </mdb> ... <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"> <resource-adapters> <resource-adapter id="activemq.file">  <archive>activemq.file.rar</archive> > MDBs should use the full identifier of the resource adapter > ----------------------------------------------------------- > > Key: WFLY-2428 > URL: https://issues.jboss.org/browse/WFLY-2428 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Fix For: 8.0.0.CR1 > > > The .rar suffix shouldn't be stripped anymore, as the resource adapters are registered under their full name. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1597) Re-Review TLS/SSL where http-upgrade is in use.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1597?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1597: ----------------------------------- Issue Type: Task (was: Feature Request) > Re-Review TLS/SSL where http-upgrade is in use. > ----------------------------------------------- > > Key: WFLY-1597 > URL: https://issues.jboss.org/browse/WFLY-1597 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 8.0.0.CR1 > > > Need to double check the behaviour here, the wrapping of Remoting so far it leaving the Remoting specific messages as-is - need to verify we are not double encrypting the connection and also the Client Cert based authentication requirements on that connection. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1113) JCA 1.6: 16.4.4 CallbackSecurity mapping not found

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1113?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1113. ---------------------------------- Resolution: Rejected Use the forum for discussions. Security inflow configuration has been supported since IJ 1.1 > JCA 1.6: 16.4.4 CallbackSecurity mapping not found > -------------------------------------------------- > > Key: JBJCA-1113 > URL: https://issues.jboss.org/browse/JBJCA-1113 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.14.Final > Reporter: Martin Keller > Assignee: Jesper Pedersen > > In the package "package org.jboss.jca.core.workmanager;" we found inside the Source "WorkWrapper.java" the following code part containing the comment > " // JCA 1.6: 16.4.4 " instead of an implementation of a "real"security mapping. > When will security mapping become available ? > List<Callback> callbacks = new ArrayList<Callback>(); > if (workManager.getCallbackSecurity().isMappingRequired()) > { > // JCA 1.6: 16.4.4 > } > if (workManager.getCallbackSecurity().getDefaultPrincipal() != null) > { > Principal defaultPrincipal = workManager.getCallbackSecurity().getDefaultPrincipal(); > CallerPrincipalCallback cpc = > new CallerPrincipalCallback(executionSubject, defaultPrincipal); > callbacks.add(cpc); > } > if (workManager.getCallbackSecurity().getDefaultGroups() != null) > { > String[] defaultGroups = workManager.getCallbackSecurity().getDefaultGroups(); > GroupPrincipalCallback gpc = > new GroupPrincipalCallback(executionSubject, defaultGroups); > callbacks.add(gpc); > } > if (callbacks.size() > 0) > { > Callback[] cb = new Callback[callbacks.size()]; > cbh.handle(callbacks.toArray(cb)); > } -- 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

12 years, 6 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 November 2013