April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13384) Add IIOP Naming View Management Command

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-13384?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty reassigned WFLY-13384: ------------------------------------------ Assignee: Ranabir Chakraborty (was: Tomasz Adamski) > Add IIOP Naming View Management Command > --------------------------------------- > > Key: WFLY-13384 > URL: https://issues.redhat.com/browse/WFLY-13384 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Affects Versions: 19.0.0.Final > Reporter: Brad Maxwell > Assignee: Ranabir Chakraborty > Priority: Minor > > Currently there is not a way to view the IIOP Naming Bindings. > Similar to the JNDI View shown below, a management command to get a view of the IIOP Naming bindings would be useful. > {code} > /subsystem=naming:jndi-view > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13402) Include EJB's IIOP Binding when EJB is deployed logging

by Ranabir Chakraborty (Jira)

Ranabir Chakraborty created WFLY-13402: ------------------------------------------ Summary: Include EJB's IIOP Binding when EJB is deployed logging Key: WFLY-13402 URL: https://issues.redhat.com/browse/WFLY-13402 Project: WildFly Issue Type: Enhancement Components: IIOP Affects Versions: 12.0.0.Final Reporter: Ranabir Chakraborty Assignee: Ranabir Chakraborty Attachments: WFLY-10612.jar, java.policy It would be useful when EJBs configured with IIOP enabled or when enabled by default for all, that it log the binding for the IIOP interface as it is different from the JNDI bindings. <iiop enable-by-default="true" use-qualified-name="true"/> {code} INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome java:jboss/exported/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote java:jboss/exported/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote {code} Something like this when use-qualified-name="true" {code} IIOP bindings for for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: iiop-eap7/HelloSessionBean {code} or use-qualified-name="false" {code} IIOP bindings for for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: HelloSessionBean {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13379) Redirect after "j_security_check" login does not work if URL has no trailing slash

by Wolfgang Knauf (Jira)

