March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created JGRP-1812: ----------------------------------------- Summary: ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages Key: JGRP-1812 URL: https://issues.jboss.org/browse/JGRP-1812 Project: JGroups Issue Type: Bug Affects Versions: 3.2.14 Environment: RHEL, Solaris Reporter: Richard Achmatowicz Assignee: Bela Ban Fix For: 3.2.14 ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following: - creates two channels A and B - creates a UDP-based shared transport stack - assigns the same stack to both channels - channel A connects to group cluster-one; channel B connects to group cluster-two - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group - the test then waits for the correct number of multicast messages to arrive Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages. This test fails intermittently, but fairly regularly. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] Alessio Soldano resolved WFLY-3067. ----------------------------------- Resolution: Done AFAICS this is solved by https://github.com/wildfly/wildfly/pull/6027 > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3067: ----------------------------------------------- Alessio Soldano <asoldano(a)redhat.com> changed the Status of [bug 1079084|https://bugzilla.redhat.com/show_bug.cgi?id=1079084] from NEW to ASSIGNED > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-3067: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/5992, https://github.com/wildfly/wildfly/pull/6027 (was: https://github.com/wildfly/wildfly/pull/5992) > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1019) Validate composite operation steps just before executing them

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1019?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-1019: ----------------------------------- Labels: EAP (was: ) > Validate composite operation steps just before executing them > ------------------------------------------------------------- > > Key: WFLY-1019 > URL: https://issues.jboss.org/browse/WFLY-1019 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Labels: EAP > > Say we have a composite operation with 2 steps: > 1) /extension=org.jboss.as.messaging:add > 2) /subsystem=messaging:add > This will fail: > Failed to execute batch: JBAS014739: No handler for add at address > [("subsystem" => "messaging")] > This fails because at the time of validation the /subsystem=messaging:add is not valid. > To illustrate, the execution order is > Validate 1-2 > 1 > 2 > A possible solution is to convert this to the following: > V1 > 1 > V2 (works now because 1 has registered the subsystem API) > 2 > I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-850) @TransactionTimeout ignored if method ist not public

