[JBoss JIRA] (WFLY-4476) Unable to configure cxf socket timeout in wildfly_8.2.Final
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4476?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-4476:
---------------------------------------
This appears as a regression likely because in the past the JBossWS-CXF implementation of javax.xml.soap.SOAPConnection was not automatically resolved.
Anyway, the HTTPConduit is going to be configurable when the JBWS-3901 changes will be included in WildFly, that is after next Beta or CR release of JBossWS 5.
> Unable to configure cxf socket timeout in wildfly_8.2.Final
> -----------------------------------------------------------
>
> Key: WFLY-4476
> URL: https://issues.jboss.org/browse/WFLY-4476
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Beta2
> Environment: Java8, Ubuntu Linux Desktop
> Reporter: George Mathias
> Assignee: Alessio Soldano
> Priority: Critical
> Labels: cxf, saaj, undertow
> Fix For: 8.2.0.Final
>
>
> Socket times out after 60 seconds when calling SAAJ webservices from a wildfly servlet. Wildfly uses CXF internally and CXF HTTP Conduit times out in 60 seconds by default. Cannot find a way to configure this timeout (Receive timeout) in standalone.xml file.
> Following line throws socket read time out exception
> responseMsg = soapConn.call(soapMessage, wsdlLoc);
> Java Call is:
> private static String callWebService(String serviceName,
> String userName,
> org.w3c.dom.Document soapRequestDoc,
> String serviceType,
> String endPointAddress,
> String remoteClientAddress,
> String remoteClientHostname,
> String remoteClientUser,
> String clientApplicationId)
> throws SOAPException,java.io.IOException,CommunicationException
> {
> SOAPConnection soapConn = null;
> String wsdlLoc=endPointAddress;
> String resp = "";
> MessageFactory msgFactory;
> SOAPFactory soapFactory;
> SOAPMessage soapMessage;
> SOAPConnectionFactory soapConnFactory;
> SOAPMessage responseMsg;
>
> try
> {
> if (wsdlLoc == null)
> throw new SOAPException("Error: Endpoint address is NULL.");
> msgFactory = MessageFactory.newInstance();
> soapFactory = SOAPFactory.newInstance();
> soapMessage = msgFactory.createMessage();
>
> //Add headers
> addSoapHeaders(soapMessage,soapFactory,
> serviceType,userName,remoteClientAddress,remoteClientHostname,
> remoteClientUser,
> clientApplicationId);
>
> //Add Body addBody(soapMessage,soapFactory,soapRequestDoc,serviceName);
>
> logger.debug(soapMessage);
> soapConnFactory = SOAPConnectionFactory.newInstance();
> soapConn = soapConnFactory.createConnection();
> logger.debug("Invoking service ["+serviceName+
> "] on WSDL ["+
> wsdlLoc+"] ...");
>
> responseMsg = soapConn.call(soapMessage, wsdlLoc);
> logger.debug("Call completed ["+serviceName+
> "] on WSDL ["+
> wsdlLoc+"]!");
> resp = processResponseMessageStringParser(responseMsg);
> logger.debug("Return Document [" + resp + "]");
> }
> catch (SOAPException e)
> {
> logger.error(e);
> throw new CommunicationException(errorBuffer.toString());
> }
> finally
> {
> try
> {
> if (soapConn != null)
> soapConn.close();
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> }
>
> return resp;
> }
> Exception thrown is:
> javax.xml.soap.SOAPException: JBWS024004: SOAP message could not be sent
> at org.jboss.wsf.stack.cxf.saaj.SOAPConnectionImpl.call(SOAPConnectionImpl.java:124)
> at com.qwest.servlet.Client.callWebService(Client.java:225)
> at com.qwest.servlet.Client.call(Client.java:138)
> at com.qwest.servlet.TestServlet.doGet(TestServlet.java:73)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:278)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:255)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.SocketTimeoutException: SocketTimeoutException invoking http://localhost:8080/TestWS/v2.0.0/TestServer?wsdl: Read timed out
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1347)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1331)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:632)
> at org.jboss.wsf.stack.cxf.saaj.SOAPConnectionImpl.call(SOAPConnectionImpl.java:120)
> ... 31 more
> Caused by: java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:150)
> at java.net.SocketInputStream.read(SocketInputStream.java:121)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:703)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
> at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.getResponseCode(URLConnectionHTTPConduit.java:266)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1545)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1515)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1318)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-2542) Groovy class implementing javax.jms.MessageListener error
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2542?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil closed WFLY-2542.
-----------------------------
Fix Version/s: 8.0.0.CR1
Resolution: Done
> Groovy class implementing javax.jms.MessageListener error
> ---------------------------------------------------------
>
> Key: WFLY-2542
> URL: https://issues.jboss.org/browse/WFLY-2542
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Environment: Mac OS 10.9, jdk 7u45.
> Reporter: Filipe Ferraz
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1
>
> Attachments: HelloMDB.zip
>
>
> A Groovy class implementing the MessageListener interface (Message Drive Beans) returns an error at the deployment.
> org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014194: EJB 3.1 FR 5.4.2 MessageDrivenBean com.filipeferraz.service.MDBGroovyService does not implement 1 interface nor specifies message listener interface
> I have tested with a Java version of the class and works fine, the problem appers only when using a groovy class to implements the MessageListener interface.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-2608) MDB not receiving messages from JMS queue.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2608?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-2608.
-------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
Fixed in HornetQ since 2.4.2.Final
> MDB not receiving messages from JMS queue.
> ------------------------------------------
>
> Key: WFLY-2608
> URL: https://issues.jboss.org/browse/WFLY-2608
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Reporter: Corey Puffalt
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Alpha1
>
>
> We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB. The forum thread referenced below has more background information but basically at some point we see the following in our server logs:
> {code}
> 00:50:28,915 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
> 00:50:29,208 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> 00:50:29,235 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> [the above two messages are repeated a number of times in rapid succession...and then finally we get...]
> 00:50:30,187 WARN [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected]
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:29,240 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected]
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:38,633 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> 00:50:38,636 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> {code}
> After this our MDB never receives any further messages until a server restart. HornetQ should be recovering from this situation (whatever the cause).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-621) Support legacy slaves when invoking wildcard reads in a domain
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-621:
---------------------------------------
Summary: Support legacy slaves when invoking wildcard reads in a domain
Key: WFCORE-621
URL: https://issues.jboss.org/browse/WFCORE-621
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Priority: Critical
Fix For: 2.0.0.Beta1
This is a follow-on to WFCORE-282.
The WFCORE-282 will not work for requests with address patterns /host=*/server=* or /host=somename/server=* if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.)
In particular, it won't work with slaves running EAP 6.x.
The problem is with either of those address patterns the DC will send a request addressed to /host=somename/server=* to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them.
Potentially this could be fixed by having the DC detect these patterns and not call /host=somename/server=*, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plu... ]
James Perkins commented on JBLOGGING-111:
-----------------------------------------
Yeah it's in 3.2.0.Final. Fixed and thanks for pointing it out.
> LoggerProvider configured with new ServiceLoader crash
> ------------------------------------------------------
>
> Key: JBLOGGING-111
> URL: https://issues.jboss.org/browse/JBLOGGING-111
> Project: JBoss Logging
> Issue Type: Bug
> Affects Versions: 3.2.0.Beta1
> Environment: Weblogic 10.3.2.0
> Configured in ejb jar, deployed by an ear file
> Reporter: Frederic Allard
> Assignee: James Perkins
> Fix For: 3.2.0.Final
>
>
> There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging.
> org.jboss.logging.LoggerProviders snippet :
> {code}
> // Next try for a service provider
> try {
> final ServiceLoader<LoggerProvider> loader = ServiceLoader.load(LoggerProvider.class, cl);
> if (loader.iterator().hasNext()) {
> return loader.iterator().next();
> }
> } catch (Throwable ignore) {
> // TODO consider printing the stack trace as it should only happen once
> }
> {code}
> When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider.
> {code}
> java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers ""
> at java.util.ServiceLoader.fail(ServiceLoader.java:207)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
> at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70)
> at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32)
> at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:29)
> at org.jboss.logging.Logger.getLogger(Logger.java:2177)
> at org.jboss.logging.Logger$1.run(Logger.java:2277)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241)
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228)
> at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:176)
> ...
> {code}
> This is caused by the fact that all JBoss providers are not public classes and are instead package classes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-601) Boot sometimes fails on restart when deployments are present in the deployments directory and the deployment scanner is in use
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-601?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-601:
------------------------------------------
Leaving Stuart as assigned since I can't reproduce it locally.
> Boot sometimes fails on restart when deployments are present in the deployments directory and the deployment scanner is in use
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-601
> URL: https://issues.jboss.org/browse/WFCORE-601
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> I observed this today, looks to be some kind of race in the deployment scanner on boot
> {code}
> 21:52:08,618 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final
> 21:52:10,370 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final
> 21:52:10,440 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting
> 21:52:11,390 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 20) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
> 21:52:11,409 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment mysql-ds.xml
> 21:52:11,413 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment wildfly-ee7.war
> 21:52:11,488 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/48/032d14f289775249a004205c059588ab0f44d4/content
> 21:52:11,504 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/c6/7babde4791697ddc6509fbd43ba1ec25952d47/content
> 21:52:11,506 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "wildfly-ee7.war")]) - failure description: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"wildfly-ee7.war\")]"
> 21:52:11,509 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations"
> 21:52:11,512 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations\""
> 21:52:11,514 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 21:52:11,514 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-416) Inconsistent tab completion behaviour between commands and arguments
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-416?page=com.atlassian.jira.plugin... ]
Jeff Mesnil closed WFCORE-416.
------------------------------
Resolution: Won't Fix
> Inconsistent tab completion behaviour between commands and arguments
> --------------------------------------------------------------------
>
> Key: WFCORE-416
> URL: https://issues.jboss.org/browse/WFCORE-416
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
>
> When tab is used for completion, the behavior changes when there is only 1 remaining candidate.
> For commands, when the completion leads to a single candidate, a whitespace is appended and we can proceed to the arguments
> For arguments using a TabCompleter, when the completion leads to a single candidate, no whitespace is appended and we have to type it to be able to proceed to the next argument
>
> Example:
> * deployment-over<TAB>
> => will complete to deployment-overlay<WHITESPACE><CURSOR> (a whitespace is appended to the single candidate)
> * deployment-overlay a<TAB>
> => will complete to deployment-overlay add<CURSOR> (no whitespace appended even though add is the only candidate matched)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months