[JBoss JIRA] (WFLY-12827) Class not found com.sun.xml.internal.ws.encoding.StringDataContentHandler
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12827?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12827:
-----------------------------------------
[~morvael] Do you understand why it wants to load com.sun.xml.internal.ws.encoding.StringDataContentHandler? I've been poking trying to understand where that's specified and I'm not seeing it. Perhaps you know as you've been digging into this some.
[~yersan] FYI.
> Class not found com.sun.xml.internal.ws.encoding.StringDataContentHandler
> -------------------------------------------------------------------------
>
> Key: WFLY-12827
> URL: https://issues.jboss.org/browse/WFLY-12827
> Project: WildFly
> Issue Type: Bug
> Components: Mail
> Affects Versions: 18.0.1.Final
> Reporter: Dominik Derwiński
> Assignee: Tomaž Cerar
> Priority: Major
>
> Trying to send email I get:
> {noformat}
> [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : MailcapCommandMap: createDataContentHandler for text/plain
> [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : search DB #0
> [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : got content-handler
> [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : class com.sun.xml.internal.ws.encoding.StringDataContentHandler
> [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [49] : Can't load DCH com.sun.xml.internal.ws.encoding.StringDataContentHandler: java.lang.ClassNotFoundException: com.sun.xml.internal.ws.encoding.StringDataContentHandler from [Module "javax.activation.api" version 1.2.1 from local module loader @82de64a (finder: local module finder @659499f1 (roots: /u01/wildfly/wildfly18/modules,/u01/wildfly/wildfly18/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:315)
> at javax.activation.api@1.2.1//javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:598)
> at javax.activation.api@1.2.1//javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:555)
> at javax.activation.api@1.2.1//javax.activation.DataHandler.getDataContentHandler(DataHandler.java:600)
> at javax.activation.api@1.2.1//javax.activation.DataHandler.writeTo(DataHandler.java:299)
> at javax.mail.api@1.6.4//javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:316)
> at javax.mail.api@1.6.4//javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1551)
> at javax.mail.api@1.6.4//javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1148)
> at javax.mail.api@1.6.4//javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:498)
> at javax.mail.api@1.6.4//javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1509)
> at javax.mail.api@1.6.4//javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2238)
> at javax.mail.api@1.6.4//javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2198)
> at javax.mail.api@1.6.4//javax.mail.Transport.send(Transport.java:99)
> {noformat}
> Maybe it's just missing module dependency for javax.mail.api, maybe you need to include JAXB and JAXWS libraries in WildFly modules for use on JDK 11+, when they were removed from JDK.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFWIP-160:
----------------------------------
Thanks, [~dmlloyd]. +1, it would be interesting to compare against OpenSSL performance. We just need to first update {{wildfly-openssl}} to make it possible to make use of TLSv1.3.
[~aph] As described in Richard's [previous comment|https://issues.jboss.org/browse/WFWIP-160?focusedCommentId=138157...] and in David's [previous comment|https://issues.jboss.org/browse/WFWIP-160?focusedCommentId=138181...], we are running into a performance issue in Undertow with TLSv1.3 and JDK 11. However, performance seems to improve when switching to JDK 13.0.1. What are your thoughts on this? Would it be possible to backport TLS performance improvements that have been made in newer versions to jdk11u?
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: jstourac-report.zip, performance-hotspot.png, results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Start server with JDK11 and configure with TLSv1.3:
> {code}
> $ JAVA_HOME=/path/to/java/openjdk-11.0.2 <EAP_HOME>/bin/standalone.sh
> $ <EAP_HOME>/bin/jboss-cli.sh -c
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4806) The fields of a DataObject used in a pattern aren't presented in the menu list
by Massimiliano Dessi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4806?page=com.atlassian.jira.plugi... ]
Massimiliano Dessi commented on DROOLS-4806:
--------------------------------------------
[~jomarko] Yes, if it saved (close the editors and reopen to see if all the fields of the models are present) the fields are presents, if isn't saved even if the model is present and used for the pattern the fields aren't showed in the list.
> The fields of a DataObject used in a pattern aren't presented in the menu list
> ------------------------------------------------------------------------------
>
> Key: DROOLS-4806
> URL: https://issues.jboss.org/browse/DROOLS-4806
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.30.0.Final
> Reporter: Massimiliano Dessi
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
> Attachments: 1.png, 2.png, 3.png, 4.png
>
>
> Isn't possible to create a column "Set the value of a field", the menulist doesn't show the field of the data object chosen as a pattern.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4799) Adding "expression" type handling for Collection type propereties
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4799?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-4799:
--------------------------------------
Attachment: Screen Shot 2019-11-26 at 1.26.54 PM.png
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4799
> URL: https://issues.jboss.org/browse/DROOLS-4799
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Yeser Amer
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam
> Attachments: Screen Shot 2019-11-26 at 1.26.54 PM.png
>
>
> I need a clarification regarding the behaviour of the updated Collection Editor, in particular for this section -->https://marvelapp.com/5ab248j/screen/62093042/layer/102496330.
> Considering the editor introduces a new way to handle a Collection ("Define List"), can you please give us detailed behaviour for the following case:
> - What happen if a user starts to input data inside a section (Define List/Create List) and then switch on the other one?
> eg. if I start to define a List using "Define List" option (i.e. an expression) and then I change to "Create List" case. What should happen?
> - Currently, after adding a Collection, the Grid cell will show "List (1)". It should be the same for "Define list" (i.e. Expression) case?
> In case of additional clarificaiton, I'll update this ticket.
> Hope it's clear, if not you can contact me anytime.
> Thanks
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4799) Adding "expression" type handling for Collection type propereties
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4799?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4799:
-------------------------------------------
[~yamer] My initial leaning though is to:
* If a user starts to input data inside a section (Define List/Create List) and then switch on the other one, imo the fields should clear out. We could add an inline notification if there's a concerning this will be unexpected for the user.
* After adding a Collection, the Grid cell will show "List (1)". It should be the same for "Define list" (i.e. Expression) case? - I'm not sure I'm following the question, the mockups illustrates this (is that what you're talking about)
!Screen Shot 2019-11-26 at 1.26.54 PM.png|thumbnail!
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4799
> URL: https://issues.jboss.org/browse/DROOLS-4799
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Yeser Amer
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam
> Attachments: Screen Shot 2019-11-26 at 1.26.54 PM.png
>
>
> I need a clarification regarding the behaviour of the updated Collection Editor, in particular for this section -->https://marvelapp.com/5ab248j/screen/62093042/layer/102496330.
> Considering the editor introduces a new way to handle a Collection ("Define List"), can you please give us detailed behaviour for the following case:
> - What happen if a user starts to input data inside a section (Define List/Create List) and then switch on the other one?
> eg. if I start to define a List using "Define List" option (i.e. an expression) and then I change to "Create List" case. What should happen?
> - Currently, after adding a Collection, the Grid cell will show "List (1)". It should be the same for "Define list" (i.e. Expression) case?
> In case of additional clarificaiton, I'll update this ticket.
> Hope it's clear, if not you can contact me anytime.
> Thanks
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4799) Adding "expression" type handling for Collection type propereties
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4799?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4799:
-------------------------------------------
[~yamer] I understand, but I just haven't been able to replicate that view on the CICD. So would like the video to refer to instead.
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4799
> URL: https://issues.jboss.org/browse/DROOLS-4799
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Yeser Amer
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam
>
> I need a clarification regarding the behaviour of the updated Collection Editor, in particular for this section -->https://marvelapp.com/5ab248j/screen/62093042/layer/102496330.
> Considering the editor introduces a new way to handle a Collection ("Define List"), can you please give us detailed behaviour for the following case:
> - What happen if a user starts to input data inside a section (Define List/Create List) and then switch on the other one?
> eg. if I start to define a List using "Define List" option (i.e. an expression) and then I change to "Create List" case. What should happen?
> - Currently, after adding a Collection, the Grid cell will show "List (1)". It should be the same for "Define list" (i.e. Expression) case?
> In case of additional clarificaiton, I'll update this ticket.
> Hope it's clear, if not you can contact me anytime.
> Thanks
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4810) KIE Server REST Command GetObjects with ObjectFilter not working
by Martin Weiler (Jira)
Martin Weiler created DROOLS-4810:
-------------------------------------
Summary: KIE Server REST Command GetObjects with ObjectFilter not working
Key: DROOLS-4810
URL: https://issues.jboss.org/browse/DROOLS-4810
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.15.0.Final
Environment: RHEL 7.5, EAP 7.1.0, Drools 7.15.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
Filtering the facts in the GetObjectsCommand doesn't do any object filtering!.
Here are the two code pieces that were used to set the ObjectFilter into GetObjectsCommand, but didn't produce the expected filtered results.
*+Trial 1:+*
{code:java}
ObjectFilter filter = new ObjectFilter() {
@Override
public boolean accept(Object object) {
return object.getClass().getName().equals("a.b.c.PotentialFraudFact");
}
};
Command<?> getObjects = commandsFactory.newGetObjects(filter, "out");
{code}
*+Trial 2:+*
{code:java}
ClassObjectSerializationFilter filter = new ClassObjectSerializationFilter(PotentialFraudFact.class);
Command<?> getObjects = commandsFactory.newGetObjects(filter, "out");
{code}
In the response, the "out" identifier has *all* facts, not just the ones matching the given filter. It's as if it ignores the filter. Also, no error messages appear in the console.
When a ClassObjectFilter is used instead of the aforementioned implementations, a ClassNotFoundException (_shown below_) for the a.b.c.PotentialFraudFact.class occurs. This is incorrect as the deployed container/KJAR has this class!.
{code:java}
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: a.b.c.PotentialFraudFact from [Module "deployment.kie-server.war" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.drools.core.ClassObjectSerializationFilter.accept(ClassObjectSerializationFilter.java:50)
... 73 more
{code}
The issue is with this line https://github.com/kiegroup/drools/blob/4c6856223b8be47b4fc52c35423be8b50... where the class loader used to find the class couldn't find the class that corresponds to the given Fact.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFWIP-160:
-----------------------------------
It looks like it is spending the majority of time in JDK cryptographic functions. There might not be a lot that we can do about that (beyond requesting backports of TLS performance improvements to jdk11u, which is something we can ask [~aph] about, or using the TLSv1.3 support in {{wildfly-openssl}} as previously mentioned).
It would be interesting to compare OpenSSL performance here to see if it is an implementation issue, or if it is likely to be something inherent in the selected cipher suite.
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: jstourac-report.zip, performance-hotspot.png, results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Start server with JDK11 and configure with TLSv1.3:
> {code}
> $ JAVA_HOME=/path/to/java/openjdk-11.0.2 <EAP_HOME>/bin/standalone.sh
> $ <EAP_HOME>/bin/jboss-cli.sh -c
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months