[JBoss JIRA] (WFCORE-2671) CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFCORE-2671:
------------------------------------
Summary: CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
Key: WFCORE-2671
URL: https://issues.jboss.org/browse/WFCORE-2671
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
When keystore (or cerficate in keystore) is changed during server runtime then CLI opertation {{load}} can be used for {{/subsystem=elytron/key-store=...}} to re-reading this keystore in server. However after calling this operation server still works with original keystore/certificate. Then CLI reads current keystore correctly, but in case when ssl-context which uses that key-store is used then original keystore is still used by server. Reload of server is required to correctly re-read the new keystore. See Steps to Reproduce for more details.
We request blocker flag since this issue blocks RFE EAP7-455.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Nick . (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
Nick . edited comment on WFCORE-482 at 4/12/17 11:30 PM:
---------------------------------------------------------
[~jamezp] Its way too old issue now, to answer your question what usually a EAP user required, a log4j2 module and a log4j2 supportive logging-subsystem. No developers bother to create an old style log4j.xml if logging-subsystem is configurable wrt log4j2.
So according to me there is no need to support user specific log4j2 configuration via their xml or properties file, but give enough flexibility in the log4j2 logging subsystem.
was (Author: nick.sree):
[~jamezp] Its way too old issue now, to answer your question what usually a EAP user required, a log4j2 module and a log4j2 supportive logging-subsystem. No developers bother to create an old style log4j.xml if logging-subsystem is configurable wrt log4j2.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Nick . (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
Nick . edited comment on WFCORE-482 at 4/12/17 11:20 PM:
---------------------------------------------------------
[~jamezp] Its way too old issue now, to answer your question what usually a EAP user required, a log4j2 module and a log4j2 supportive logging-subsystem. No developers bother to create an old style log4j.xml if logging-subsystem is configurable wrt log4j2.
was (Author: nick.sree):
[~jamezp] Its way too old issue now, but to answer your question what usually as an EAP user required is a log4j2 module and a log4j2 supportive logging-subsystem, no developers bother to create an old style create log4j.xml if logging-subsystem is configurable wrt log4j2.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Nick . (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
Nick . commented on WFCORE-482:
-------------------------------
[~jamezp] Its way too old issue now, but to answer your question what usually as an EAP user required is a log4j2 module and a log4j2 supportive logging-subsystem, no developers bother to create an old style create log4j.xml if logging-subsystem is configurable wrt log4j2.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (LOGMGR-148) Support suppressed exceptions in log formatting
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-148?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated LOGMGR-148:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1441890
Bugzilla Update: Perform
> Support suppressed exceptions in log formatting
> -----------------------------------------------
>
> Key: LOGMGR-148
> URL: https://issues.jboss.org/browse/LOGMGR-148
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 1.5.7.Final
>
>
> In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by.
> This JIRA was created to track a back port of the JDK 7 enhancement to support suppressed exceptions to the 1.5.x branch which requires JDK 6. This will introduce a new requirement that the 1.5 branch will require JDK 7 to compile, but will still work on JDK 6.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7192) 'name' attribute missing in XSD while required by web subsystem parser
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7192?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7192:
-----------------------------------------------
Michael Cada <mcada(a)redhat.com> changed the Status of [bug 1365939|https://bugzilla.redhat.com/show_bug.cgi?id=1365939] from ON_QA to VERIFIED
> 'name' attribute missing in XSD while required by web subsystem parser
> ----------------------------------------------------------------------
>
> Key: WFLY-7192
> URL: https://issues.jboss.org/browse/WFLY-7192
> Project: WildFly
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Labels: downstream_dependency
> Fix For: 11.0.0.Alpha1
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal]
> While configuring the global valve using the following article :
> https://access.redhat.com/solutions/379813
> It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml".
> So "name" attribute is mandatory to configure this valve.
> but it is not mentioned in the schema of valve as shown below :
> {code:xml}
> <xs:element name="valve">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" />
> </xs:sequence>
> <xs:attribute name="class-name" type="xs:string" use="required" />
> <xs:attribute name="module" type="xs:string" use="required" />
> <xs:attribute name="enabled" default="true" type="xs:boolean" />
> </xs:complexType>
> </xs:element>
> {code}
> Version-Release number of selected component (if applicable):
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8572) Documentation in the XSD for the queue-length is incorrect based on the model description
by James Perkins (JIRA)
James Perkins created WFLY-8572:
-----------------------------------
Summary: Documentation in the XSD for the queue-length is incorrect based on the model description
Key: WFLY-8572
URL: https://issues.jboss.org/browse/WFLY-8572
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: James Perkins
Assignee: James Perkins
The documentation for in the XSD for the {{queue-length}} on the {{managed-executor-service}} states:
{quote}
A managed executor service (implementing javax.enterprise.concurrent.ManagedExecutorService).
If the "thread-factory" attribute is not defined a managed thread factory with no context service and normal thread priority will be created and used by the executor.
The task queue is based on the values of "core-threads" and "queue-length":
* If "queue-length" is 0, or "queue-length" is Integer.MAX_VALUE (2147483647) and "core-threads" is 0, direct handoff queuing strategy will be used and a SynchronousQueue will be created.
* If "queue-length" is Integer.MAX_VALUE but "core-threads" is not 0, an unbounded queue will be used.
* For any other valid value for "queue-length", a bounded queue wil be created.
{quote}
The model description states:
{quote}
The executors task queue capacity. A length of 0 means direct hand-off and possible rejection will occur. An undefined length (the default), or Integer.MAX_VALUE, indicates that an unbounded queue should be used. All other values specify an exact queue size. If an unbounded queue or direct hand-off is used, a core-threads value greater than zero is required.
{quote}
The two descriptions should match. The model validation should also be checked as one of the messages doesn't seem to be correct:
{code:java}
// Validate an unbounded queue
if (!queueLength.isDefined() || queueLength.asInt() == Integer.MAX_VALUE) {
if (coreThreads.isDefined() && coreThreads.asInt() <= 0) {
throw EeLogger.ROOT_LOGGER.invalidCoreThreadsSize(coreThreads.asString());
}
}
{code}
That message doesn't really describe the real problem and will always be
{quote}
WFLYEE0112: The core-threads value must be greater than 0 when the queue-length is 0
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2670) list-add doesn't work for nested list of child attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2670?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2670:
----------------------------------------
Assignee: Brian Stansberry (was: Tomaz Cerar)
> list-add doesn't work for nested list of child attribute
> --------------------------------------------------------
>
> Key: WFCORE-2670
> URL: https://issues.jboss.org/browse/WFCORE-2670
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
> Priority: Critical
>
> The list-add doesn't work for a child of an attribute as in the example below
> Add a dir-context first
> {code}
> /profile=full/subsystem=elytron/dir-context=dir2:add(url="ldap://test")
> {code}
> Add a ldap-realm
> {code}
> /profile=full/subsystem=elytron/ldap-realm=foobar2:add(dir-context=dir2,identity-mapping={rdn-identifier=test})
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }}}}}}
> }
> {code}
> This is the command to add the item to the list
> {code}
> /profile=full/subsystem=elytron/ldap-realm=foobar2:list-add(name=identity-mapping.new-identity-attributes,value={name=key2,value=["val1","val2"]})
> {
> "outcome" => "failed",
> "result" => undefined,
> "server-groups" => undefined,
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months