[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
11 years, 9 months
[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
11 years, 9 months
[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
11 years, 9 months
[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
11 years, 9 months
[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
11 years, 9 months
[JBoss JIRA] (WFLY-3155) Upgrade MSC to 1.2.2.Final
by David Lloyd (JIRA)
David Lloyd created WFLY-3155:
---------------------------------
Summary: Upgrade MSC to 1.2.2.Final
Key: WFLY-3155
URL: https://issues.jboss.org/browse/WFLY-3155
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Reporter: David Lloyd
Assignee: David Lloyd
Priority: Blocker
Fix For: 8.0.1.Final
This upgrade should be done before release.
--
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
11 years, 9 months
[JBoss JIRA] (WFLY-3154) Operation which require server reload should check if something was changed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3154?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3154:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=976228
> Operation which require server reload should check if something was changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-3154
> URL: https://issues.jboss.org/browse/WFLY-3154
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
>
> Description of problem:
> Server reload is required even if nothing was actually changed. This could have negative impact on usability of WildFly.
> Steps to Reproduce:
> - start standalone
> - connect to cli
> - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
> - reload server
> - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
> Actual results:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> Expected results:
> - reload is not required
--
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
11 years, 9 months
[JBoss JIRA] (WFLY-3154) Operation which require server reload should check if something was changed
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-3154:
---------------------------------------
Summary: Operation which require server reload should check if something was changed
Key: WFLY-3154
URL: https://issues.jboss.org/browse/WFLY-3154
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Final
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
Description of problem:
Server reload is required even if nothing was actually changed. This could have negative impact on usability of WildFly.
Steps to Reproduce:
- start standalone
- connect to cli
- run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
- reload server
- run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
Actual results:
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
Expected results:
- reload is not required
--
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
11 years, 9 months