[JBoss JIRA] (WFCORE-2540) Update JACC Version property name and version to match WildFly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2540?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2540:
------------------------------------------
[~brian.stansberry] This may be a good topic for tomorrow's call.
We don't really want JACC in Core but as the subsystem needs to manage JACC and the subsystem needs to be in Core the dependency has been pulled in. Even more if we add Elytron the core feature feature pack we also don't really want JACC.
Any thoughts on either how a subsystem can be slimmed to make it compatible with core, or expanded to satisfy it's WildFly requirements.
Peter had explored detecting if required classes are available and skipping specific resource registrations but that does not help with the XML schema.
> Update JACC Version property name and version to match WildFly
> --------------------------------------------------------------
>
> Key: WFCORE-2540
> URL: https://issues.jboss.org/browse/WFCORE-2540
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta10
>
>
> (The definition in WildFly can likely be removed as well)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-945) User names in Elytron FileSystemRealm are not case sensitive on Windows
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/ELY-945?page=com.atlassian.jira.plugin.sy... ]
Bartosz Baranowski reassigned ELY-945:
--------------------------------------
Assignee: Bartosz Baranowski (was: Darran Lofthouse)
> User names in Elytron FileSystemRealm are not case sensitive on Windows
> -----------------------------------------------------------------------
>
> Key: ELY-945
> URL: https://issues.jboss.org/browse/ELY-945
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Bartosz Baranowski
> Priority: Blocker
>
> User names are case sensitive on Linux but not on Windows when using the Elytron {{FileSystemSecurityRealm}}
> This is IMO a security issue. And it also affects platform certifications.
> If this is by any chance an expected behavior, then it has to be emphasized in documentation and in the domain model too (description of file-system-realm)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2497:
------------------------------------------
[~brian.stansberry] I am thinking about the reload required issue we looked at the other day for Alexey - if a child depends on it's parent is it possible to define an implicit capability reference so if the parent already put the server in a reload required state the runtime steps for the child will be skipped?
> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2497
> URL: https://issues.jboss.org/browse/WFCORE-2497
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta10
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2497:
------------------------------------------
Correct, the parent resource is still unaware of it's child so the parent can be added as one atomic step which will install and start it's services, the child can then be added as a second atomic step and register it's services.
> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2497
> URL: https://issues.jboss.org/browse/WFCORE-2497
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta10
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Jens Viebig (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
Jens Viebig edited comment on WFCORE-482 at 3/15/17 6:17 AM:
-------------------------------------------------------------
Just a note for people that just want their application using log4j2 to log to the wildfly server log (for example because of using a framework struts2 which is using log4j2)
This might not be an answer to the original question, but people might come here because of google results for "wildfly log4j2"
The answer is here:
http://stackoverflow.com/questions/26313113/wrong-logging-in-jboss-wildfl...
Just include:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-to-slf4j</artifactId>
<version>2.7</version>
</dependency>
was (Author: jviebig):
Just a note for people that just want their application using log4j2 to log to the wildfly server log (for example because of using a framework struts2 which is using log4j2)
The answer is here:
http://stackoverflow.com/questions/26313113/wrong-logging-in-jboss-wildfl...
Just include:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-to-slf4j</artifactId>
<version>2.7</version>
</dependency>
> 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, 1 month
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Jens Viebig (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
Jens Viebig commented on WFCORE-482:
------------------------------------
Just a note for people that just want their application using log4j2 to log to the wildfly server log (for example because of using a framework struts2 which is using log4j2)
The answer is here:
http://stackoverflow.com/questions/26313113/wrong-logging-in-jboss-wildfl...
Just include:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-to-slf4j</artifactId>
<version>2.7</version>
</dependency>
> 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, 1 month
[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ]
Martin Choma commented on WFCORE-2497:
--------------------------------------
"The behaviour of the parent is unaffected by the existence or configuration of the child."
Does that mean, that server reload will be not necessary after adding *-authentication-factory ?
> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2497
> URL: https://issues.jboss.org/browse/WFCORE-2497
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta10
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1477) DMN Extension Elements
by Alexandros Koufoudakis (JIRA)
Alexandros Koufoudakis created DROOLS-1477:
----------------------------------------------
Summary: DMN Extension Elements
Key: DROOLS-1477
URL: https://issues.jboss.org/browse/DROOLS-1477
Project: Drools
Issue Type: Feature Request
Components: dmn engine
Reporter: Alexandros Koufoudakis
Assignee: Edson Tirelli
Currently, the extension elements are disregarded. As I'm working in one of the projects, which uses Drools 7 beta release and relies on extension elements, I would like to add this feature and to try to implement it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1005) Remote naming client from EAP 7.0 can't authenticate against EAP 7.1
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1005?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1005:
----------------------------------
Fix Version/s: 1.1.0.Beta32
> Remote naming client from EAP 7.0 can't authenticate against EAP 7.1
> --------------------------------------------------------------------
>
> Key: ELY-1005
> URL: https://issues.jboss.org/browse/ELY-1005
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.1.0.Beta29
> Reporter: Darran Lofthouse
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 1.1.0.Beta32
>
>
> When using the jboss-remote-naming library from EAP 7.0 against EAP 7.1.0.DR13 the client is unable to authenticate and all lookups time out ( {{java.net.ConnectException: Operation failed with status WAITING after 5000 MILLISECONDS}} )
> The exact same client code with the same dependencies works when running against EAP 7.1.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1005) Incompatible handling of digest-uri from legacy clients.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1005?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1005:
----------------------------------
Summary: Incompatible handling of digest-uri from legacy clients. (was: Remote naming client from EAP 7.0 can't authenticate against EAP 7.1)
> Incompatible handling of digest-uri from legacy clients.
> --------------------------------------------------------
>
> Key: ELY-1005
> URL: https://issues.jboss.org/browse/ELY-1005
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.1.0.Beta29
> Reporter: Darran Lofthouse
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 1.1.0.Beta32
>
>
> When using the jboss-remote-naming library from EAP 7.0 against EAP 7.1.0.DR13 the client is unable to authenticate and all lookups time out ( {{java.net.ConnectException: Operation failed with status WAITING after 5000 MILLISECONDS}} )
> The exact same client code with the same dependencies works when running against EAP 7.1.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month