[JBoss JIRA] (WFLY-8607) Application client ignores remote host address in ejb-client-properties file passed to it in argument
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8607?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-10448 to WFLY-8607:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8607 (was: JBEAP-10448)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Application Client
EJB
Security
(was: Application Client)
(was: EJB)
(was: Security)
Affects Version/s: (was: 7.1.0.DR16)
> Application client ignores remote host address in ejb-client-properties file passed to it in argument
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-8607
> URL: https://issues.jboss.org/browse/WFLY-8607
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, EJB, Security
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Blocker
>
> Application client provides an option to define client properties through {{--ejb-client-properties=<url>}} command line argument. When trying to connect to remote server with its address defined by file from the argument, the {{remote.connection.default.host}} property gets ignored with the following error being produced in the application client:
> {code:title=$\{JBOSS_HOME\}/bin/appclient.sh --ejb-client-properties=ejb-client.properties ear/target/app-client.ear#simpleClient.jar Hello from command line}13:07:12,287 ERROR [org.jboss.as.appclient] (Thread-45) WFLYAC0002: InvocationTargetException running app client main: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_121]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
> at org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:109)
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
> Caused by: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "app-client/ejb/StatelessSessionBean", view is interface org.jboss.as.quickstarts.appclient.server.ejb.StatelessSession, affinity is None"
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:716) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:698) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:96) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> at com.sun.proxy.$Proxy12.getGreeting(Unknown Source)
> at org.jboss.as.quickstarts.appclient.acc.client.Main.main(Main.java:59) [simpleClient.jar:7.1.0.Beta]
> ... 6 more
> Suppressed: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) [rt.jar:1.8.0_121]
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) [rt.jar:1.8.0_121]
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:323)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:569)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:465)
> at org.jboss.remoting3.FutureConnection.getConnection(FutureConnection.java:117)
> at org.jboss.remoting3.FutureConnection.init(FutureConnection.java:77)
> at org.jboss.remoting3.FutureConnection.get(FutureConnection.java:152)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:407)
> at org.jboss.remoting3.EndpointImpl.getConnection(EndpointImpl.java:341)
> at org.jboss.remoting3.UncloseableEndpoint.getConnection(UncloseableEndpoint.java:55)
> at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:135)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.lambda$discover$0(RemotingEJBDiscoveryProvider.java:101) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_121]
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.discover(RemotingEJBDiscoveryProvider.java:101) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> at org.wildfly.discovery.Discovery.discover(Discovery.java:94)
> at org.jboss.ejb.client.EJBClientContext.discover(EJBClientContext.java:440) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:711) [jboss-ejb-client-4.0.0.Beta24-redhat-1.jar:4.0.0.Beta24-redhat-1]
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2475) Changing Elytron default-authentication-context ends in reload-required state
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2475?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2475:
----------------------------------------
Fix Version/s: 3.0.0.Beta16
Assignee: Tomas Hofman (was: Darran Lofthouse)
Resolution: Done
> Changing Elytron default-authentication-context ends in reload-required state
> -----------------------------------------------------------------------------
>
> Key: WFCORE-2475
> URL: https://issues.jboss.org/browse/WFCORE-2475
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Tomas Hofman
> Fix For: 3.0.0.Beta16
>
>
> If I try to change Elytron default-authentication-context server ends in reload-required state.
> {code}
> /subsystem=elytron/authentication-context=auth-context:add()
> /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model
> {code}
> /subsystem=elytron:read-resource-description(recursive=false)
> {
> ...
> "default-authentication-context" => {
> "type" => STRING,
> "description" => "The default authentication context to be associated with all deployments.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.authentication-context",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> ...
> }
> {code}
> According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary
> no-services – Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present.
> [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2697) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
by Ken Wills (JIRA)
Ken Wills created WFCORE-2697:
---------------------------------
Summary: Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
Key: WFCORE-2697
URL: https://issues.jboss.org/browse/WFCORE-2697
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Ken Wills
Assignee: Ken Wills
Fix For: 3.0.0.Beta16
Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.)
But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years