February 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-2190) Manage jgroups configuration through the console

by Heiko Braun (Created) (JIRA)

Manage jgroups configuration through the console ------------------------------------------------ Key: AS7-2190 URL: https://issues.jboss.org/browse/AS7-2190 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
4
0 / 0

[JBoss JIRA] (AS7-3864) CLI: unable to specify operation headers in generic operations

by Dominik Pospisil (JIRA)

Dominik Pospisil created AS7-3864: ------------------------------------- Summary: CLI: unable to specify operation headers in generic operations Key: AS7-3864 URL: https://issues.jboss.org/browse/AS7-3864 Project: Application Server 7 Issue Type: Bug Reporter: Dominik Pospisil It seems to me that it is not possible to specify operation headers in generic operation executions. This is required if a user choose to use low-level operation and need to specify roll-out plans, allow-resource-service-restart or other flags. Something like this should be possible: [standalone@localhost:9999 /] /subsystem=datasources/data-source=TestDS:disable(headers={"allow-resource-service-restart" => true}) Operation 'disable' does not expect any property. [standalone@localhost:9999 /] /subsystem=datasources/data-source=TestDS:disable --headers={"allow-resource-service-restart" => true}) 'disable --headers=' is not a valid operation name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
3
0 / 0

[JBoss JIRA] (AS7-2947) org.jboss.as.server.mgmt.HttpManagementService.start leads to NPE

by Richard Opalka (Created) (JIRA)

org.jboss.as.server.mgmt.HttpManagementService.start leads to NPE ----------------------------------------------------------------- Key: AS7-2947 URL: https://issues.jboss.org/browse/AS7-2947 Project: Application Server 7 Issue Type: Bug Components: Server Reporter: Richard Opalka Assignee: Brian Stansberry Fix For: 7.1.0.CR1 08:53:58,375 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:189) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29] Caused by: java.lang.NullPointerException at sun.nio.ch.Util.atBugLevel(Util.java:448) [:1.6.0_29] at sun.nio.ch.SelectorImpl.<init>(SelectorImpl.java:40) [:1.6.0_29] at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:47) [:1.6.0_29] at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) [:1.6.0_29] at java.nio.channels.Selector.open(Selector.java:209) [:1.6.0_29] at org.jboss.sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:147) at org.jboss.sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:54) at org.jboss.sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:38) at org.jboss.com.sun.net.httpserver.HttpServer.create(HttpServer.java:147) at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:105) at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:154) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:] ... 5 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

7
8
0 / 0

[JBoss JIRA] (AS7-3768) Unexpected failure for WS-Addressing tests

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created AS7-3768: -------------------------------------- Summary: Unexpected failure for WS-Addressing tests Key: AS7-3768 URL: https://issues.jboss.org/browse/AS7-3768 Project: Application Server 7 Issue Type: Bug Components: Web Services Affects Versions: 7.1.0.CR1b Reporter: Rostislav Svoboda Assignee: Richard Opalka Fix For: 7.1.1.Final I'm developing WS-Addressing tests for AS7 TS and I hit interesting issue. It's about org.jboss.as.test.integration.ws.wsa.TestNoAddressingTestCase -- usingWSDLFromDeployedEndpoint test, when I run just TestNoAddressingTestCase everything if fine, but when I run all Test*AddressingTestCase I have failure. Just TestNoAddressingTestCase (./integration-tests.sh -e -Dts.basic clean test -Dtest=TestNoAddressingTestCase) Details for usingWSDLFromDeployedEndpoint (@HandlerChain used to dump message) {code} ----------- Incoming message: ----------- <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header/><soap:Body><ns2:sayHello xmlns:ns2="http://www.jboss.org/jbossws/ws-extensions/wsaddressing"><arg0>no-addressing</arg0></ns2:sayHello></soap:Body></soap:Envelope> ----------- Outgoing message: ----------- <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:sayHelloResponse xmlns:ns2="http://www.jboss.org/jbossws/ws-extensions/wsaddressing"><return>Hello no-addressing!</return></ns2:sayHelloResponse></soap:Body></soap:Envelope> ----------- {code} All Test*AddressingTestCase (./integration-tests.sh -Dts.basic clean test -Dtest=Test*AddressingTestCase) Details for usingWSDLFromDeployedEndpoint: {code} ----------- Incoming message: ----------- <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><Action xmlns="http://www.w3.org/2005/08/addressing">http://www.jboss.org/jbossws/ws-extensions/wsaddressing/ServiceIface/sayH...</Action><MessageID xmlns="http://www.w3.org/2005/08addressing">urn:uuide4f20e7-e3d3-4e04-a4fc-c1830ca2c9e8</MessageID><To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/jaxws-wsa/AddressingService</To><ReplyTo xmlns="http://www.w3.org/2005/08/addressing"><Address>http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo></soap:Header><soap:Body><ns2:sayHello xmlns:ns2="http://www.jboss.org/jbossws/ws-extensions/wsaddressing"><arg0>no-addressing</arg0></ns2:sayHello></soap:Body></soap:Envelope> ----------- Outgoing message: ----------- <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:sayHelloResponse xmlns:ns2="http://www.jboss.org/jbossws/ws-extensions/wsaddressing"><return>Hello no-addressing!</return></ns2:sayHelloResponse></soap:Body></soap:Envelope> ----------- {code} Details: - How could addressing appear in incoming message? - I dump generated WSDL file and it contains no addressing namespaces and elements [1] - I think WS lookup in usingWSDLFromDeployedEndpoint method is just standard - Is there any client side caching? TestNoAddressingTestCase must be influenced by other tests. Branch with WS-Addressing tests: https://github.com/rsvoboda/jboss-as/tree/ws-addressing Commit: https://github.com/rsvoboda/jboss-as/commit/c345ea0ebccb50bdbada5cd105d2f... [1] WSDL dump: https://github.com/rsvoboda/jboss-as/commit/c345ea0ebccb50bdbada5cd105d2f... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
8
0 / 0

