[JBoss JIRA] (WFLY-10861) MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10861?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-10861:
-----------------------------------
This will be fixed in the core upgrade containing WFCORE-4045
> MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10861
> URL: https://issues.jboss.org/browse/WFLY-10861
> Project: WildFly
> Issue Type: Bug
> Components: Management, MP Health
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
> Priority: Blocker
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> ----
> Kabir edit: the full command is:
> /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
> ----
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> -I marked this as minor bug.- ... see comments
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-118) [Artemis 2.x upgrade] Transaction remained in prepared state
by Erich Duda (JIRA)
Erich Duda created WFWIP-118:
--------------------------------
Summary: [Artemis 2.x upgrade] Transaction remained in prepared state
Key: WFWIP-118
URL: https://issues.jboss.org/browse/WFWIP-118
Project: WildFly WIP
Issue Type: Bug
Reporter: Erich Duda
Assignee: Kabir Khan
Priority: Blocker
*Scenario*
* Start group A of two servers (node-1 and node-3) Servers are not in cluster.
* Send messages to queue on node-1.
* Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
* Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
* Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
* Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
*Investigation of issue is in progress. It is not known what component causes it.*
Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
{quote}I looked at the output from the clients, and filtered the processing
for one XA that's never commited..
I looked for the XID on
base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
and filtered the onMessage that generated it (attached the log as
processingOneMessage.txt):
This XID was never commited simply because the TM never did it.
Probably because of some issue on the JDBC.. but there are no errors,
no exceptions.. totally clean on artemis side.
There are no logging for TM or the MDB itself to correlate other
failures. With the information I have I am certain there were nothing
from Artemis side that would have caused it.
In any case.. this is not replicated at all.. and not related to 87.
This is simply the TM getting confused for some issue on the JDBC.
As far as I am concerned I have fixed the replicated shutdown case.
and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-95) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-95?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor commented on WFWIP-95:
------------------------------------
{quote}Unfortunately, it is not acceptable to expect a user to make a code change when upgrading to a minor EAP 7.* version.
I agree with Brad Maxwell 's recommended action to deprecate it so that we can remove support in EAP Next.{quote}
[~bilge] Understood. Thanks.
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFWIP-95
> URL: https://issues.jboss.org/browse/WFWIP-95
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4048) Unable to configure custom security realm in deployment
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4048?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-4048:
------------------------------------------
Yes JASPI and EE Security are looking to be added in WildFly 15, both of those allow the implementations to live within a deployment.
I have converted this to a feature request as we still my want to look into some form of dynamic security domain from a deployment for use by just that deployment.
> Unable to configure custom security realm in deployment
> -------------------------------------------------------
>
> Key: WFCORE-4048
> URL: https://issues.jboss.org/browse/WFCORE-4048
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 6.0.0.CR2
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Original user report [1]:
> Hello everyone, I am migrating from legacy security to Elytron, and I have a problem. Is there anyone who can help me? We have a custom login-module that queries infinispan cache (which maps simple bearer tokens to user names), and then queries the database (to get user roles), and on commit essentially wraps it up in Principal object. Elytron doesn't have login-modules, but security realms. There is no default realm that matches our desired functionality, so we need to define a new custom-realm. The problem is, security realms can be defined with classes in wildfly "modules", not deployments. And since "modules" can't contain EJB's, I can't inject neither infinispan cache nor database entity manager in the code. Please help what is the right way to go here
> I was thinking about it and I have come to conclusion that Elytron is not able to do the same as legacy. I assume that user is right that you cant use EE features in modules. And it looks to me Elytorn does not allow dependency on deployment module. Because Elytron checks existance of module in time of starting and deployment can be not loaded yet. In legacy existance verification is apparently postponed to time of usage.
> So I assume in legacy you can define custom login module in deployment (with EE annotations) and register such login module in security subsystem. And dependencies are resolved in runtime and not in boottime.
> [1] https://wildfly.hipchat.com/embedded/history/room/699248/2018/07/18?p=1&q...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4048) Unable to configure custom security realm in deployment
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4048?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-4048:
-------------------------------------
Issue Type: Feature Request (was: Bug)
> Unable to configure custom security realm in deployment
> -------------------------------------------------------
>
> Key: WFCORE-4048
> URL: https://issues.jboss.org/browse/WFCORE-4048
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 6.0.0.CR2
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Original user report [1]:
> Hello everyone, I am migrating from legacy security to Elytron, and I have a problem. Is there anyone who can help me? We have a custom login-module that queries infinispan cache (which maps simple bearer tokens to user names), and then queries the database (to get user roles), and on commit essentially wraps it up in Principal object. Elytron doesn't have login-modules, but security realms. There is no default realm that matches our desired functionality, so we need to define a new custom-realm. The problem is, security realms can be defined with classes in wildfly "modules", not deployments. And since "modules" can't contain EJB's, I can't inject neither infinispan cache nor database entity manager in the code. Please help what is the right way to go here
> I was thinking about it and I have come to conclusion that Elytron is not able to do the same as legacy. I assume that user is right that you cant use EE features in modules. And it looks to me Elytorn does not allow dependency on deployment module. Because Elytron checks existance of module in time of starting and deployment can be not loaded yet. In legacy existance verification is apparently postponed to time of usage.
> So I assume in legacy you can define custom login module in deployment (with EE annotations) and register such login module in security subsystem. And dependencies are resolved in runtime and not in boottime.
> [1] https://wildfly.hipchat.com/embedded/history/room/699248/2018/07/18?p=1&q...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-95) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-95?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor commented on WFWIP-95:
------------------------------------
[~ehugonnet] This will require a WildFly change to include the properties file in the WF client. Is this something you can take care of?
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFWIP-95
> URL: https://issues.jboss.org/browse/WFWIP-95
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3962) Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3962?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-3962:
----------------------------------
Description:
As per request, copying MODULES-372 to WFCORE as well.
*Affected scripts*
\[standalone|domain|add-user|appclient|jboss-cli|jdr|vault|wsconsume|wsprovide\].\[bat|sh|ps1\]
*Logs*
Starting WFLY with JDK 11 using {{standalone.sh}} yields:
{code}
org.jboss.modules.ModuleNotFoundException: java.se
at org.jboss.modules.Module.addPaths(Module.java:1266)
at org.jboss.modules.Module.link(Module.java:1622)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:437)
{code}
Output of {{java -version}}:
{code}
openjdk version "11-ea" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11-ea+21)
OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
{code}
was:
As per request, copying MODULES-372 to WFCORE as well.
Affected scripts are:
\[standalone|domain|add-user|appclient|jboss-cli|jdr|vault|wsconsume|wsprovide\].\[bat|sh|ps1\]
Starting WFLY with JDK 11 using {{standalone.sh}} yields:
{code}
org.jboss.modules.ModuleNotFoundException: java.se
at org.jboss.modules.Module.addPaths(Module.java:1266)
at org.jboss.modules.Module.link(Module.java:1622)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:437)
{code}
Output of {{java -version}}:
{code}
openjdk version "11-ea" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11-ea+21)
OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
{code}
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3962
> URL: https://issues.jboss.org/browse/WFCORE-3962
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Modules, Scripts
> Affects Versions: 6.0.0.Alpha3
> Reporter: Matej Novotny
> Assignee: Richard Opalka
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> As per request, copying MODULES-372 to WFCORE as well.
> *Affected scripts*
> \[standalone|domain|add-user|appclient|jboss-cli|jdr|vault|wsconsume|wsprovide\].\[bat|sh|ps1\]
> *Logs*
> Starting WFLY with JDK 11 using {{standalone.sh}} yields:
> {code}
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> {code}
> Output of {{java -version}}:
> {code}
> openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+21)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3962) Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3962?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-3962:
----------------------------------
Description:
As per request, copying MODULES-372 to WFCORE as well.
Affected scripts are:
\[standalone|domain|add-user|appclient|jboss-cli|jdr|vault|wsconsume|wsprovide\].\[bat|sh|ps1\]
Starting WFLY with JDK 11 using {{standalone.sh}} yields:
{code}
org.jboss.modules.ModuleNotFoundException: java.se
at org.jboss.modules.Module.addPaths(Module.java:1266)
at org.jboss.modules.Module.link(Module.java:1622)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:437)
{code}
Output of {{java -version}}:
{code}
openjdk version "11-ea" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11-ea+21)
OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
{code}
was:
As per request, copying MODULES-372 to WFCORE as well.
Starting WFLY with JDK 11 using {{standalone.sh}} yields:
{code}
org.jboss.modules.ModuleNotFoundException: java.se
at org.jboss.modules.Module.addPaths(Module.java:1266)
at org.jboss.modules.Module.link(Module.java:1622)
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
at org.jboss.modules.Main.main(Main.java:437)
{code}
Output of {{java -version}}:
{code}
openjdk version "11-ea" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11-ea+21)
OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
{code}
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3962
> URL: https://issues.jboss.org/browse/WFCORE-3962
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Modules, Scripts
> Affects Versions: 6.0.0.Alpha3
> Reporter: Matej Novotny
> Assignee: Richard Opalka
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> As per request, copying MODULES-372 to WFCORE as well.
> Affected scripts are:
> \[standalone|domain|add-user|appclient|jboss-cli|jdr|vault|wsconsume|wsprovide\].\[bat|sh|ps1\]
> Starting WFLY with JDK 11 using {{standalone.sh}} yields:
> {code}
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> {code}
> Output of {{java -version}}:
> {code}
> openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+21)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-90) [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-90?page=com.atlassian.jira.plugin.s... ]
Erich Duda commented on WFWIP-90:
---------------------------------
I noticed that the messages are not delivered because after restart of one server, the Artemis cluster is not connected. So I tried to use Netty multicast as discovery service (instead of JGroups) and the reproducer passed 50 times in row. It looks this is JGroups issue. [~pferraro] can you please take a look?
> [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
> -------------------------------------------------------------------------------
>
> Key: WFWIP-90
> URL: https://issues.jboss.org/browse/WFWIP-90
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
>
> There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
> Test scenario:
> * Start 2 server in Artemis cluster
> * Start 2 servers with MDB connected to Artemis cluster
> ** MDB resends messages from InQueue to OutQueue from/to remote cluster
> * Send messages to InQueue
> * Restart all server (one by one)
> * Consumes messages from OutQueue
> Results:
> After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months