Between WFLY 23 and WFLY 26 there were a lot of changes wrt security, maybe that’s what’s going on at your end. Unfortunately I am unable to help much on that are so will wait for someone else to step in.

—E


On 28 Jan 2022, at 15:49, Andrew Marlow <marlow.agents@gmail.com> wrote:

I have managed to get slightly further. I've compared our 23 standalone-whatever.xml to version 26. Version 23 has a line in the socket-binding that by mistake my 26 version didn't have: name="remoting" port="myportNumber". With 23, netstat revealed that a server does listen on that port number. I added this line to my 26 env but it made no difference. We've had this line in the config since wildfly 9. I wonder if maybe it was deprecated for a while and has now been removed? I don't see in standalone-full.xml for either 23 or 26. So how is the remoting port specified in 26 please?

On Fri, 28 Jan 2022 at 14:33, Andrew Marlow <marlow.agents@gmail.com> wrote:
Hello everyone,

I'd just like to add that I've used add-user to add an admin user and I can now see the various admin screens for wf-26. They all show the JNDI and JMS information as I would expect to see it. All the queues are there although they are empty because I cannot connect. I wonder what port the server is listening on for client connections.
I also tried changing the protocol from remote://hostname:portNumber to remote+http://hostname:portNumber but it made no difference.

On Fri, 28 Jan 2022 at 14:05, Andrew Marlow <marlow.agents@gmail.com> wrote:
Hello everyone and thank you for your quick reply Eduardo. Unfortunately I cannot send the logs or the configuration; the work I am engaged in is proprietary so I can share very little. But almost nothing has changed in our code that has been using wildfly-23 for some time. We are running wildfly standalone and I used standalone-full.xml as the template, just adding stuff for our JDBC driver and our JMS queues.

When I trapped the exception I got a stack trace that revealed it was deep in the wildfly code, starting at RemoteNamingProvider.java in the function getPeerIdentityForNaming. Tracking back into the project code it is the lookup function, which calls javx.naming.InitialContext.lookup.

I note from netstat that nothing seems to be listening on the port number I am using. Shouldn't wildfly be listening to it? Of course if it isn't for whatever reason then this might explain the client side error. But the server.log from wildfly seems to be clean.

On Fri, 28 Jan 2022 at 13:43, Eduardo Martins <emartins@redhat.com> wrote:
Hi Andrew, can you please share the logs?

—E

On 28 Jan 2022, at 11:56, Andrew Marlow <marlow.agents@gmail.com> wrote:

Hello everyone,

I am trying to move from 23 to 26 but am getting exception error WFNAM00018. My provider URL takes the form: remote://machineName:portNumber. Has this changed between 23 and 26? The port number is set via the property jboss.https.port. The line of code that blows up on is a call to context.lookup.

-- 
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s



-- 


-- 


-- 
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s