[ https://issues.redhat.com/browse/WFLY-13379?page=com.atlassian.jira.plugi... ] Wolfgang Knauf commented on WFLY-13379: --------------------------------------- Thanks for the workarounds - but as I found it in one of my personal testing sample apps, there is no need for me to do much about it ;-). Does this issue has to be kept open, or will the fix be contained in the next WildFly release and it can be closed? > Redirect after "j_security_check" login does not work if URL has no trailing slash > ---------------------------------------------------------------------------------- > > Key: WFLY-13379 > URL: https://issues.redhat.com/browse/WFLY-13379 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 19.0.0.Final > Reporter: Wolfgang Knauf > Assignee: Darran Lofthouse > Priority: Major > Attachments: Security.ear, configure.cli, restore-configuration.cli > > > Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron). > When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown. > On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check > It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL. > To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this: > jboss-cli.bat --file=path_to\configure.cli > The script "restore-configuration.cli" undoes this configuration. > Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13401) MicroProfile REST Client does not handle header propagation correctly

by James Perkins (Jira)

James Perkins created WFLY-13401: ------------------------------------ Summary: MicroProfile REST Client does not handle header propagation correctly Key: WFLY-13401 URL: https://issues.redhat.com/browse/WFLY-13401 Project: WildFly Issue Type: Bug Components: MP REST Client Reporter: James Perkins Assignee: Alessio Soldano The linked forum post has some good detail on what the issue is. The gist of it is the {{org.eclipse.microprofile.rest.client.propagateHeaders}} does not seem to propagate the properties to the request headers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13399) Upgrade Infinispan to 9.4.19.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13399?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13399: -------------------------------- Priority: Critical (was: Major) > Upgrade Infinispan to 9.4.19.Final > ---------------------------------- > > Key: WFLY-13399 > URL: https://issues.redhat.com/browse/WFLY-13399 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 19.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > https://issues.redhat.com/projects/ISPN/versions/12344730 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13400) Upgrade Infinispan to 9.4.19.Final

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13400: ----------------------------------- Summary: Upgrade Infinispan to 9.4.19.Final Key: WFLY-13400 URL: https://issues.redhat.com/browse/WFLY-13400 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 19.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro https://issues.redhat.com/projects/ISPN/versions/12344730 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13399) Upgrade Infinispan to 9.4.19.Final

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13399: ----------------------------------- Summary: Upgrade Infinispan to 9.4.19.Final Key: WFLY-13399 URL: https://issues.redhat.com/browse/WFLY-13399 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 19.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro https://issues.redhat.com/projects/ISPN/versions/12344730 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules

by Wolfgang Knauf (Jira)

[ https://issues.redhat.com/browse/WFLY-3211?page=com.atlassian.jira.plugin... ] Wolfgang Knauf commented on WFLY-3211: -------------------------------------- My original sample is still not working in WildFly 19. But: I managed to make it functioning - don't know whether my solution/workaround is correct: a) in "jboss-client.xml" of the ApplicationClient project, use the JNDI name "java:/jms/queue/MessageBeanQueue" instead of "java:app/jms/queue/MessageBeanQueue". {{<jboss-client ...> <jndi-name>MessageClient</jndi-name> <resource-ref> <res-ref-name>jms/MBConnectionFactory</res-ref-name>  <jndi-name>java:/ConnectionFactory</jndi-name> </resource-ref> <resource-ref> <res-ref-name>jms/MBQueueRef</res-ref-name> <jndi-name>java:/jms/queue/MessageBeanQueue</jndi-name> </resource-ref> </jboss-client>}} b) in "%WILDFLY_HOME%\appclient\configuration\appclient.xml", also declare the Queue and point it to "java:/jms/queue/MessageBeanQueue": {{ <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> ... <jms-queue name="MessageBeanQueue" entries="java:/jms/queue/MessageBeanQueue"/> <connection-factory name="RemoteConnectionFactory" entries="java:/ConnectionFactory" connectors="http-connector"/> </server> </subsystem>}} > java:app resources can not be shared between ejb and appclient modules > ---------------------------------------------------------------------- > > Key: WFLY-3211 > URL: https://issues.redhat.com/browse/WFLY-3211 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.0.0.Final, 11.0.0.Final > Reporter: Jeff Mesnil > Assignee: Eduardo Martins > Priority: Major > Attachments: Sample_WildFly10.zip > > > use case: > 1 ear composed of: > 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global) > 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue) > When the ear is deployed: > 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module) > 2. the appclient module is deployed, its 2 queues are deployed > 3. the appclient main is run > When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine. > When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it > => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module. > Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors: > {noformat} > [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [ > [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu > e.queue1]", > [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app > client-test.jms.queue.queue2]" > [APPCLIENT-out] ]} > {noformat} > Steps to reproduce: > 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient > 2. build WildFly > 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules

by Wolfgang Knauf (Jira)

[ https://issues.redhat.com/browse/WFLY-3211?page=com.atlassian.jira.plugin... ] Wolfgang Knauf edited comment on WFLY-3211 at 4/22/20 2:05 PM: --------------------------------------------------------------- My original sample is still not working in WildFly 19. But: I managed to make it functioning - don't know whether my solution/workaround is correct: a) in "jboss-client.xml" of the ApplicationClient project, use the JNDI name "java:/jms/queue/MessageBeanQueue" instead of "java:app/jms/queue/MessageBeanQueue". <jboss-client ...> <jndi-name>MessageClient</jndi-name> <resource-ref> <res-ref-name>jms/MBConnectionFactory</res-ref-name>  <jndi-name>java:/ConnectionFactory</jndi-name> </resource-ref> <resource-ref> <res-ref-name>jms/MBQueueRef</res-ref-name> <jndi-name>java:/jms/queue/MessageBeanQueue</jndi-name> </resource-ref> </jboss-client> b) in "%WILDFLY_HOME%\appclient\configuration\appclient.xml", also declare the Queue and point it to "java:/jms/queue/MessageBeanQueue": <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> ... <jms-queue name="MessageBeanQueue" entries="java:/jms/queue/MessageBeanQueue"/> <connection-factory name="RemoteConnectionFactory" entries="java:/ConnectionFactory" connectors="http-connector"/> </server> </subsystem> was (Author: wolfgangknauf): My original sample is still not working in WildFly 19. But: I managed to make it functioning - don't know whether my solution/workaround is correct: a) in "jboss-client.xml" of the ApplicationClient project, use the JNDI name "java:/jms/queue/MessageBeanQueue" instead of "java:app/jms/queue/MessageBeanQueue". {{<jboss-client ...> <jndi-name>MessageClient</jndi-name> <resource-ref> <res-ref-name>jms/MBConnectionFactory</res-ref-name>  <jndi-name>java:/ConnectionFactory</jndi-name> </resource-ref> <resource-ref> <res-ref-name>jms/MBQueueRef</res-ref-name> <jndi-name>java:/jms/queue/MessageBeanQueue</jndi-name> </resource-ref> </jboss-client>}} b) in "%WILDFLY_HOME%\appclient\configuration\appclient.xml", also declare the Queue and point it to "java:/jms/queue/MessageBeanQueue": {{ <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> ... <jms-queue name="MessageBeanQueue" entries="java:/jms/queue/MessageBeanQueue"/> <connection-factory name="RemoteConnectionFactory" entries="java:/ConnectionFactory" connectors="http-connector"/> </server> </subsystem>}} > java:app resources can not be shared between ejb and appclient modules > ---------------------------------------------------------------------- > > Key: WFLY-3211 > URL: https://issues.redhat.com/browse/WFLY-3211 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.0.0.Final, 11.0.0.Final > Reporter: Jeff Mesnil > Assignee: Eduardo Martins > Priority: Major > Attachments: Sample_WildFly10.zip > > > use case: > 1 ear composed of: > 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global) > 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue) > When the ear is deployed: > 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module) > 2. the appclient module is deployed, its 2 queues are deployed > 3. the appclient main is run > When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine. > When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it > => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module. > Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors: > {noformat} > [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [ > [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu > e.queue1]", > [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app > client-test.jms.queue.queue2]" > [APPCLIENT-out] ]} > {noformat} > Steps to reproduce: > 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient > 2. build WildFly > 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13398) MicroProfile OpenAPI Quickstart README.adoc missing attributes

by Eduardo Martins (Jira)

Eduardo Martins created WFLY-13398: -------------------------------------- Summary: MicroProfile OpenAPI Quickstart README.adoc missing attributes Key: WFLY-13398 URL: https://issues.redhat.com/browse/WFLY-13398 Project: WildFly Issue Type: Enhancement Components: Quickstarts Affects Versions: 19.0.0.Final Reporter: Eduardo Martins Assignee: Eduardo Martins The MicroProfile OpenAPI quickstart has some attributes missing in its README.adoc, which leads to issues when building the root README ToC. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020