by Tomek Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-850?page=com.atlassian.jira.plugin.s... ] Tomek Adamski reassigned WFLY-850: ---------------------------------- Assignee: Tomek Adamski (was: David Lloyd) > @TransactionTimeout ignored if method ist not public > ---------------------------------------------------- > > Key: WFLY-850 > URL: https://issues.jboss.org/browse/WFLY-850 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Frank Langelage > Assignee: Tomek Adamski > Priority: Minor > > The annotation @TransactionTimeout is not honored, when the method has other than public access. > @Timeout methods invoked by the container are allowed to have "public, private, protected, or package level access". > So the annotation should work also if method is not public. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2422) Simplify the remote-outbound connections

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.... ] Cheng Fang reassigned WFLY-2422: -------------------------------- Assignee: Tomek Adamski (was: Cheng Fang) Tomek, can you take it over? Looks like I won't be able to get to it any time soon. > Simplify the remote-outbound connections > ---------------------------------------- > > Key: WFLY-2422 > URL: https://issues.jboss.org/browse/WFLY-2422 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: EJB, Remoting > Affects Versions: 8.0.0.Beta1 > Reporter: Wolf-Dieter Fink > Assignee: Tomek Adamski > > At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml. > But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster. > It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration. > In this case it is possible to keep the application deployment independent from the server environment. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-972) EJB calendar timer Sunday calculation problem in certain locales

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.s... ] Cheng Fang reassigned WFLY-972: ------------------------------- Assignee: Tomek Adamski (was: Cheng Fang) Tomek, can you look into this issue? > EJB calendar timer Sunday calculation problem in certain locales > ---------------------------------------------------------------- > > Key: WFLY-972 > URL: https://issues.jboss.org/browse/WFLY-972 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Environment: JDK 6 & 7 > Reporter: Cheng Fang > Assignee: Tomek Adamski > > My ejb class contains this timeout method: > {code:java} > @Schedule(dayOfWeek="Sun", persistent=false) > private void sunday(Timer t) { > } > {code} > When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc). It works as expected on other locales like en_US. > I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale. > Seems to be a JDK bug. There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday. Today is Wed. > One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes." I tried it on 7.2 with it_IT, and got the expected Sunday. > {noformat} > ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java > ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java > ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java > {noformat} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-349) Accumulate.accumulate(Accumulate.java:182) NullPointerException

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-349?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-349. -------------------------------- Resolution: Rejected The NPE is not a drools bug, but caused by the fact that the employee inside the ShiftAssignment is null. Changing the first pattern in that rule with the following one fixes the problem. ShiftAssignment($employee : employee != null, $shiftType : shiftType) > Accumulate.accumulate(Accumulate.java:182) NullPointerException > --------------------------------------------------------------- > > Key: DROOLS-349 > URL: https://issues.jboss.org/browse/DROOLS-349 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR1 > Environment: Windows 7 64 bit, Optaplanner 6.0.0.CR1, Java 1.7.0_17-b02 > Reporter: Nick Snels > Assignee: Mario Fusco > > I reported my issue with a Drools rule in Optaplanner on the Drools user forum (http://drools.46999.n3.nabble.com/Optaplanner-rules-NullPointerException-...). I was adviced to create a JIRA ticket. > ============= > I am trying to accomplish the following, a part time employee (eg 50%) needs to do only half the shifts a full time employee needs to do. I have created a rule, that > 1. count number of shifts of certain shiftType > 2. count number of shifts of a certain shiftType per employee > 3. count the total number of "arbeidsbreuken" per employee and within a certain shiftType > 4. do something with these numbers so that an part time employee only gets half the shifts assigned that a full time employee gets > The complete rule is: > {code} > rule "arbeidsbreuk" > when > //System.out.println("arbeidsbreuk, Drools!"); > ShiftAssignment($employee : employee, $shiftType : shiftType) > //count aantal shifts > $assignmentTotal : Number() from accumulate( > $assignment : ShiftAssignment(shiftType == $shiftType), > count($assignment) > ) > > //count aantal shifts per medewerker > $assignmentTotalEmployee : Number() from accumulate( > $assignmentEmployee : ShiftAssignment(employee == $employee, shiftType == $shiftType), > count($assignmentEmployee) > ) > > //count arbeidsbreuken van alle medewerkers > $arbeidsbreukTotal : Number() from accumulate( > //Employee($breuk : arbeidsbreuk), > ShiftAssignment(employee == $employee, shiftType == $shiftType), > sum($employee.getArbeidsbreuk()) > ) > $assignmentTotalEmployee.intValue()) > then > System.out.println("Arbeidsbreuk drools: " + $employee.getArbeidsbreuk() + " - " + $assignmentTotal.intValue() + " - " + $assignmentTotalEmployee.intValue() + " - " + $arbeidsbreukTotal); > scoreHolder.addSoftConstraintMatch(kcontext, -(Math.abs(($employee.getArbeidsbreuk() * $assignmentTotal.intValue()) - $assignmentTotalEmployee.intValue()) * (Math.abs(($employee.getArbeidsbreuk() * $assignmentTotal.intValue()) - $assignmentTotalEmployee.intValue()))) ); > end > {code} > I get the following error: > {code} > Exception in thread "main" org.drools.core.RuntimeDroolsException: java.lang.NullPointerException > at org.drools.core.rule.Accumulate.accumulate(Accumulate.java:182) > at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:756) > at org.drools.core.phreak.PhreakAccumulateNode.doLeftInserts(PhreakAccumulateNode.java:164) > at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:81) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:494) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:277) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:205) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183) > at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:935) > at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:909) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) > at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) > at org.optaplanner.core.impl.bestsolution.BestSolutionRecaller.solvingStarted(BestSolutionRecaller.java:58) > at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:177) > at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:154) > at be.ocmwturnhout.permanenties.Main.main(Main.java:495) > Caused by: java.lang.NullPointerException > at be.ocmwturnhout.permanenties.solver.Rule_arbeidsbreuk654888368.accumulateExpression2(Rule_arbeidsbreuk654888368.java:23) > at be.ocmwturnhout.permanenties.solver.Rule_arbeidsbreuk654888368AccumulateExpression2Invoker.evaluate(Rule_arbeidsbreuk654888368AccumulateExpression2Invoker.java:25) > at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:107) > at org.drools.core.rule.Accumulate.accumulate(Accumulate.java:173) > ... 21 more > {code} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3156) Upgrade RestEasy to 3.0.7

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-3156: --------------------------------- Summary: Upgrade RestEasy to 3.0.7 Key: WFLY-3156 URL: https://issues.jboss.org/browse/WFLY-3156 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: REST Affects Versions: 8.0.0.Final Reporter: Tomaz Cerar Assignee: Bill Burke Priority: Blocker Fix For: 8.0.1.Final We need new release of RestEasy as it includes few fixes community wants. -- 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, 3 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 March 2014