[JBoss JIRA] (JGRP-1870) Convert manual and tutorial to Asciidoc
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1870?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1870:
--------------------------------
Re #2: according to GitHub support, _GitHub Pages_ doesn't currently support AsciiDoc (only Markdown), whereas GitHub itself does. Resolving the issue and creating a new issue when GitHub Pages supports AsciiDoc.
> Convert manual and tutorial to Asciidoc
> ---------------------------------------
>
> Key: JGRP-1870
> URL: https://issues.jboss.org/browse/JGRP-1870
> Project: JGroups
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> # Convert the Docbook based documentation (manual & tutorial) to Asciidoc
> # Move the documentation to github.io: advantage would be to make changing docs simpler; e.g. anyone with permission would be able to make a change in the doc online (directly on github.io) or via PR. OPTIONAL and TBD
> # Move the web page to github.io (optional, later)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1870) Convert manual and tutorial to Asciidoc
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1870?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1870:
---------------------------
Fix Version/s: 3.5
(was: 3.6)
> Convert manual and tutorial to Asciidoc
> ---------------------------------------
>
> Key: JGRP-1870
> URL: https://issues.jboss.org/browse/JGRP-1870
> Project: JGroups
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> # Convert the Docbook based documentation (manual & tutorial) to Asciidoc
> # Move the documentation to github.io: advantage would be to make changing docs simpler; e.g. anyone with permission would be able to make a change in the doc online (directly on github.io) or via PR. OPTIONAL and TBD
> # Move the web page to github.io (optional, later)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.... ]
Emmanuel Hugonnet moved WFLY-2738 to WFCORE-57:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-57 (was: WFLY-2738)
Issue Type: Enhancement (was: Bug)
Affects Version/s: 1.0.0.Alpha4
(was: 8.0.0.CR1)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: (was: 9.0.0.CR1)
> Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
> --------------------------------------------------------------------------------
>
> Key: WFCORE-57
> URL: https://issues.jboss.org/browse/WFCORE-57
> Project: WildFly Core
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha4
> Reporter: Harald Pehl
> Assignee: Emmanuel Hugonnet
> Priority: Minor
>
> When executing
> {code}
> /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
> {code}
> the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
> {code}
> ...
> "acl" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> "model-description" => {"classic" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> ...
> "operations" => undefined,
> "children" => {
> "acl-module" => {
> "description" => "ACL module",
> "model-description" => {"*" => {
> "description" => "List of authentication modules",
> ...
> "operations" => undefined,
> "children" => {}
> }}
> },
> "login-module" => {
> "description" => "Login module",
> "model-description" => {"*" => undefined}
> }
> }
> }}
> },
> ...
> {code}
> However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3742) DeliveryActive not documented
by Tom Ross (JIRA)
Tom Ross created WFLY-3742:
------------------------------
Summary: DeliveryActive not documented
Key: WFLY-3742
URL: https://issues.jboss.org/browse/WFLY-3742
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation
Environment: JBoss EAP 6.2
Reporter: Tom Ross
Assignee: Tom Wells
Please document fix for WFLY0878
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3529) UT000010: Session not found
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3529:
-----------------------------------
Try to reproduce it on WildFly nightly builds https://community.jboss.org/thread/224262 to see if problem still persists
> UT000010: Session not found
> ----------------------------
>
> Key: WFLY-3529
> URL: https://issues.jboss.org/browse/WFLY-3529
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Environment: Wildfly 8.1.0.Final ,
> Reporter: Youssef BIKHCHICHE
> Assignee: Stuart Douglas
>
> After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has been fixed in the previous release of wildfly.
> ERREOR code :
> 2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121)
> at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144)
> at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86)
> at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402)
> ======================================================
> this issue happens after a http session invalidate action and it' not a regular problems.
> Best regards,
> Youssef
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3741) Setting some locales causes missing buttons on console and throws errors.
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3741?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma updated WFLY-3741:
--------------------------------------
Summary: Setting some locales causes missing buttons on console and throws errors. (was: setting some locales causes wildfly console to throw errors and show some missing buttons.)
> Setting some locales causes missing buttons on console and throws errors.
> -------------------------------------------------------------------------
>
> Key: WFLY-3741
> URL: https://issues.jboss.org/browse/WFLY-3741
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Localization, Web Console
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Manuel Ospina
> Attachments: mssing_add_remove_disable_Buttons.png
>
>
> - When WildFly 9 Alpha1 is started with the following system properties in the "standalone.conf" then the admin console behaves abnormally and shows some missing buttons in the console. See attached screenshot "mssing_add_remove_disable_Buttons.png".
> {code}
> JAVA_OPTS="$JAVA_OPTS -Duser.country=TR -Duser.language=tr"
> {code}
> - Also it throws following Error while accessing the console URL like [1]
> [1] http://localhost:9990/console/App.html#datasources
> {code}
> 10:39:39,223 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-8) WFLYCTL0013: Operation ("check-resource-access") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "*"),
> ("connection-properties" => "*")
> ]): java.lang.IllegalArgumentException: No enum constant org.jboss.as.controller.registry.AttributeAccess.Storage.CONFİGURATİON
> at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.registry.AttributeAccess$Storage.valueOf(AttributeAccess.java:91) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:431) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:603) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:481) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1060) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:296) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:165) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:179) [wildfly-domain-http-interface-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72) [wildfly-domain-http-interface-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68) [wildfly-domain-http-interface-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68) [wildfly-domain-http-interface-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63) [wildfly-domain-http-interface-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:50) [undertow-core-1.1.0.Beta5.jar:1.1.0.Beta5]
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:83) [wildfly-domain-http-interface-1.0.0.Alpha3.jar:1.0.0.Alpha3]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.1.0.Beta5.jar:1.1.0.Beta5]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta5.jar:1.1.0.Beta5]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta5.jar:1.1.0.Beta5]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-1119:
---------------------------------
Assignee: Jeff Mesnil
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMS
> Reporter: Clebert Suconic
> Assignee: Jeff Mesnil
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months