[JBoss JIRA] (WFCORE-1031) PS1 scripts invocation ends with "cannot be loaded because running scripts is disabled on thi s system", affect MS Windows desktop series
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1031?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-1031:
-----------------------------------
Assignee: (was: Tomaz Cerar)
> PS1 scripts invocation ends with "cannot be loaded because running scripts is disabled on thi s system", affect MS Windows desktop series
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1031
> URL: https://issues.jboss.org/browse/WFCORE-1031
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Rostislav Svoboda
>
> PS1 scripts invocation ends with "cannot be loaded because running scripts is disabled on thi s system".
> This was spotted on Windows 10 but it seems it affect more MS Windows desktop series (at leas 8.x too) - based on HiChat discussion.
> When I open PowerShel, enter the bin folder and run .\standalone.ps1 I get this:
> {code}
> .\standalone.ps1 : File E:\jboss-eap-7.0\bin\standalone.ps1 cannot be loaded because running scripts is disabled on this s system.
> For more information, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
> At line:1 char:1
> + .\standalone.ps1
> + ~~~~~~~~~~~~~~~~
> + CategoryInfo : SecurityError: (:) [], PSSecurityException
> + FullyQualifiedErrorId : UnauthorizedAccess
> {code}
> what "helped" is this:
> Set-ExecutionPolicy RemoteSigned
> but I had to run powershell as administrator because it's changing registry key ... so well, not straightforward usage of ps1 scripts ... Not everybody is able to run in admin mode.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (DROOLS-2442) Update Kie Navigator to the new git/rest structure
by Tiago Bento (JIRA)
Tiago Bento created DROOLS-2442:
-----------------------------------
Summary: Update Kie Navigator to the new git/rest structure
Key: DROOLS-2442
URL: https://issues.jboss.org/browse/DROOLS-2442
Project: Drools
Issue Type: Bug
Components: eclipse plugin
Affects Versions: 7.5.0.Final
Environment: 7.7.0-SNAPSHOT
Reporter: Tiago Bento
Assignee: Tiago Bento
Fix For: 7.7.0.Final
Drools eclipse plugin contains Kie Navigator tool which uses git structure and rest calls to connect to kie-wb. According to changes made in kie-wb 7.7.0 the tooling should be updated.
The rest api and the git structure changed. and the kie navigator doesn't work.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (LOGTOOL-134) Incompatible type error with @Cause and ctors with unusual exception types
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-134?page=com.atlassian.jira.plugi... ]
David Lloyd updated LOGTOOL-134:
--------------------------------
Workaround Description:
Use the {{Signature}} annotation like this:
{code:java}
@Message(id = 442, value = "Unexpected Error")
@Signature(String.class)
EJBException unexpectedError(@Cause Throwable cause);
{code}
Workaround: Workaround Exists
> Incompatible type error with @Cause and ctors with unusual exception types
> --------------------------------------------------------------------------
>
> Key: LOGTOOL-134
> URL: https://issues.jboss.org/browse/LOGTOOL-134
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.1.0.Final
> Reporter: David Lloyd
> Priority: Minor
>
> Incorrect generated code can be generated if an exception constructor's "cause" parameter is a subtype of {{Throwable}} (say, {{Exception}}) instead of being {{Throwable}} itself, and a {{\@Cause}} parameter exists whose type is a superclass of that type (say, {{Throwable}}).
> The compilation errors can look something like this:
> {noformat}
> 2018-04-02 12:37:40 [ERROR] /home/david/src/java/wildfly/ejb3/target/generated-sources/annotations/org/jboss/as/ejb3/logging/EjbLogger_$logger.java:[3340,112] incompatible types: java.lang.Throwable cannot be converted to java.lang.Exception
> 2018-04-02 12:37:40 [ERROR] /home/david/src/java/wildfly/ejb3/target/generated-sources/annotations/org/jboss/as/ejb3/logging/EjbLogger_$logger.java:[3479,164] incompatible types: java.lang.Error cannot be converted to java.lang.Exception
> {noformat}
> If the {{\@Cause}} method parameter type is not assignable to the exception's cause parameter type, then the {{initCause}} strategy should be used instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (LOGTOOL-134) Incompatible type error with @Cause and ctors with unusual exception types
by David Lloyd (JIRA)
David Lloyd created LOGTOOL-134:
-----------------------------------
Summary: Incompatible type error with @Cause and ctors with unusual exception types
Key: LOGTOOL-134
URL: https://issues.jboss.org/browse/LOGTOOL-134
Project: Log Tool
Issue Type: Bug
Affects Versions: 2.1.0.Final
Reporter: David Lloyd
Priority: Minor
Incorrect generated code can be generated if an exception constructor's "cause" parameter is a subtype of {{Throwable}} (say, {{Exception}}) instead of being {{Throwable}} itself, and a {{\@Cause}} parameter exists whose type is a superclass of that type (say, {{Throwable}}).
The compilation errors can look something like this:
{noformat}
2018-04-02 12:37:40 [ERROR] /home/david/src/java/wildfly/ejb3/target/generated-sources/annotations/org/jboss/as/ejb3/logging/EjbLogger_$logger.java:[3340,112] incompatible types: java.lang.Throwable cannot be converted to java.lang.Exception
2018-04-02 12:37:40 [ERROR] /home/david/src/java/wildfly/ejb3/target/generated-sources/annotations/org/jboss/as/ejb3/logging/EjbLogger_$logger.java:[3479,164] incompatible types: java.lang.Error cannot be converted to java.lang.Exception
{noformat}
If the {{\@Cause}} method parameter type is not assignable to the exception's cause parameter type, then the {{initCause}} strategy should be used instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFCORE-3724) stop-servers following by a reload operation could end up in a long period with an unmanageable domain
by Yeray Borges (JIRA)
Yeray Borges created WFCORE-3724:
------------------------------------
Summary: stop-servers following by a reload operation could end up in a long period with an unmanageable domain
Key: WFCORE-3724
URL: https://issues.jboss.org/browse/WFCORE-3724
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 5.0.0.Alpha2
Reporter: Yeray Borges
Assignee: Brian Stansberry
When {{:stop-servers}} operation is used with a timeout different than 0, a graceful stop is performed on each server.
If the user executes {{/host=master:reload}} in a DC, the reload operation waits for the servers until they are completely stopped. This could be an issue for a DC since the user is unable to execute any operation meanwhile the reload op is waiting for the previous stop.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFCORE-3724) stop-servers following by a reload operation could end up in a long period with an unmanageable domain
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3724?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-3724:
------------------------------------
Assignee: Yeray Borges (was: Brian Stansberry)
> stop-servers following by a reload operation could end up in a long period with an unmanageable domain
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3724
> URL: https://issues.jboss.org/browse/WFCORE-3724
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 5.0.0.Alpha2
> Reporter: Yeray Borges
> Assignee: Yeray Borges
>
> When {{:stop-servers}} operation is used with a timeout different than 0, a graceful stop is performed on each server.
> If the user executes {{/host=master:reload}} in a DC, the reload operation waits for the servers until they are completely stopped. This could be an issue for a DC since the user is unable to execute any operation meanwhile the reload op is waiting for the previous stop.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (JBRULES-1058) nested accessors with Sets - "not contains" is not a valid operator for MVEL
by Rahul Vanimisetty (JIRA)
[ https://issues.jboss.org/browse/JBRULES-1058?page=com.atlassian.jira.plug... ]
Rahul Vanimisetty commented on JBRULES-1058:
--------------------------------------------
Hi Edson ,
I am looking for a faster turnaround for https://issues.jboss.org/browse/DROOLS-2438. Could you please assign this ticket to yourself and respond. Need your help on this one asap. Thanks in advance.
> nested accessors with Sets - "not contains" is not a valid operator for MVEL
> ----------------------------------------------------------------------------
>
> Key: JBRULES-1058
> URL: https://issues.jboss.org/browse/JBRULES-1058
> Project: JBRULES
> Issue Type: Bug
> Components: drools-compiler
> Affects Versions: 4.0.0.GA
> Reporter: Mark McNally
> Assignee: Edson Tirelli
> Fix For: 4.0.1
>
>
> Following does not work:
> rule StateMatch
> when
> $ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state )
> then
> retract( $ca );
> end
>
>
> public class CandidateAssociation {
> private PatientDetails patientDetails;
> private NurseDetails nurseDetails;
> private int overlapHours;
>
> public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
> super();
> this.patientDetails = patientDetails;
> this.nurseDetails = nurseDetails;
> overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
> }
> [...]
> }
>
> public class NurseDetails {
> private Set stateLicensures = new HashSet();
> [...]
> }
> public class PatientDetails {
> private String state;
> [...]
> }
> Edson suggested that the problem is that "not contains" is not a valid operator for MVEL.
> Also Noticed that the following workaround did not work:
> rule State
> dialect "mvel"
> when
> $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
> then
> retract( $ca );
> end
>
> This produced this Exception:
> org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at [...]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (DROOLS-2438) Drools template : Multiple rows from database map to multiple conditions within the when block of a a single rule
by Rahul Vanimisetty (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2438?page=com.atlassian.jira.plugi... ]
Rahul Vanimisetty updated DROOLS-2438:
--------------------------------------
Issue Type: Bug (was: Enhancement)
> Drools template : Multiple rows from database map to multiple conditions within the when block of a a single rule
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2438
> URL: https://issues.jboss.org/browse/DROOLS-2438
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.6.0.Final
> Reporter: Rahul Vanimisetty
> Assignee: Mario Fusco
> Priority: Blocker
> Labels: task
>
> In a drool template, if i am loading rules from a database, then as per my understanding each row in the database table represents a rule. So a drool template will generate a drl file in the following way :
> rule 1
> when
> condition(first row of db)
> action
> rule 2
> condition(2cd row of db)
> then
> action
> etc.
> My requirement is to have a dynamic drl generated in the following way :
> rule 1
> when
> condition 1(1st row of db)
> condition 2 (2cd row of db)
> condition 3 (3rd row of db)
> etc
> then
> action
> end
> Please suggest a way to do this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years