[JBoss JIRA] (WFCORE-4115) JDK11 - GC logging format needs to be reviewed
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4115?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-4115:
---------------------------------------
I do believe Java 9+ defaults to G1GC, however the format difference is because of [JEP 271|http://openjdk.java.net/jeps/271]. That JEP reimplemented GC logging which leads to the new format. In the "Non Goals" it states:
{quote}
Non-Goals
It is not a goal to ensure that current GC log parsers work without change on the new GC logs.
Not all log entries will necessarily be reproduced in the new logging format.
{quote}
Essentially there's nothing we can do. We'll have to use a new parser.
> JDK11 - GC logging format needs to be reviewed
> ----------------------------------------------
>
> Key: WFCORE-4115
> URL: https://issues.jboss.org/browse/WFCORE-4115
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts, Server
> Reporter: Marek Kopecký
> Assignee: James Perkins
> Priority: Major
> Labels: Java11, jdk11
> Attachments: java-11-gc.log, java-8-gc.log
>
>
> * Weird naming of gc log files
> ** I test this with JDK11
> ** I start standalone and stop standalone
> ** JDK10 creates JBOSS_HOME/standalone/log/gc.log (with detailed information) and JBOSS_HOME/standalone/log/gc.log.0 (with brief summary of gc logging)
> ** I start standalone and stop standalone again
> ** JDK10 moves original gc.log to gc.log.1
> ** JDK10 keep original gc.log.0
> ** JDK10 creates new gc.log (with detailed information) and gc.log.2 (with brief summary of gc logging)
> ** Can this be changed by GC settings?
> * GC logs are much more verbose against jdk8 gc logs. Can this be fixed by some JDK10 gc settings?
> This is follow up for WFCORE-3996
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3249) [DMN Designer] Add support for optional typeRefs
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3249?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-3249:
---------------------------------------
I think we can keep it in master only.
> [DMN Designer] Add support for optional typeRefs
> ------------------------------------------------
>
> Key: DROOLS-3249
> URL: https://issues.jboss.org/browse/DROOLS-3249
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Critical
> Labels: drools-tools
>
> At the moment {{TypeRef}} is a mandatory field within the editor.
> This is a hard limitation of use of the Properties Panel bean-binding (it cannot bind to {{null}} values). However the DMN Specification states that {{TypeRef}} are optional (and we are working around by changing the _default_ to {{Any}} - see [DROOLS-3248|https://issues.jboss.org/browse/DROOLS-3248]).
> We need to change the UI and marshaller to be able to support _optional_ {{TypeRef}}. This would (probably) require adding a _magic_ value to {{BuiltInType}} representing a "null" selection. It would need to:
> - Appear at the top of the "Data Type selector" widget (with label "<None>" or similar)
> - Be the _selected_ option when the {{TypeRef}} is the new _magic_ value (this should happen automatically, but worth checking!)
> - The marshaller should set the {{TypeRef}} to the _magic_ {{BuiltInType}} if the DMN model (coming from XML->{{kie-dmn-model}}->workbench model) has a {{null}} {{TypeRef}} - the _magic_ value is only to be used _client-side_.
> - The marshaller should set the {{TypeRef}} to {{null}} when converting from the workbench model to {{kie-dmn-model}} and the workbench model {{TypeRef}} is the _magic_ value - again, the _magic_ value is only to be used _client-side_.
> - Check that creating new data-types does not show the _magic_ value (it uses a different widget, but population of the widget probably iterates all {{BuiltInType}}.
> [~tari_manga] [~karreiro] seem reasonable to you?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFCORE-4115) JDK11 - GC logging format needs to be reviewed
by Aaron Ogburn (Jira)
[ https://issues.jboss.org/browse/WFCORE-4115?page=com.atlassian.jira.plugi... ]
Aaron Ogburn commented on WFCORE-4115:
--------------------------------------
Thanks, [~jamezp]. So java 11 is defaulting to G1 and Java 8 defaults to parallel throughput collector here so that's a notable difference. Parallel GC on java 8 produces 1 log line per GC. G1 produces multiline entries for each GC. So if you used G1 on java 8 also and compared, you'd probably see more similar verbosity from multiline entires. I'm not aware of anything to scale back G1 verbosity on java 8 or 11.
> JDK11 - GC logging format needs to be reviewed
> ----------------------------------------------
>
> Key: WFCORE-4115
> URL: https://issues.jboss.org/browse/WFCORE-4115
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts, Server
> Reporter: Marek Kopecký
> Assignee: James Perkins
> Priority: Major
> Labels: Java11, jdk11
> Attachments: java-11-gc.log, java-8-gc.log
>
>
> * Weird naming of gc log files
> ** I test this with JDK11
> ** I start standalone and stop standalone
> ** JDK10 creates JBOSS_HOME/standalone/log/gc.log (with detailed information) and JBOSS_HOME/standalone/log/gc.log.0 (with brief summary of gc logging)
> ** I start standalone and stop standalone again
> ** JDK10 moves original gc.log to gc.log.1
> ** JDK10 keep original gc.log.0
> ** JDK10 creates new gc.log (with detailed information) and gc.log.2 (with brief summary of gc logging)
> ** Can this be changed by GC settings?
> * GC logs are much more verbose against jdk8 gc logs. Can this be fixed by some JDK10 gc settings?
> This is follow up for WFCORE-3996
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3277) KieScanner in Scala fat-jar application does not work due to Plexus configuration
by Michael Reynolds (Jira)
[ https://issues.jboss.org/browse/DROOLS-3277?page=com.atlassian.jira.plugi... ]
Michael Reynolds commented on DROOLS-3277:
------------------------------------------
To make this work in my SBT build, I had to do the following:
# Make META-INF/sisu/javax.named.Inject a 'concat' merge stratedgy
# Manually concat all of the META-INF/plexus/components.xml files into a "master" file and then choose that file as the one included in the fat-jar.
My SBT assembly configuration now looks like this. The attached components.xml file is in my project under src/main/resources/META-INF/plexus/components.xml.
{code:scala}
assemblyMergeStrategy in assembly := {
case PathList( "META-INF", "MANIFEST.MF" ) => MergeStrategy.discard
case PathList( "reference.conf" ) => MergeStrategy.concat
case PathList( "META-INF", "kie.conf" ) => MergeStrategy.concat
case PathList( "META-INF", "sisu", "javax.inject.Named" ) => MergeStrategy.concat
case PathList( "META-INF", "plexus", "components.xml" ) => MergeStrategy.first
case x => MergeStrategy.last
}
{code}
> KieScanner in Scala fat-jar application does not work due to Plexus configuration
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-3277
> URL: https://issues.jboss.org/browse/DROOLS-3277
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 7.13.0.Final
> Reporter: Michael Reynolds
> Assignee: Mario Fusco
> Priority: Major
> Attachments: components.xml, out.log
>
>
> The configuration required for all the KIE related components wired together with Sisu and in Plexus is spread out among many files with the same name/location in various library jars.
> The SBT assembly plugin is the standard for building a Scala fat-jar application. When it multiple versions of the same file when squashing the jars together it attempts to apply a merge strategy to them. For the Sisu configuration, it is simple enough to apply a "concat" merge strategy. However, the META-INF/plexus/components.xml cannot be automatically merged. Unless all the elements are present, various component lookups will fail when using the KieScanner.
> I've provided the following attachments related to this case:
> ||File||Description||
> |out.log|Output of starting the fat-jar application without properly merging the Sisu and Plexus configuration files|
> |components.xml|The merged components.xml file I created that resolves this issue.|
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3277) KieScanner in Scala fat-jar application does not work due to Plexus configuration
by Michael Reynolds (Jira)
[ https://issues.jboss.org/browse/DROOLS-3277?page=com.atlassian.jira.plugi... ]
Michael Reynolds edited comment on DROOLS-3277 at 11/7/18 4:42 PM:
-------------------------------------------------------------------
To make this work in my SBT build, I had to do the following:
# Make META-INF/sisu/javax.named.Inject a 'concat' merge strategy
# Manually concat all of the META-INF/plexus/components.xml files into a "master" file and then choose that file as the one included in the fat-jar.
My SBT assembly configuration now looks like this. The attached components.xml file is in my project under src/main/resources/META-INF/plexus/components.xml.
{code:scala}
assemblyMergeStrategy in assembly := {
case PathList( "META-INF", "MANIFEST.MF" ) => MergeStrategy.discard
case PathList( "reference.conf" ) => MergeStrategy.concat
case PathList( "META-INF", "kie.conf" ) => MergeStrategy.concat
case PathList( "META-INF", "sisu", "javax.inject.Named" ) => MergeStrategy.concat
case PathList( "META-INF", "plexus", "components.xml" ) => MergeStrategy.first
case x => MergeStrategy.last
}
{code}
was (Author: reynoldsm88):
To make this work in my SBT build, I had to do the following:
# Make META-INF/sisu/javax.named.Inject a 'concat' merge stratedgy
# Manually concat all of the META-INF/plexus/components.xml files into a "master" file and then choose that file as the one included in the fat-jar.
My SBT assembly configuration now looks like this. The attached components.xml file is in my project under src/main/resources/META-INF/plexus/components.xml.
{code:scala}
assemblyMergeStrategy in assembly := {
case PathList( "META-INF", "MANIFEST.MF" ) => MergeStrategy.discard
case PathList( "reference.conf" ) => MergeStrategy.concat
case PathList( "META-INF", "kie.conf" ) => MergeStrategy.concat
case PathList( "META-INF", "sisu", "javax.inject.Named" ) => MergeStrategy.concat
case PathList( "META-INF", "plexus", "components.xml" ) => MergeStrategy.first
case x => MergeStrategy.last
}
{code}
> KieScanner in Scala fat-jar application does not work due to Plexus configuration
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-3277
> URL: https://issues.jboss.org/browse/DROOLS-3277
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 7.13.0.Final
> Reporter: Michael Reynolds
> Assignee: Mario Fusco
> Priority: Major
> Attachments: components.xml, out.log
>
>
> The configuration required for all the KIE related components wired together with Sisu and in Plexus is spread out among many files with the same name/location in various library jars.
> The SBT assembly plugin is the standard for building a Scala fat-jar application. When it multiple versions of the same file when squashing the jars together it attempts to apply a merge strategy to them. For the Sisu configuration, it is simple enough to apply a "concat" merge strategy. However, the META-INF/plexus/components.xml cannot be automatically merged. Unless all the elements are present, various component lookups will fail when using the KieScanner.
> I've provided the following attachments related to this case:
> ||File||Description||
> |out.log|Output of starting the fat-jar application without properly merging the Sisu and Plexus configuration files|
> |components.xml|The merged components.xml file I created that resolves this issue.|
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3277) KieScanner in Scala fat-jar application does not work due to Plexus configuration
by Michael Reynolds (Jira)
[ https://issues.jboss.org/browse/DROOLS-3277?page=com.atlassian.jira.plugi... ]
Michael Reynolds updated DROOLS-3277:
-------------------------------------
Issue Type: Bug (was: Feature Request)
> KieScanner in Scala fat-jar application does not work due to Plexus configuration
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-3277
> URL: https://issues.jboss.org/browse/DROOLS-3277
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.13.0.Final
> Reporter: Michael Reynolds
> Assignee: Mario Fusco
> Priority: Major
> Attachments: components.xml, out.log
>
>
> The configuration required for all the KIE related components wired together with Sisu and in Plexus is spread out among many files with the same name/location in various library jars.
> The SBT assembly plugin is the standard for building a Scala fat-jar application. When it multiple versions of the same file when squashing the jars together it attempts to apply a merge strategy to them. For the Sisu configuration, it is simple enough to apply a "concat" merge strategy. However, the META-INF/plexus/components.xml cannot be automatically merged. Unless all the elements are present, various component lookups will fail when using the KieScanner.
> I've provided the following attachments related to this case:
> ||File||Description||
> |out.log|Output of starting the fat-jar application without properly merging the Sisu and Plexus configuration files|
> |components.xml|The merged components.xml file I created that resolves this issue.|
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months