[JBoss JIRA] (WFCORE-1950) Get rid of system property for turning off 'strict' transformers rejection testing
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-1950:
----------------------------------
Summary: Get rid of system property for turning off 'strict' transformers rejection testing
Key: WFCORE-1950
URL: https://issues.jboss.org/browse/WFCORE-1950
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 3.0.0.Alpha12
WFCORE-1892 reworks the rejection transformers testing, and tightens it up a bit. Most things work fine with this stricter checking, apart from ejb3 which needs reworking. To get around this WFCORE-1892 has a temporary system property to disable this stricter checking.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1313:
---------------------------------------
Can someone confirm that the code in this post illustrates the correct / supported way to do incremental builds?
https://issues.jboss.org/browse/DROOLS-765
> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
> Key: DROOLS-1313
> URL: https://issues.jboss.org/browse/DROOLS-1313
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> - Create a new ReleaseId
> - Create a new KieFileSystem
> - Generate and write the PomXML for the ReleaseId created above
> - Create a new KieModuleModel
> - Create a new KieBaseModel
> - Write the ModuleModel XML to the KieFileSystem
> - Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> - Create a new KieBuilder
> - Do a buildall() with the KieBuilder
> - Create a new KieContainer
> - Create a new KieSession from the KieContainer
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> - Delete 2 rules from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
> - Rule_120_Triggered_Part_1_ 0 is not there
> - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> - Delete 1 rule from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
> - Rule_120_Triggered_Part_1_ 0 is STILL not there
> - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1902) Error messages from CLI batch should be more informative
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1902:
----------------------------------------------
[~mkopecky],
the CLI.next merge is far from being ready. We plan to evolve our dependency on aesh to aesh-readline first. This is work in progress that should be coming much sooner.
> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
> Key: WFCORE-1902
> URL: https://issues.jboss.org/browse/WFCORE-1902
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 3.0.0.Alpha10
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Labels: user_experience
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
> "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
> "Operation step-3" => {
> "operation" => ":read-attribute(name=nonsence)"
> "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGMGR-143) NullPointer in JbossAppenderHandler.doPublish() degrades performance
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-143?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-143:
--------------------------------------
Something must be adding a {{null}} appender. We should probably just guard against {{null}} from being added to the list.
> NullPointer in JbossAppenderHandler.doPublish() degrades performance
> --------------------------------------------------------------------
>
> Key: LOGMGR-143
> URL: https://issues.jboss.org/browse/LOGMGR-143
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1.0.GA
> Environment: Windows 7 x64
> WildFly 8
> Java 8.0_102
> Reporter: David Frank
>
> I don't have code I can send to reproduce this, but if the issue doesn't show up readily, I can try to create it.
> I noticed while doing some performance monitoring of WildFly with JVisualVM, that JBossAppenderHandler.doPublish() kept popping up in the top 5 for Self Time (CPU). This is the method:
> {code:java}
> 36 @Override
> 37 protected void More ...doPublish(final ExtLogRecord record) {
> 38 final LoggingEvent event = new LoggingEvent(record, JBossLogManagerFacade.getLogger(logger));
> 39 final List<Appender> appenders = getAppenderList(logger);
> 40 for (Appender appender : appenders) {
> 41 if (new JBossFilterWrapper(appender.getFilter(), true).isLoggable(record)) {
> 42 appender.doAppend(event);
> 43 }
> 44 }
> 45 }
> {code}
> After attaching the Eclipse debugger to it, I found the following:
> 1) The logger's name was ""
> 2) The appender list returend from getAppendersList(logger) had one element in it, and it was null. So the for loop following it would throw the null pointer.
> I put a quick hack in place to see how much of an impact this was having, basically putting a if(appender != null) check within the for loop. My average CPU load for WildFly dropped from about 173% to 130%.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1902) Error messages from CLI batch should be more informative
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1902:
-------------------------------------
Issue Type: Enhancement (was: Feature Request)
I've changed this to an Enhancement.
> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
> Key: WFCORE-1902
> URL: https://issues.jboss.org/browse/WFCORE-1902
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 3.0.0.Alpha10
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Labels: user_experience
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
> "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
> "Operation step-3" => {
> "operation" => ":read-attribute(name=nonsence)"
> "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1902) Error messages from CLI batch should be more informative
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugi... ]
Marek Kopecký commented on WFCORE-1902:
---------------------------------------
[~jdenise]: Ok, I remove "line number" from description of this jira. In my point of view, this could be implemented in CLI today and also in the CLI.next. Btw, when do you plan to merge CLI.next to WildFly-Core?
> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
> Key: WFCORE-1902
> URL: https://issues.jboss.org/browse/WFCORE-1902
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 3.0.0.Alpha10
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Labels: user_experience
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
> "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
> "Operation step-3" => {
> "operation" => ":read-attribute(name=nonsence)"
> "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1902) Error messages from CLI batch should be more informative
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-1902:
----------------------------------
Description:
*Description of problem:*
Error messages from CLI batch should be more informative
*Steps to Reproduce:*
{noformat}
cat <<EOF >a
batch
:read-attribute(name=product-version)
:read-attribute(name=product-name)
:read-attribute(name=nonsence)
:read-attribute(name=product-name)
run-batch
EOF
./jboss-cli.sh -c --file=a
{noformat}
*Actual results:*
{noformat}
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
{noformat}
*Expected results:*
I can imagine content like following could be helpful for troubleshooting:
{noformat}
{
"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
"Operation step-3" => {
"operation" => ":read-attribute(name=nonsence)"
"response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
}
}
{noformat}
was:
*Description of problem:*
Error messages from CLI batch should be more informative
*Steps to Reproduce:*
{noformat}
cat <<EOF >a
batch
:read-attribute(name=product-version)
:read-attribute(name=product-name)
:read-attribute(name=nonsence)
:read-attribute(name=product-name)
run-batch
EOF
./jboss-cli.sh -c --file=a
{noformat}
*Actual results:*
{noformat}
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
{noformat}
*Expected results:*
I can imagine content like following could be helpful for troubleshooting:
{noformat}
{
"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
"Operation step-3" => {
"line number" => 4
"operation" => ":read-attribute(name=nonsence)"
"response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
}
}
{noformat}
> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
> Key: WFCORE-1902
> URL: https://issues.jboss.org/browse/WFCORE-1902
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 3.0.0.Alpha10
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Labels: user_experience
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
> "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
> "Operation step-3" => {
> "operation" => ":read-attribute(name=nonsence)"
> "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-727) Support verification of a users certificate against an LDAP Server
by Jan Kalina (JIRA)
Jan Kalina created ELY-727:
------------------------------
Summary: Support verification of a users certificate against an LDAP Server
Key: ELY-727
URL: https://issues.jboss.org/browse/ELY-727
Project: WildFly Elytron
Issue Type: Feature Request
Components: Realms, SSL
Reporter: Jan Kalina
Assignee: Jan Kalina
Fix For: 1.1.0.Beta13
LDAP realm should be able to authenticate user using user certificate.
This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7505) Support verification of a users certificate against an LDAP Server
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7505?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved ELY-727 to WFLY-7505:
--------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-7505 (was: ELY-727)
Component/s: Security
(was: Realms)
(was: SSL)
Fix Version/s: (was: 1.1.0.Beta13)
> Support verification of a users certificate against an LDAP Server
> ------------------------------------------------------------------
>
> Key: WFLY-7505
> URL: https://issues.jboss.org/browse/WFLY-7505
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> LDAP realm should be able to authenticate user using user certificate.
> This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months