[JBoss JIRA] (WFCORE-724) CLI throws IAE on tab completion
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-724?page=com.atlassian.jira.plugin... ]
Petr Kremensky moved JBEAP-229 to WFCORE-724:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-724 (was: JBEAP-229)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 2.0.0.Alpha3
(was: EAP 7.0.0.DR2)
Component/s: CLI
(was: CLI)
Target Release: (was: EAP 7.0.0.GA)
> CLI throws IAE on tab completion
> --------------------------------
>
> Key: WFCORE-724
> URL: https://issues.jboss.org/browse/WFCORE-724
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha3
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> CLI throws IAE on tab completion.
> https://issues.jboss.org/browse/WFCORE-672 - CLI tab-completion for attribute name path syntax
> {noformat}
> [standalone@localhost:9990 /] /subsystem=jgroups/stack=udp/transport=UDP:write-attribute(name=properties.java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:136)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1373)
> at org.jboss.as.cli.impl.AttributeNamePathCompleter$AttributeNamePathCallbackHandler.getCandidates(AttributeNamePathCompleter.java:165)
> at org.jboss.as.cli.impl.AttributeNamePathCompleter.complete(AttributeNamePathCompleter.java:112)
> at org.jboss.as.cli.impl.AttributeNamePathCompleter.complete(AttributeNamePathCompleter.java:96)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:229)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:73)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:126)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:122)
> at org.jboss.aesh.console.Console.complete(Console.java:1227)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:551)
> at org.jboss.aesh.console.Console.read(Console.java:453)
> at org.jboss.aesh.console.Console.read(Console.java:347)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:198)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1327)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:272)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.modules.Module.run(Module.java:308)
> at org.jboss.modules.Main.main(Main.java:487)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFLY-4709) Invalid Last-Modified header
by Davy De Durpel (JIRA)
Davy De Durpel created WFLY-4709:
------------------------------------
Summary: Invalid Last-Modified header
Key: WFLY-4709
URL: https://issues.jboss.org/browse/WFLY-4709
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Environment: Windows Server 2008
Reporter: Davy De Durpel
Assignee: Stuart Douglas
After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header. Normally it should be in the format:
Fri, 10 Oct 2014 19:35:55 GMT
But sometimes it sends:
Fri, 10 Oct 2014 21:35:55 CEST
Or even:
Fri, 10 Oct 2014 21:35:55 CEST GMT
The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
A restart of the service fixes the issue for a few hours after which it reappears but not for all requests. We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly. No updates were done to windows, java and Wildfly that could have triggered the issue. We noticed the issue because we have a java applet running at the customer side. We use URLConnection to download some files based on the last modification date of these files. Browsers don't seem to be affected by the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFLY-4627) Issue when connecting to JBoss 7.1.1 queues installed in Linux from custom application installed in HP-UX
by Carmen Rodriguez Leon (JIRA)
[ https://issues.jboss.org/browse/WFLY-4627?page=com.atlassian.jira.plugin.... ]
Carmen Rodriguez Leon commented on WFLY-4627:
---------------------------------------------
Hello,
Any news on this issue?
Regards.
> Issue when connecting to JBoss 7.1.1 queues installed in Linux from custom application installed in HP-UX
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4627
> URL: https://issues.jboss.org/browse/WFLY-4627
> Project: WildFly
> Issue Type: Bug
> Environment: JBoss AS 7.1.1
> JDK: 1.6.0_13
> Operating System: Linux
> Reporter: Carmen Rodriguez Leon
> Assignee: Jason Greene
>
> I have a JBoss AS 7.1.1 deployed in a machine with the environment detailed above. In this JBoss I have 4 queues deployed.
> I run Jboss as follows:
> ./standalone.sh -c standalone-full.xml -b xxx.xxx.xx.xxx -bmanagement=xxx.xxx.xx.xxx &
> I have successfully connected HermesJMS from a remote machine (also using Linux) to the JBoss queues.
> However, when I try to connect to the queues from a custom application hosted in a remote machine using HP-UX, I get the following error:
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:615)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:121)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:116)
> Caused by: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:619)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:611)
> ... 6 more
> I'm quite sure that it is not a connectivity issue because if I configure a wrong username/password it says: Invalid username or password so it's connecting properly to JBoss. The problem is when connecting to the queues.
> Regarding the configuration of our custom application, it is exactly the same than the one used in HermesJMS (also the same libraries), so it should be ok as HermesJMS connects properly.
> The only difference is in the Operating System: JBoss and HermesJMS are installed in Linux while our custom application is installed in HP-UX. May this be an issue?
> Regards
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFLY-3439) Websockets not working
by Kadhem Kacem (JIRA)
[ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.... ]
Kadhem Kacem commented on WFLY-3439:
------------------------------------
Ok Tomaz i will do, thank you.
> Websockets not working
> ----------------------
>
> Key: WFLY-3439
> URL: https://issues.jboss.org/browse/WFLY-3439
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Veli Cris
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Hi,
> I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate!
> The configuration is standalone.
> [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080
> [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ...
> [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ...
> [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war")
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFLY-3439) Websockets not working
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3439:
-----------------------------------
[~kadhem] please start a new forum thread in https://community.jboss.org/en/wildfly and describe your application what is doing and how.
also adding info about your deployment jars (WEB-INF/lib) would be helpful
> Websockets not working
> ----------------------
>
> Key: WFLY-3439
> URL: https://issues.jboss.org/browse/WFLY-3439
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Veli Cris
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Hi,
> I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate!
> The configuration is standalone.
> [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080
> [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ...
> [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ...
> [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war")
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFLY-4696) OutOfMemory DirectByteBuffer XNIO
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4696?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4696:
--------------------------------------
That stack trace looks like it is from 8.1.0.Final, and a lot of the code has changed in that version. Can you post a more up to date stack trace?
> OutOfMemory DirectByteBuffer XNIO
> ---------------------------------
>
> Key: WFLY-4696
> URL: https://issues.jboss.org/browse/WFLY-4696
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Carlos Rodríguez Aguado
> Assignee: Stuart Douglas
> Priority: Blocker
>
> I get this errors constantly in my server when a web connection is interrupted from the browser for instance:
> 11:50:45,301 ERROR [stderr] (default task-339) Exception in thread "default task-339" java.nio.BufferOverflowException
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:150)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:629)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205)
> 11:50:45,301 ERROR [stderr] (default task-339) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:201)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.lang.Thread.run(Thread.java:745)
> And then, I think this errors lead to a OutOfMemory crash:
> 14:23:09,592 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:143) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> I also have found that if I perform a full GC manually the server recovers, but it can not recover by itself, by performing other types of GCs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFCORE-723) Support for -P multiple times
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-723?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-723:
----------------------------------
Assignee: James Perkins (was: Jason Greene)
it is possible it broke with migration to launcher api
> Support for -P multiple times
> -----------------------------
>
> Key: WFCORE-723
> URL: https://issues.jboss.org/browse/WFCORE-723
> Project: WildFly Core
> Issue Type: Feature Request
> Affects Versions: 1.0.0.CR5
> Reporter: John Ament
> Assignee: James Perkins
>
> In 8.2.0 and 8.1, we had the ability to invoke (in an arquilian test in my case) the startup with -P multiple times, e.g.
> {code}
> -P=../standalone/configuration/dev.properties -P=../standalone/configuration/integ.properties -P=../standalone/configuration/custom.properties
> {code}
> This doesn't seem to work in WF 9 CR1. It seems like only the last option is read.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFCORE-723) Support for -P multiple times
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-723?page=com.atlassian.jira.plugin... ]
Tomaz Cerar moved WFLY-4706 to WFCORE-723:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-723 (was: WFLY-4706)
Affects Version/s: 1.0.0.CR5
(was: 9.0.0.CR1)
> Support for -P multiple times
> -----------------------------
>
> Key: WFCORE-723
> URL: https://issues.jboss.org/browse/WFCORE-723
> Project: WildFly Core
> Issue Type: Feature Request
> Affects Versions: 1.0.0.CR5
> Reporter: John Ament
> Assignee: Jason Greene
>
> In 8.2.0 and 8.1, we had the ability to invoke (in an arquilian test in my case) the startup with -P multiple times, e.g.
> {code}
> -P=../standalone/configuration/dev.properties -P=../standalone/configuration/integ.properties -P=../standalone/configuration/custom.properties
> {code}
> This doesn't seem to work in WF 9 CR1. It seems like only the last option is read.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFLY-3088) Cannot Inject Validator using @Inject
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3088?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger resolved WFLY-3088.
-----------------------------------
Resolution: Incomplete Description
Closing due to inactivity of the reporter. Feel free to reopen with more information.
> Cannot Inject Validator using @Inject
> -------------------------------------
>
> Key: WFLY-3088
> URL: https://issues.jboss.org/browse/WFLY-3088
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Reporter: Sat B
> Assignee: Eduardo Martins
>
> I have a very simple bean and I am trying to inject the Validator using the @Inject annotation. But I am ending up getting a null when I try to use the Validator. I have the beans.xml defined to bean-discovery-mode="all". Below is the code
> --------
> import javax.inject.Inject;
> import javax.validation.ConstraintViolation;
> import javax.validation.Validation;
> import javax.validation.Validator;
> import javax.validation.ValidatorFactory;
> import javax.validation.constraints.*;
> import java.util.Map;
> import java.util.Set;
> public class SimpleCommand {
> @Inject
> private Validator validator;
>
> @Email
> private String email;
>
> public SimpleCommand(){
> }
> public SimpleCommand(Map<String, String[]> params){
> this.email = params.get("email")!=null ? params.get("email")[0] : null;
> }
> public void validate(){
> //USING VALIDATOR THAT IS INJECTED IS NULL HERE
> //USING THE BELOW METHOD WORKS
> ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
> Validator validator1 = factory.getValidator();
> Set<ConstraintViolation<SimpleCommand>> contstraintViolations = validator1.validate(this); //USING INJECTED VALIDATOR WILL THROW NULL POINTER EXCEPTION
> for (ConstraintViolation<SimpleCommand> violation : contstraintViolations){
> System.out.println(violation.getMessage());
> }
> }
> }
> --------
> Then, from a JAX-RS controller, I call this validator
> ------
> SimpleCommand cmd = new SimpleCommand(req.getParameterMap());
> cmd.validate();
> -----
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (WFLY-3669) Deltaspike deployment fails on wildfly 8.1
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3669?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger resolved WFLY-3669.
-----------------------------------
Resolution: Incomplete Description
Closing due to inactivity of the reporter. Feel free to reopen with more information.
> Deltaspike deployment fails on wildfly 8.1
> ------------------------------------------
>
> Key: WFLY-3669
> URL: https://issues.jboss.org/browse/WFLY-3669
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.1.0.Final
> Reporter: Paa Kojo Konduah Amos
> Assignee: Jozef Hartinger
>
> on addition of the Deltaspike-core dependency in my pom.xml....wildfly 8.1 fails at deployment time.
> 01:45:08,481 INFO [org.apache.deltaspike.core.util.ProjectStageProducer] (MSC service thread 1-4) Computed the following DeltaSpike ProjectStage: Production
> 01:45:12,813 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jwi.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jwi.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name dsWindowContext resolves to beans:
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()],
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()]
> at org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:134)
> at org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:130)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_65]
> ... 3 more
> 01:45:12,824 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jwi.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jwi.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jwi.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name dsWindowContext resolves to beans:
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()],
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()]"}}
> 01:45:12,919 INFO [org.jboss.as.server] (ServerService Thread Pool – 28) JBAS018559: Deployed "jwi.war" (runtime-name : "jwi.war")
> 01:45:12,928 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."jwi.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jwi.war".WeldStartService: Failed to start service
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months