[JBoss JIRA] (WFCORE-3962) Starting WFLY with JDK 11 blows up with ModuleNotFoundException java.se
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3962?page=com.atlassian.jira.plugi... ]
Matej Novotny updated WFCORE-3962:
----------------------------------
Labels: Java11 (was: )
> Starting WFLY with JDK 11 blows up with ModuleNotFoundException java.se
> -----------------------------------------------------------------------
>
> Key: WFCORE-3962
> URL: https://issues.jboss.org/browse/WFCORE-3962
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Affects Versions: 6.0.0.Alpha3
> Reporter: Matej Novotny
> Assignee: David Lloyd
> Labels: Java11
>
> As per request, copying MODULES-372 to WFCORE as well.
> Starting WFLY with JDK 11 using {{standalone.sh}} yields:
> {code}
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> {code}
> Output of {{java -version}}:
> {code}
> openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+21)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3962) Starting WFLY with JDK 11 blows up with ModuleNotFoundException java.se
by Matej Novotny (JIRA)
Matej Novotny created WFCORE-3962:
-------------------------------------
Summary: Starting WFLY with JDK 11 blows up with ModuleNotFoundException java.se
Key: WFCORE-3962
URL: https://issues.jboss.org/browse/WFCORE-3962
Project: WildFly Core
Issue Type: Bug
Components: Modules
Affects Versions: 6.0.0.Alpha3
Reporter: Matej Novotny
Assignee: David Lloyd
As per request, copying MODULES-372 to WFCORE as well.
Starting WFLY with JDK 11 using {{standalone.sh}} yields:
{code}
org.jboss.modules.ModuleNotFoundException: java.se
at org.jboss.modules.Module.addPaths(Module.java:1266)
at org.jboss.modules.Module.link(Module.java:1622)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:437)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ELY-1608) Keystores do not expose same operation
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1608?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1608:
------------------------------
Need Info from: Darran Lofthouse, Farah Juma
> Keystores do not expose same operation
> --------------------------------------
>
> Key: ELY-1608
> URL: https://issues.jboss.org/browse/ELY-1608
> Project: WildFly Elytron
> Issue Type: Bug
> Components: KeyStores
> Affects Versions: 1.4.0.Final
> Reporter: Martin Choma
>
> This JIRA is in this stage for discussion purposed.
> In context of https://issues.jboss.org/browse/PRODMGT-1907 I have compared operations of resources providing same capability in elytron subsystem.
> I want to discuss.
> * {code}
> diff key-store.operations ldap-key-store.operations
> 5,9d4
> < "change-alias",
> < "export-certificate",
> < "generate-certificate-signing-request",
> < "generate-key-pair",
> < "import-certificate",
> 14d8
> < "load",
> 34d27
> < "store",
> {code}
> load() was introduced by EAP7-455
> rest of operations were introduced by EAP7-650
> Now question is if these operations (load() is already covered by PRODMGT-1907) shouldn be also in `ldap-key-store`.
> * filtering-key-store
> should it also contain extended operations or it is enough only underlying key-store has them
> * Keystore capability org.wildfly.security.key-store is referenced in filtering-key-store, key-manager, trust-manager, keystore-realm, token-realm . Is it necessary to propagate load operation also to these resources.
> key-manager has init() operation. trust-manager does not have such operation but went through EAP7-455 so is probably ok. filtering-key-store probably does not "cache" keystore but request underlying keystore. What about keystore-realm, token-realm ?
> * Although same resources "provide" same capability (org.wildfly.security.key-store) There is no guarantee they should provide same operations on model level, right? It is just user experience issue as one could expect same operations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2733) Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model
by Luca Molteni (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2733?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-2733:
---------------------------------
Component/s: executable model
> Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model
> -----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2733
> URL: https://issues.jboss.org/browse/DROOLS-2733
> Project: Drools
> Issue Type: Feature Request
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Optional
>
> The executable model doesn't support custom inline accumulate code that uses external declarations such as
> {code:java}
> String str = "import " + Person.class.getCanonicalName() + ";\n" +
> "rule R dialect \"mvel\" when\n" +
> " String( $l : length )" +
> " $sum : Integer() from accumulate (\n" +
> " Person( age > 18, $age : age ), init( int sum = 0 * $l; ), action( sum += $age; ), reverse( sum -= $age; ), result( sum )\n" +
> " )" +
> "then\n" +
> " insert($sum);\n" +
> "end";
> {code}
> (Notice that in the init we multiply the sum value with the length of string)
> But it can support such style using the "classic" generation of accumulate classes which gets compiled among the executable model and instantiate during the execution of the DSL.
> This mechanism is broken with the MVEL dialect, as we don't have such generated classes.
> Probably what we should do instead is putting MVEL expressions in the DSL directly such as
> {code:java}
> accumulateScript("initCode", "accCode", "reverseCode");
> {code}
> and then during interpretation create a new MVEL context and execute the accumulate in memory
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-338) Checker script needs replacement for --show-all flag as it will not be supported in future
by Sunil kondkar (JIRA)
Sunil kondkar created SWSQE-338:
-----------------------------------
Summary: Checker script needs replacement for --show-all flag as it will not be supported in future
Key: SWSQE-338
URL: https://issues.jboss.org/browse/SWSQE-338
Project: Kiali QE
Issue Type: Task
Reporter: Sunil kondkar
Assignee: Michael Foley
Priority: Minor
1. Checker script uses the flag -show-all=false to hide the terminated/evicted pods. In jenkins run, we get messages like:
Flag --show-all has been deprecated, will be removed in an upcoming release
Some replacement is needed for the flag in the script.
2. Fix a corner case where istio is not deployed successfuly and checker script shows istio pods deployed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2249) CENTRAL_LOCK2: reconciliation protocol on coord change
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2249?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2249:
--------------------------------
The design document is ./doc/design/CENTRAL_LOCK2.txt.
Almost done with the implementation; the request-queue handler is the only thing left to do.
> CENTRAL_LOCK2: reconciliation protocol on coord change
> ------------------------------------------------------
>
> Key: JGRP-2249
> URL: https://issues.jboss.org/browse/JGRP-2249
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> Implement a reconciliation protocol when the coord changes: instead of backing up all lock information to another member, the new coord asks all members for their current lock information (acquired locks, pending acquire and release requests) and constructs the lock table accordingly.
> This is described in https://issues.jboss.org/browse/JGRP-2234 (later comments).
> Comment from 2234:
> Clients need to have the following information:
> * Locks they acquired
> * Pending lock requests; locks which they want to acquire but for which they haven't yet received a LOCK_GRANTED response
> * Pending lock release requests; lock that have been released, but for which no RELEASE_LOCK_OK response has been received
> * Ditto for conditions, but we'll tackle them in a second stage
> The reconciliation protocol queues all new requests on the coord and asks all members for their lock information. Once the coord has received this information from all members, it applies this and then drains the queue of pending requests.
> It is important that the requests are ordered per member, ie. a release(L) cannot come before a lock(L).
> Since {{CENTRAL_LOCK}} allows for multiple members to hold the same lock in a split brain scenario, we need to think about how to handle merging where the coord detects that multiple members hold the same lock...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-1685) Improve performance of rules using "or" in LHS
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1685?page=com.atlassian.jira.plugi... ]
Tibor Zimányi closed DROOLS-1685.
---------------------------------
Resolution: Cannot Reproduce
> Improve performance of rules using "or" in LHS
> ----------------------------------------------
>
> Key: DROOLS-1685
> URL: https://issues.jboss.org/browse/DROOLS-1685
> Project: Drools
> Issue Type: Enhancement
> Components: core engine, kie server
> Affects Versions: 6.5.0.Final
> Reporter: Russell Morrisey
> Assignee: Mario Fusco
>
> The following two rulesets produce the same output, but their performance differs dramatically.
> My understanding is that the two rulesets should be equivalent to one another. It seems like the 'or' operation must be handled inefficiently by the engine. Is there anything that can be improved the engine's performance in this case?
> Ruleset #1 takes ~3 seconds to execute on my local machine (for a dataset with 3 entities, 1 service ordered each). Ruleset #2 runs in ~200 ms.
> *Ruleset 1*
> {code:java}
> rule "Rule183"
> dialect "mvel"
> when
> $entity : Entity( )
> ( $service : ServiceOrdered( serviceId == "FORM" , entity == $entity , entity.entityTypeId in ( 291262, 291275, 291277 ) ) or $service : ServiceOrdered( serviceId == "DISSO" , entity == $entity , entity.entityTypeId in ( 291262 ) , stateId == 290864 ) )
> $r1 : QuestionDefinition( id == 590 )
> then
> Question fact0 = new Question();
> fact0.setQuestionDefinition( $r1 );
> fact0.setEntity( $entity );
> insert( fact0 );
> end
> {code}
> *Ruleset 2*
> {code:java}
> rule "Rule183"
> dialect "mvel"
> when
> $entity : Entity( )
> $service : ServiceOrdered( serviceId == "FORM" , entity == $entity , entity.entityTypeId in ( 291262, 291275, 291277 ) )
> $r1 : QuestionDefinition( id == 590 )
> then
> Question fact0 = new Question();
> fact0.setQuestionDefinition( $r1 );
> fact0.setEntity( $entity );
> insert( fact0 );
> end
> {code}
> {code}
> rule "Rule183-2"
> dialect "mvel"
> when
> $entity : Entity( )
> $service : ServiceOrdered( serviceId == "DISSO" , entity == $entity , entity.entityTypeId == 291262 , stateId == 290864 )
> $r1 : QuestionDefinition( id == 590 )
> then
> Question fact0 = new Question();
> fact0.setQuestionDefinition( $r1 );
> fact0.setEntity( $entity );
> insert( fact0 );
> end
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ELY-1608) Keystores do not expose same operation
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1608?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1608:
------------------------------
Description:
This JIRA is in this stage for discussion purposed.
In context of https://issues.jboss.org/browse/PRODMGT-1907 I have compared operations of resources providing same capability in elytron subsystem.
I want to discuss.
* {code}
diff key-store.operations ldap-key-store.operations
5,9d4
< "change-alias",
< "export-certificate",
< "generate-certificate-signing-request",
< "generate-key-pair",
< "import-certificate",
14d8
< "load",
34d27
< "store",
{code}
load() was introduced by EAP7-455
rest of operations were introduced by EAP7-650
Now question is if these operations (load() is already covered by PRODMGT-1907) shouldn be also in `ldap-key-store`.
* filtering-key-store
should it also contain extended operations or it is enough only underlying key-store has them
* Keystore capability org.wildfly.security.key-store is referenced in filtering-key-store, key-manager, trust-manager, keystore-realm, token-realm . Is it necessary to propagate load operation also to these resources.
key-manager has init() operation. trust-manager does not have such operation but went through EAP7-455 so is probably ok. filtering-key-store probably does not "cache" keystore but request underlying keystore. What about keystore-realm, token-realm ?
* Although same resources "provide" same capability (org.wildfly.security.key-store) There is no guarantee they should provide same operations on model level, right? It is just user experience issue as one could expect same operations.
was:
This JIRA is in this stage for discussion purposed.
In context of https://issues.jboss.org/browse/PRODMGT-1907 I have compared operations of resources providing same capability in elytron subsystem.
I want to discuss.
*
{code}
diff key-store.operations ldap-key-store.operations
5,9d4
< "change-alias",
< "export-certificate",
< "generate-certificate-signing-request",
< "generate-key-pair",
< "import-certificate",
14d8
< "load",
34d27
< "store",
{code}
load() was introduced by EAP7-455
rest of operations were introduced by EAP7-650
Now question is if these operations (load() is already covered by PRODMGT-1907) shouldn be also in `ldap-key-store`.
* filtering-key-store
should it also contain extended operations or it is enough only underlying key-store has them
*
Keystore capability org.wildfly.security.key-store is referenced in filtering-key-store, key-manager, trust-manager, keystore-realm, token-realm . Is it necessary to propagate load operation also to these resources.
key-manager has init() operation. trust-manager does not have such operation but went through EAP7-455 so is probably ok. filtering-key-store probably does not "cache" keystore but request underlying keystore. What about keystore-realm, token-realm ?
* Although same resources "provide" same capability (org.wildfly.security.key-store) There is no guarantee they should provide same operations on model level, right? It is just user experience issue as one could expect same operations.
> Keystores do not expose same operation
> --------------------------------------
>
> Key: ELY-1608
> URL: https://issues.jboss.org/browse/ELY-1608
> Project: WildFly Elytron
> Issue Type: Bug
> Components: KeyStores
> Affects Versions: 1.4.0.Final
> Reporter: Martin Choma
>
> This JIRA is in this stage for discussion purposed.
> In context of https://issues.jboss.org/browse/PRODMGT-1907 I have compared operations of resources providing same capability in elytron subsystem.
> I want to discuss.
> * {code}
> diff key-store.operations ldap-key-store.operations
> 5,9d4
> < "change-alias",
> < "export-certificate",
> < "generate-certificate-signing-request",
> < "generate-key-pair",
> < "import-certificate",
> 14d8
> < "load",
> 34d27
> < "store",
> {code}
> load() was introduced by EAP7-455
> rest of operations were introduced by EAP7-650
> Now question is if these operations (load() is already covered by PRODMGT-1907) shouldn be also in `ldap-key-store`.
> * filtering-key-store
> should it also contain extended operations or it is enough only underlying key-store has them
> * Keystore capability org.wildfly.security.key-store is referenced in filtering-key-store, key-manager, trust-manager, keystore-realm, token-realm . Is it necessary to propagate load operation also to these resources.
> key-manager has init() operation. trust-manager does not have such operation but went through EAP7-455 so is probably ok. filtering-key-store probably does not "cache" keystore but request underlying keystore. What about keystore-realm, token-realm ?
> * Although same resources "provide" same capability (org.wildfly.security.key-store) There is no guarantee they should provide same operations on model level, right? It is just user experience issue as one could expect same operations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years