[JBoss JIRA] (JGRP-2310) Port to quarkus
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2310?page=com.atlassian.jira.plugin.... ]
Bela Ban deleted JGRP-2310:
---------------------------
> Port to quarkus
> ---------------
>
> Key: JGRP-2310
> URL: https://issues.jboss.org/browse/JGRP-2310
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
>
> Port JGroups to Quarkus [1].
> This is a quick and dirty port, to see what needs to be done.
> The goal is to identify changes which can be made in JGroups to make this part as easy as possible. Example: since JMX is not supported, separate JMX into a set of interfaces and 2 implementations: the default impl which is used when JGroups runs on a regular JVM, and another one used when run on GraalVM.
> [1] https://quarkus.io
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2332) Port of JGroups to Quarkus
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2332?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2332:
---------------------------
Issue Type: Patch (was: Task)
Fix Version/s: 4.1.0
(was: 4.0.20)
> Port of JGroups to Quarkus
> --------------------------
>
> Key: JGRP-2332
> URL: https://issues.jboss.org/browse/JGRP-2332
> Project: JGroups
> Issue Type: Patch
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Port JGroups to Quarkus [1].
> This is a quick and dirty port, to see what needs to be done.
> The goal is to identify changes which can be ported back to JGroups proper to make this port as easy as possible.
> Example: since JMX is not supported, separate JMX into a set of interfaces and 2 implementations: the default impl which is used when JGroups runs on a regular JVM, and another one used when run on GraalVM.
> This is currently scheduled for 4.x, but may as well end up being done in 5.x
> [1] https://quarkus.io
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3608) Wrong behavior with top level collection in DMN scenario
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3608?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi resolved DROOLS-3608.
--------------------------------------
Resolution: Done
> Wrong behavior with top level collection in DMN scenario
> --------------------------------------------------------
>
> Key: DROOLS-3608
> URL: https://issues.jboss.org/browse/DROOLS-3608
> Project: Drools
> Issue Type: Sub-task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: dmn-list.dmn
>
>
> If you have a DMN file with a top level collection like a list of string not as field of a complex object but as top level. The type is not correctly loaded and managed.
> Top-level collection should work also in Rule scenario.
> See dmn-list.dmn as example
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3608) Wrong behavior with top level collection in DMN scenario
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3608?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi commented on DROOLS-3608:
------------------------------------------
[~kkufova]
The last issue you raised here https://github.com/kiegroup/drools-wb/pull/1091 was actually due to wrongly written out DMN (I sent you correct one via gchat).
But beside that you explicitly stated that you do not want "partial" solutions
_I don't accept the answer that "top-level collections don't work yet", as they work with some DMNs_
Probably it was not clear enough, but top-level collection *are* broken; even if you see a _green_ status after run is only by chance, and it does not mean it actually made the _right_ comparison you would expect. For example, it turned out that in some cases the DMN engine turned both input and output to _null_, and then the comparison "apparently" succeeded.
Last, making only one single PR at the end was exactly what I meant with:
_This mean that I will close this PR and I will create a new one that will include everything._
> Wrong behavior with top level collection in DMN scenario
> --------------------------------------------------------
>
> Key: DROOLS-3608
> URL: https://issues.jboss.org/browse/DROOLS-3608
> Project: Drools
> Issue Type: Sub-task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: dmn-list.dmn
>
>
> If you have a DMN file with a top level collection like a list of string not as field of a complex object but as top level. The type is not correctly loaded and managed.
> Top-level collection should work also in Rule scenario.
> See dmn-list.dmn as example
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3608) Wrong behavior with top level collection in DMN scenario
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3608?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3608:
--------------------------------------
[~gabriolo], so there isn't any dedicated PR specifically for this task?
> Wrong behavior with top level collection in DMN scenario
> --------------------------------------------------------
>
> Key: DROOLS-3608
> URL: https://issues.jboss.org/browse/DROOLS-3608
> Project: Drools
> Issue Type: Sub-task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: dmn-list.dmn
>
>
> If you have a DMN file with a top level collection like a list of string not as field of a complex object but as top level. The type is not correctly loaded and managed.
> Top-level collection should work also in Rule scenario.
> See dmn-list.dmn as example
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11717) Illegal reflective access - org.jboss.invocation.proxy.AbstractProxyFactory
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11717?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFLY-11717 at 3/20/19 8:21 PM:
------------------------------------------------------------------
[~krisgerhard] Do you have some kind of reproducer app you can attach? I just scanned through the server.log produced by the testsuite/integration/basic part of our testsuite from a JDK 11 job[1] looking for "lllegal ref" and don't find any occurrences. That job runs all sorts of EE related tests, i.e. various EJB apps the testsuite deploys. So if it doesn't report the illegal reflective access my assumption is it won't be trivial to reproduce. Looking at the code I didn't see why it would happen either. So perhaps something about your app is key to identifying the cause.
[1] https://ci.wildfly.org/repository/download/WF_MasterLinuxJdk11/141561:id/... -- a link that will break eventually as ci server cleans out old jobs.
was (Author: brian.stansberry):
[~krisgerhard] Do you have some kind of reproducer app you can attach? I just scanned through the server.log produced by the testsuite/integration/basic part of our testsuite from a JDK 11 job[1] looking for "llegal ref" and don't find any occurrences. That job runs all sorts of EE related tests, i.e. various EJB apps the testsuite deploys. So if it doesn't report the illegal reflective access my assumption is it won't be trivial to reproduce. Looking at the code I didn't see why it would happen either. So perhaps something about your app is key to identifying the cause.
[1] https://ci.wildfly.org/repository/download/WF_MasterLinuxJdk11/141561:id/... -- a link that will break eventually as ci server cleans out old jobs.
> Illegal reflective access - org.jboss.invocation.proxy.AbstractProxyFactory
> ---------------------------------------------------------------------------
>
> Key: WFLY-11717
> URL: https://issues.jboss.org/browse/WFLY-11717
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 15.0.1.Final
> Reporter: Kris-Gerhard Aabrams
> Assignee: Brian Stansberry
> Priority: Major
> Labels: Java11
>
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.invocation.proxy.AbstractProxyFactory$1 (jar:file:/opt/jboss/wildfly/modules/system/layers/base/org/jboss/invocation/main/jboss-invocation-1.5.1.Final.jar!/) to method java.lang.Object.clone()
> WARNING: Please consider reporting this to the maintainers of org.jboss.invocation.proxy.AbstractProxyFactory$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-11808?page=com.atlassian.jira.plugin... ]
Cheng Fang edited comment on WFLY-11808 at 3/20/19 7:45 PM:
------------------------------------------------------------
The batch subsystem chose the name context for the batch job execution as follows:
{code:java}
org.jboss.as.naming.context.NamespaceContextSelector.getCurrentSelector();
{code}
So for a job execution request from the management console or CLI, the current thread is "External Management Threads - 1", and its associated name context is used for batch job execution, but this name context has no knowlege of the deployment that contains the batch job. Any lookup of application resources done from any batch artifacts during the batch job execution will simply fail.
See attached screenshot of external management request thread vs default task thread.
was (Author: cfang):
The batch subsystem chose the name context for the batch job execution as follows:
{code:java}
org.jboss.as.naming.context.NamespaceContextSelector.getCurrentSelector();
{code}
So for a job execution request from the management console or CLI, the current thread is "External Management Threads - 1", and its associated name context is used for batch job execution, but this name context has no knowlege of the deployment that contains the batch job. Any lookup of application resources done from any batch artifacts during the batch job execution will simply fail.
> Unable to do jndi lookup when starting batch job from web console
> -----------------------------------------------------------------
>
> Key: WFLY-11808
> URL: https://issues.jboss.org/browse/WFLY-11808
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 16.0.0.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Default Task Thread.png, External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png
>
>
> when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months