[JBoss JIRA] (WFLY-4244) Naming alias to datasource in deployment
by Katarina Hermanova (Jira)
[ https://issues.jboss.org/browse/WFLY-4244?page=com.atlassian.jira.plugin.... ]
Katarina Hermanova closed WFLY-4244.
------------------------------------
Resolution: Out of Date
> Naming alias to datasource in deployment
> ----------------------------------------
>
> Key: WFLY-4244
> URL: https://issues.jboss.org/browse/WFLY-4244
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.2.0.Final
> Reporter: Frank Denninger
> Assignee: Katarina Hermanova
> Priority: Minor
>
> Using a name alias to a datasource that is defined in the deployment (with a *-ds.xml in the .war) causes a npe when jpa tries to resolve that datasource with the alias.
> <lookup name="java:/de/datasource/sub" lookup="java:/de/datasource/main"/>
> When both the datasource and name-alias are defined in the standalone.xml it works as expected.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-4806) The fields of a DataObject used in a pattern aren't presented in the menu list
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4806?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-4806:
-------------------------------------
[~mdessi] thank you for recheck. It is expected behavior. Our Guided designers (rules, tables, templates) do not support hot reload. It means if you change model java classes, you need to save them, and then open the guided editor. If the guided editor was opened at the time of changing java class, you need to reopen the guided editor.
I am closing this jira, if you spot similar issue but you followed the order (1. save java class, open/reopen guided editor) feel free to reopen it.
Thank you.
> 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)
4 years, 5 months
[JBoss JIRA] (WFLY-12827) Class not found com.sun.xml.internal.ws.encoding.StringDataContentHandler
by Dominik Derwiński (Jira)
[ https://issues.jboss.org/browse/WFLY-12827?page=com.atlassian.jira.plugin... ]
Dominik Derwiński edited comment on WFLY-12827 at 11/27/19 2:35 AM:
--------------------------------------------------------------------
For now I have confirmed your findings that mailcap[-default] files are only in jakarta.activation-1.2.1.jar and jakarta.mail-1.6.4.jar, and they do not reference those wrong classes directly.
I have also found out that WildFly uses com.sun.activation:jakarta.activation:1.21 which contains com.sun.activation.registries and com.sun.activation.viewers packages, whereas pulling JAXB and JAX-WS reference implementations (org.glassfish.jaxb:jaxb-runtime:2.3.2 and com.sun.xml.ws:jaxws-rt:2.3.2) into my projects (I don't want to deal with specifics of using two different implementations of those standards in EE apps, and standalone apps + test classes; and on JDK 11 have no choice but to add them as dependencies), pulls jakarta.activation:jakarta.activation-api:jar:1.2.1, which contains same classes as com.sun.activation:jakarta.activation:1.21 in javax.activation package, but no com.sun.* packages and no mailcap.default file.
Similar issues may arise from pulling jakarta.mail:jakarta.mail-api:jar:1.6.4 (no mailcap file) instead of com.sun.mail:jakarta.mail:1.6.4 (has mailcap file and depends on com.sun.activation:jakarta.activation).
Seems like it may be a problem of my own making, created by the confusion of removing classes in JDK and Jakarta EE renames. I'll check if the problem will be gone with fixing the dependencies. It will be extra work to exclude standard activation api dependencies from JAXB and JAX-WS RIs (I use duplicate finder to prevent duplicate classes on classpath).
was (Author: morvael):
For now I have confirmed your findings that mailcap[-default] files are only in jakarta.activation-1.2.1.jar and jakarta.mail-1.6.4.jar, and they do not reference those wrong classes directly.
I have also found out that WildFly uses com.sun.activation:jakarta.activation:1.21 which contains com.sun.activation.registries and com.sun.activation.viewers packages, whereas pulling JAXB and JAX-WS reference implementations (org.glassfish.jaxb:jaxb-runtime:2.3.2 and com.sun.xml.ws:jaxws-rt:2.3.2) into my projects (I don't want to deal with specifics of using two different implementations of those standards in EE apps, and standalone apps + test classes; and on JDK 11 have no choice but to add them as dependencies), pulls jakarta.activation:jakarta.activation-api:jar:1.2.1, which contains same classes as com.sun.activation:jakarta.activation:1.21 in javax.activation package, but no com.sun.* packages and no mailcap.default file.
Similar issues may arise from pulling jakarta.mail:jakarta.mail-api:jar:1.6.4 (no mailcap file) instead of com.sun.mail:jakarta.mail:1.6.4 (has mailcap file and depends on com.sun.activation:jakarta.activation).
Seems like it may be a problem of my own making, created by the confusion of removing classes in JDK and Jakarta EE renames. I'll check if the problem will be gone with fixing the dependencies.
> 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)
4 years, 5 months
[JBoss JIRA] (DROOLS-4808) [DMN Designer] Time Constraint picker remains shown
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4808?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-4808:
-------------------------------------
The video comes from times before KOGITO-523, the issue recorded in this jira is picker shown after constraint popup was closed. Sorry for confusion.
> [DMN Designer] Time Constraint picker remains shown
> ---------------------------------------------------
>
> Key: DROOLS-4808
> URL: https://issues.jboss.org/browse/DROOLS-4808
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: karreiro
> Priority: Optional
> Labels: drools-tools
> Attachments: Screenshot from 2019-11-26 16-44-21.png, time-range-2.webm
>
>
> See the attached video, there is scenario, when a timzeone/timeofset picker remains shown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFLY-12827) Class not found com.sun.xml.internal.ws.encoding.StringDataContentHandler
by Dominik Derwiński (Jira)
[ https://issues.jboss.org/browse/WFLY-12827?page=com.atlassian.jira.plugin... ]
Dominik Derwiński commented on WFLY-12827:
------------------------------------------
For now I have confirmed your findings that mailcap[-default] files are only in jakarta.activation-1.2.1.jar and jakarta.mail-1.6.4.jar, and they do not reference those wrong classes directly.
I have also found out that WildFly uses com.sun.activation:jakarta.activation:1.21 which contains com.sun.activation.registries and com.sun.activation.viewers packages, whereas pulling JAXB and JAX-WS reference implementations (org.glassfish.jaxb:jaxb-runtime:2.3.2 and com.sun.xml.ws:jaxws-rt:2.3.2) into my projects (I don't want to deal with specifics of using two different implementations of those standards in EE apps, and standalone apps + test classes; and on JDK 11 have no choice but to add them as dependencies), pulls jakarta.activation:jakarta.activation-api:jar:1.2.1, which contains same classes as com.sun.activation:jakarta.activation:1.21 in javax.activation package, but no com.sun.* packages and no mailcap.default file.
Similar issues may arise from pulling jakarta.mail:jakarta.mail-api:jar:1.6.4 (no mailcap file) instead of com.sun.mail:jakarta.mail:1.6.4 (has mailcap file and depends on com.sun.activation:jakarta.activation).
Seems like it may be a problem of my own making, created by the confusion of removing classes in JDK and Jakarta EE renames. I'll check if the problem will be gone with fixing the dependencies.
> 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)
4 years, 5 months
[JBoss JIRA] (DROOLS-4805) Memory leak in STREAM mode (# PointInTimeTriggers growing)
by Jesse White (Jira)
[ https://issues.jboss.org/browse/DROOLS-4805?page=com.atlassian.jira.plugi... ]
Jesse White commented on DROOLS-4805:
-------------------------------------
I think the problem may be related to the fact that our events are not strictly ordered sequentially in time.
I have a test case that reproduces the problem here: https://gist.github.com/j-white/7adee3e5c628f012ea83cd69695b93f9
(if the value of delta == 0, then the events are effectively ordered, otherwise they are random)
With out-of-order events {{org.drools.core.time.impl.TrackableTimeJobFactoryManager#addTimerJobInstance}} gets called many times and {{#removeTimerJobInstance}} is never called, leading to growth in the {{timerInstances}} map.
With ordered events, {{#addTimerJobInstance}} is only called once.
> Memory leak in STREAM mode (# PointInTimeTriggers growing)
> ----------------------------------------------------------
>
> Key: DROOLS-4805
> URL: https://issues.jboss.org/browse/DROOLS-4805
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.29.0.Final
> Reporter: Jesse White
> Assignee: Mario Fusco
> Priority: Major
> Attachments: image-2019-11-25-10-31-07-281.png
>
>
> When running our engine in STREAM mode, we notice a number of Drools internal object references increasing time even though the fact count stays relatively constant.
> jmap -histo <pid> shows:
> {noformat}
> num #instances #bytes class name
> ----------------------------------------------
> 1: 17478466 1258449552 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
> 2: 17475174 699006960 org.drools.core.time.impl.JDKTimerService$JDKJobHandle
> 3: 17762331 568394592 java.util.concurrent.ConcurrentHashMap$Node
> 4: 17475174 559205568 org.drools.core.rule.SlidingTimeWindow$BehaviorJobContext
> 5: 17475174 559205568 org.drools.core.time.impl.DefaultTimerJobInstance
> 6: 8596776 551411680 [C
> 7: 18898675 453568200 java.lang.Long
> 8: 17475174 419404176 org.drools.core.time.SelfRemovalJobContext
> 9: 17475174 279602784 org.drools.core.time.SelfRemovalJob
> 10: 17475174 279602784 org.drools.core.time.impl.PointInTimeTrigger
> 11: 9263698 222328752 java.lang.String
> 12: 4584671 146709472 java.util.HashMap$Node
> 13: 246658 138804176 [B
> {noformat}
> These number continue to increase over time until the system OOMs.
> Graph for # of facts in the session looks like:
> !image-2019-11-25-10-31-07-281.png|thumbnail!
> The engine is fairly busy - we're constantly adding and removing facts.
> Our rules are available here:
> https://github.com/OpenNMS/opennms/blob/opennms-25.0.0-1/opennms-base-ass...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months