[JBoss JIRA] (JBADMCON-174) Add feature in management console to define JNDI bindings from management console
by Abhijit Humbe (JIRA)
Abhijit Humbe created JBADMCON-174:
--------------------------------------
Summary: Add feature in management console to define JNDI bindings from management console
Key: JBADMCON-174
URL: https://issues.jboss.org/browse/JBADMCON-174
Project: JBoss Admin Console
Issue Type: Feature Request
Components: General Console
Affects Versions: 1.0 alpha, 1.1 alpha
Reporter: Abhijit Humbe
. Proposed title of this feature request
Grant access permission for sub packages to role 'package.admin'
2. Who is the customer behind the request?
Account:Biomerieux (acct #643034)
TAM customer: No
SRM customer: No
Strategic: No
3. What is the nature and description of the request?
Customer want to define specific JNDI bindings from management console.
Through the management interface, the Profile ==> Container ==> Naming does not show up.
4. Why does the customer need this? (List the business requirements here)
Customer dont want to use CLI command for this,running CLI command remotely means there is a component deployed on remote machine.
There are several dependencies on this like Java being the biggest one, network...etc
customer want to perform all task from admin console only.
5. How would the customer like to achieve this? (List the functional requirements here)
Add "Naming" field(like EJB 3, EE,..etc) under "Profile ==> Container" in management console to specify JNDI bindings.
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
TODO
9. Is the sales team involved in this request and do they have any additional input?
10. List any affected packages or components.
JBoss Admin console
11. Would the customer be able to assist in testing this functionality if implemented?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2446) invalid value for backup-group-name when it is undefined
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2446?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-2446:
------------------------------
Summary: invalid value for backup-group-name when it is undefined (was: invalid value for backup-group-name)
> invalid value for backup-group-name when it is undefined
> --------------------------------------------------------
>
> Key: WFLY-2446
> URL: https://issues.jboss.org/browse/WFLY-2446
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1
>
>
> In the messaging configuration, the backup-group-node modelNode is passed directly to the HornetQ configuration without checking whether it is defined.
> If it is not undefined, the hornetq configuration will use the "undefined" string as the backup group name instead of returning a null value
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2446) invalid value for backup-group-name
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-2446:
---------------------------------
Summary: invalid value for backup-group-name
Key: WFLY-2446
URL: https://issues.jboss.org/browse/WFLY-2446
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JMS
Affects Versions: 8.0.0.Beta1
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 8.0.0.CR1
In the messaging configuration, the backup-group-node modelNode is passed directly to the HornetQ configuration without checking whether it is defined.
If it is not undefined, the hornetq configuration will use the "undefined" string as the backup group name instead of returning a null value
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2305) add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2305:
-----------------------------------------------
Darran Lofthouse <darran.lofthouse(a)redhat.com> made a comment on [bug 1019264|https://bugzilla.redhat.com/show_bug.cgi?id=1019264]
Please DO NOT document --silent=true as a valid option.
The only reason for adding support for this option is users are not reading the current help text showing the valid options and are then getting caught out when they use an invalid form of this option - for that reason we are unofficially accepting it.
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2305
> URL: https://issues.jboss.org/browse/WFLY-2305
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Affects Versions: 8.0.0.Beta1
> Environment: WildFly snapshot of master 15-oct-2013
> Reporter: Tom Fonteyne
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-1533:
------------------------------------
We cannot get rid of SessionHolder thread local because we need to work around an incompatibility problem with some Servlet containers - see also WFLY-175. We also can't reattach the session-related contexts because we're not able to reassociate the request with a new session - i.e. request.getSession(true) currently doesn't return a new/valid session (and the Servlet spec is quite vague in this area). So the only thing we can do is to try to make a proper cleanup as much as possible and possibly log some warning message (and the full stack in debug level).
> UT015005: Error invoking method requestDestroyed on listener class
> -------------------------------------------------------------------
>
> Key: WFLY-1533
> URL: https://issues.jboss.org/browse/WFLY-1533
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
> Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip
>
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2445) Upgrade mod_cluster to 1.3.0.Alpha2
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-2445:
------------------------------------
Summary: Upgrade mod_cluster to 1.3.0.Alpha2
Key: WFLY-2445
URL: https://issues.jboss.org/browse/WFLY-2445
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Beta1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Priority: Blocker
Fix For: 8.0.0.CR1
See MODCLUSTER-367
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months