[JBoss JIRA] (DROOLS-2382) [DMN Designer] [Chrome specific] Explorer is empty
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2382?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2382:
----------------------------------------
[~jomarko] Works OK for me with Chrome 64 (running from CLI). See attached.
Reassigning to [~roger600] as the "Explorer" is a Stunner component (and not to be used by the final DMN Editor.. [~karreiro] is writing DMN's Decision Explorer).
> [DMN Designer] [Chrome specific] Explorer is empty
> --------------------------------------------------
>
> Key: DROOLS-2382
> URL: https://issues.jboss.org/browse/DROOLS-2382
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.7.0.Final
> Environment: chrome
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Attachments: DROOLS-2382.png
>
>
> If user creates DRD diagram in chrome, the diagram explorer is empty. When the same diagram is opened in firefox, the explorer correctly loads elements.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9974) Remove unused 'basic-authType' complex type in wildfly-undertow xsd file
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9974?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9974.
----------------------------------
Fix Version/s: 13.0.0.Beta1
Resolution: Done
> Remove unused 'basic-authType' complex type in wildfly-undertow xsd file
> ------------------------------------------------------------------------
>
> Key: WFLY-9974
> URL: https://issues.jboss.org/browse/WFLY-9974
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: Jan Stourac
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 13.0.0.Beta1
>
>
> Since undertow subsystem version 4.0, the [{{basic-authType}}|https://github.com/wildfly/wildfly/blob/master/undertow/src/main/resources/schema/wildfly-undertow_5_0.xsd#L578-L580] has not been utilized anymore. We should probably remove that type definition from our xsd file with another subsystem version bump.
> This type was used for {{basic-auth}} filter which is no longer present in undertow.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10010) @WebServlet is not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-10010?page=com.atlassian.jira.plugin... ]
Stuart Douglas resolved WFLY-10010.
-----------------------------------
Resolution: Duplicate Issue
This is a known issue with Wildfly 12 where classes compiled with JDK9 will not have their annotations read correctly. The only solution at this stage is to upgrade Jandex to 2.0.5.Final
> @WebServlet is not working
> --------------------------
>
> Key: WFLY-10010
> URL: https://issues.jboss.org/browse/WFLY-10010
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Final
> Environment: WildFly 12.0.0.Final
> JDK 9
> Reporter: Rakesh K. Cherukuri
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: @WebServlet
> Attachments: web-servlet-not-working.zip
>
>
> Trying to deploy a simple web module in wildfly 12 that has one servlet with @WebServlet.
> Expectation: The servlet is available at the configured URL
> Actual : Servlet is not put into service and consequently URL gets 404
> Attached is the full module.
> NOTE : The same war file works in WildFly 11 but NOT in WildFly 12
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3677) get-provider-points return /profile addresses for host level resources
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3677?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3677:
----------------------------------------------
[~claudio4j], the CLI, in domain mode query the registry of the local-host-name if no host is present in the address. Otherwise it queries the registry of the host present in the address.
For ex: /profile=default/subsystem=elytron/... ==> /host=<value of local-host-name attribute>/core-service=capability
When querying the registry (suggest-capabilities), the CLI provides the dependent-address argument. This argument is the address of the capability consumer.
For example, when completion occurs: (/profile=default/subsystem=elytron/key-manager=xxx:add(key-store=<TAB>) the following request is sent to the registry:
/host=master/core-service=capability-registry:suggest-capabilities(name=org.wildfly.security.key-store, dependent-address=[{profile=default},{subsystem=elytron},{key-manager=xxx}])
The capability has the logic to only return the subset of capabilities reachable from the dependent-address. So if you add a key-store to a profile, it will be visible from key-manager added to this profile. If you add a key-store in a given host, it will be only visible when adding a key-manager in this host.
> get-provider-points return /profile addresses for host level resources
> ----------------------------------------------------------------------
>
> Key: WFCORE-3677
> URL: https://issues.jboss.org/browse/WFCORE-3677
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Darran Lofthouse
> Priority: Minor
>
> key-manager resource at /host=master/subsystem=elytron/key-manager=*
> contains the "key-store" attribute, which has a "capability-reference" => "org.wildfly.security.key-store"
> get-provider-points returns /profile addresses that should not be a valid reference for a host level resource
> {code}
> /host=master/core-service=capability-registry:get-provider-points(name="org.wildfly.security.key-store")
> {
> "outcome" => "success",
> "result" => [
> "/host=master/subsystem=elytron/key-store=*",
> "/host=master/subsystem=elytron/ldap-key-store=*",
> "/host=master/subsystem=elytron/filtering-key-store=*",
> "/profile=*/subsystem=elytron/key-store=*",
> "/profile=*/subsystem=elytron/ldap-key-store=*",
> "/profile=*/subsystem=elytron/filtering-key-store=*",
> "/profile=*/subsystem=security/elytron-key-store=*",
> "/profile=*/subsystem=security/elytron-trust-store=*"
> ]
> }
> {code}
> A test case
> {code}
> /profile=full/subsystem=elytron/key-store=ks_full:add(credential-reference={clear-text=senha},type=JKS)
> /host=master/subsystem=elytron/key-manager=my_km:add(key-store=ks_full,credential-reference={clear-text=senha})
> {
> "outcome" => "failed",
> "result" => {},
> "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYCTL0369: Required capabilities are not available:
> org.wildfly.security.key-store.ks_full in context 'host'; Possible registration points for this capability:
> /host=master/subsystem=elytron/key-store=*
> /host=master/subsystem=elytron/ldap-key-store=*
> /host=master/subsystem=elytron/filtering-key-store=*
> /profile=*/subsystem=elytron/key-store=*
> /profile=*/subsystem=elytron/ldap-key-store=*
> /profile=*/subsystem=elytron/filtering-key-store=*
> /profile=*/subsystem=security/elytron-key-store=*
> /profile=*/subsystem=security/elytron-trust-store=*"}},
> "rolled-back" => true
> }
> {code}
> The returned addresses in the error message should contains only valid addresses.
> side note: CLI code completion works correctly in not showing resources from /profile addresses.
> /host=master/subsystem=elytron/key-manager=my_km:add(key-store=<tab>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10010) @WebServlet is not working
by Rakesh K. Cherukuri (JIRA)
Rakesh K. Cherukuri created WFLY-10010:
------------------------------------------
Summary: @WebServlet is not working
Key: WFLY-10010
URL: https://issues.jboss.org/browse/WFLY-10010
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 12.0.0.Final
Environment: WildFly 12.0.0.Final
JDK 9
Reporter: Rakesh K. Cherukuri
Assignee: Stuart Douglas
Priority: Critical
Attachments: web-servlet-not-working.zip
Trying to deploy a simple web module in wildfly 12 that has one servlet with @WebServlet.
Expectation: The servlet is available at the configured URL
Actual : Servlet is not put into service and consequently URL gets 404
Attached is the full module.
NOTE : The same war file works in WildFly 11 but NOT in WildFly 12
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9982) Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-9982?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-9982.
--------------------------------
Resolution: Done
> Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown
> ------------------------------------------------------------------------------
>
> Key: WFLY-9982
> URL: https://issues.jboss.org/browse/WFLY-9982
> Project: WildFly
> Issue Type: Bug
> Components: MSC, Server
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jason Greene
> Attachments: node-1-thread-dump-when-killed-shutdown-sequence.txt
>
>
> There is intermittent failure where server does not stop and hangs during clean shutdown.
> Investigation:
> In attached thread dump there is shutdown of WF/EAP JVM thread waiting for finishing org.jboss.as.server.BootstrapImpl$ShutdownHook:
> {code}
> "Management Triggered Shutdown" #262 prio=5 os_prio=0 tid=0x00007f931c03b800 nid=0x3900 in Object.wait() [0x00007f9296423000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000cf059e98> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> at java.lang.Thread.join(Thread.java:1252)
> - locked <0x00000000cf059e98> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> at java.lang.Thread.join(Thread.java:1326)
> at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106)
> at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
> at java.lang.Shutdown.runHooks(Shutdown.java:123)
> at java.lang.Shutdown.sequence(Shutdown.java:167)
> at java.lang.Shutdown.exit(Shutdown.java:212)
> - locked <0x00000000cedfac08> (a java.lang.Class for java.lang.Shutdown)
> at java.lang.Runtime.exit(Runtime.java:109)
> at java.lang.System.exit(System.java:971)
> at org.jboss.as.server.SystemExiter$DefaultExiter.exit(SystemExiter.java:117)
> at org.jboss.as.server.SystemExiter.logAndExit(SystemExiter.java:98)
> at org.jboss.as.server.operations.ServerShutdownHandler$ShutdownAction$1.run(ServerShutdownHandler.java:184)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> which hangs in:
> {code}
> "Thread-3" #12 prio=5 os_prio=0 tid=0x00007f92d01dc800 nid=0x3902 waiting on condition [0x00007f9296221000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fc2531d8> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.shutdown(BootstrapImpl.java:276)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.run(BootstrapImpl.java:240)
> {code}
> where ShutdownHook.shutdown(BootstrapImpl.java:276) is waiting for latch to count down however this does not happen. It seems like that not all services shut down.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9982) Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-9982?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-9982:
--------------------------------------
[~brian.stansberry] Thanks [~brian.stansberry] for great input! This was really pre-WF12 release with older WF core (4.0.0.Alpha10). I hit this with [~jmesnil] branch where I was testing Artemis 2.x integration with WF. I've already asked Jeff to rebase against latest master.
I'll close this as duplicate of WFCORE-3590.
> Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown
> ------------------------------------------------------------------------------
>
> Key: WFLY-9982
> URL: https://issues.jboss.org/browse/WFLY-9982
> Project: WildFly
> Issue Type: Bug
> Components: MSC, Server
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jason Greene
> Attachments: node-1-thread-dump-when-killed-shutdown-sequence.txt
>
>
> There is intermittent failure where server does not stop and hangs during clean shutdown.
> Investigation:
> In attached thread dump there is shutdown of WF/EAP JVM thread waiting for finishing org.jboss.as.server.BootstrapImpl$ShutdownHook:
> {code}
> "Management Triggered Shutdown" #262 prio=5 os_prio=0 tid=0x00007f931c03b800 nid=0x3900 in Object.wait() [0x00007f9296423000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000cf059e98> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> at java.lang.Thread.join(Thread.java:1252)
> - locked <0x00000000cf059e98> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> at java.lang.Thread.join(Thread.java:1326)
> at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106)
> at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
> at java.lang.Shutdown.runHooks(Shutdown.java:123)
> at java.lang.Shutdown.sequence(Shutdown.java:167)
> at java.lang.Shutdown.exit(Shutdown.java:212)
> - locked <0x00000000cedfac08> (a java.lang.Class for java.lang.Shutdown)
> at java.lang.Runtime.exit(Runtime.java:109)
> at java.lang.System.exit(System.java:971)
> at org.jboss.as.server.SystemExiter$DefaultExiter.exit(SystemExiter.java:117)
> at org.jboss.as.server.SystemExiter.logAndExit(SystemExiter.java:98)
> at org.jboss.as.server.operations.ServerShutdownHandler$ShutdownAction$1.run(ServerShutdownHandler.java:184)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> which hangs in:
> {code}
> "Thread-3" #12 prio=5 os_prio=0 tid=0x00007f92d01dc800 nid=0x3902 waiting on condition [0x00007f9296221000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fc2531d8> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.shutdown(BootstrapImpl.java:276)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.run(BootstrapImpl.java:240)
> {code}
> where ShutdownHook.shutdown(BootstrapImpl.java:276) is waiting for latch to count down however this does not happen. It seems like that not all services shut down.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10002) Incorrect number of messages on queue after remove of scheduled message
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFLY-10002?page=com.atlassian.jira.plugin... ]
Martin Styk commented on WFLY-10002:
------------------------------------
This issue affects Artemis master (5ab187b7fef5ed6ad8a857287417f55878678714)
> Incorrect number of messages on queue after remove of scheduled message
> -----------------------------------------------------------------------
>
> Key: WFLY-10002
> URL: https://issues.jboss.org/browse/WFLY-10002
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
>
> Removing scheduled message from queue cause incorrect number of messages reported by {{count-messages}} operation.
> It looks like the operation {{count-messages}} returns value equal to _actual number of messages_ minus _number of removed scheduled messages_
> *Scenario*
> # send 1 message with _AMQ_SCHED_DELIVERY property set to several minutes
> # remove scheduled emssage using CLI operation {{remove-message}}
> # find out number of messages on queue using CLI operation {{count-messages}} - it returns value -1
> This is broker related issue. It is regression against Artemis 1.5.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months