[JBoss JIRA] (AS7-3814) CommandContext.buildRequest(line) throws OperationFormatException for wrong reason

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created AS7-3814: -------------------------------------- Summary: CommandContext.buildRequest(line) throws OperationFormatException for wrong reason Key: AS7-3814 URL: https://issues.jboss.org/browse/AS7-3814 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.1.0.Final Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.1.1.Final Operation requests aren't affected. The method translates commands to operation requests. Of course, the command handler is required to implement OperationCommand interface. But the if condition is wrong, i.e. instead of throwing an exception in case the handler doesn't implement the interface, it throws an exception if the handler does implement the interface. This is a new and not yet publicly advertised functionality, so nobody will suffer from this bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
1
0 / 0

[JBoss JIRA] (AS7-3849) Operation with outcome 'failure' don't set the exit code to indicate failure

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created AS7-3849: -------------------------------------- Summary: Operation with outcome 'failure' don't set the exit code to indicate failure Key: AS7-3849 URL: https://issues.jboss.org/browse/AS7-3849 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.1.0.Final Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.1.1.Final While commands when failed set the cli process exit code to a non-zero value, the operation requests that failed (w/o throwing an exception) will not set the exit code to indicate the failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
1
0 / 0

[JBoss JIRA] (AS7-3815) add a convenience CommandContext.connectController() method w/o arguments

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created AS7-3815: -------------------------------------- Summary: add a convenience CommandContext.connectController() method w/o arguments Key: AS7-3815 URL: https://issues.jboss.org/browse/AS7-3815 Project: Application Server 7 Issue Type: Task Components: CLI Affects Versions: 7.1.0.Final Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.1.1.Final Now, starting to expose the CLI API to Java applications, not having this method seems unnatural. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
1
0 / 0

[JBoss JIRA] (AS7-3859) InjectionTarget.postConstruct is not called for EJB's

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-3859: ----------------------------------- Summary: InjectionTarget.postConstruct is not called for EJB's Key: AS7-3859 URL: https://issues.jboss.org/browse/AS7-3859 Project: Application Server 7 Issue Type: Bug Components: CDI / Weld Affects Versions: 7.1.0.Final Reporter: Stuart Douglas Assignee: Stuart Douglas Fix For: 7.1.1.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] (AS7-3847) Non-standard format of IPv6 address(-es) in LOG files

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-3847?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-3847: ----------------------------------- For the JBossWeb part, Richard seems to have a filed a separate JIRA here https://issues.jboss.org/browse/AS7-3851 which is assigned to Remy. > Non-standard format of IPv6 address(-es) in LOG files > ----------------------------------------------------- > > Key: AS7-3847 > URL: https://issues.jboss.org/browse/AS7-3847 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.0.Final > Reporter: Pavel Janousek > > There are several places where some IPv6 address related info is logged. The format of a such info is formally correct, but used format is against [RFC-5952|http://tools.ietf.org/html/rfc5952] - this RFC has status of +Proposed standard+ and I don't know any software product which doesn't follow it (at least by-default). > I think in enterprise product we should not violate this RFC. > I'm mentioning about LOG messages like: > {code} > 15:14:15,985 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on /0:0:0:0:0:0:0:1%1:9999 > > 15:14:15,990 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on localhost6.localdomain6/0:0:0:0:0:0:0:1%1:4447 > {code} > In both lines IPv6 address should be stretched to "::1" string. > More "funny" and obfuscated version of the same LOG content is LOG line like this: > {code} > 15:14:14,363 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http--0%3A0%3A0%3A0%3A0%3A0%3A0%3A1%251-8080 > {code} > But both version of the issue is almost unreadable by human. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-3723) Add support to weld for a non-standard mode that only scans for classes with annotations

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-3723: ----------------------------------- Summary: Add support to weld for a non-standard mode that only scans for classes with annotations Key: AS7-3723 URL: https://issues.jboss.org/browse/AS7-3723 Project: Application Server 7 Issue Type: Feature Request Components: CDI / Weld Reporter: Stuart Douglas Assignee: Stuart Douglas Fix For: 7.1.1.Final On 12 Feb 2012, at 04:01, Stuart Douglas wrote: I have actually toyed with the idea of including this as an AS7 extension. I was thinking something like this in the beans.xml file: <as7:only-scan-annotated enabled="true"> <as7:annotation>org.jboss.seam.ExtensionManaged</as7:annotation> <as7:annotation>com.acme.SomeOtherAnnotation</as7:annotation> </as7:only:scan-annotation> This setting would only be applied to the bean archive that has it in its beans.xml (so 3rd party libraries would function properly), and the set of annotations to scan would be merged and applied to all bean archives that use this setting (so if deltaspike defines ExtensionManaged the use would also not have to add that the list of annotations to scan, it would be picked up from the beans.xml file). This is actually relatively easy to implement, and I could probably get it into AS 7.1.1 . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
1
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 February 2012