October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9431) Write a test to ensure a library in an EAR uses the correct log context

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-9431?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-9431: -------------------------------- Summary: Write a test to ensure a library in an EAR uses the correct log context (was: Not able to separate application(EAR) logging with the use of logging profile) > Write a test to ensure a library in an EAR uses the correct log context > ----------------------------------------------------------------------- > > Key: WFLY-9431 > URL: https://issues.jboss.org/browse/WFLY-9431 > Project: WildFly > Issue Type: Task > Components: Logging, Test Suite > Reporter: James Perkins > Assignee: James Perkins > Attachments: 01933631-new.tar.gz, logging-profile.zip > > > Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file. > WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log. > when we access application we can see logging from EAR1 into EAR2 log file . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3351) Not able to separate application(EAR) logging with the use of logging profile

by James Perkins (JIRA)

James Perkins created WFCORE-3351: ------------------------------------- Summary: Not able to separate application(EAR) logging with the use of logging profile Key: WFCORE-3351 URL: https://issues.jboss.org/browse/WFCORE-3351 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins Attachments: 01933631-new.tar.gz, logging-profile.zip Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file. WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log. when we access application we can see logging from EAR1 into EAR2 log file . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9431) Not able to separate application(EAR) logging with the use of logging profile

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-9431?page=com.atlassian.jira.plugin.... ] James Perkins moved WFCORE-3351 to WFLY-9431: --------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-9431 (was: WFCORE-3351) Issue Type: Task (was: Bug) Component/s: Logging Test Suite (was: Logging) Steps to Reproduce: (was: 1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration) 2. Deploy both EAR files and access them 3. Check log files. *Note:* The following reproducer only works on WildFly Full, but the issue itself is likely in WIldFly Core. To reproduce with the attached {{logging-profile.zip}} do the follow: # Build the project and deploy the EAR. ## With maven you can do {{mvn clean isntall && cd ear && mvn wildfly:deploy -Pconfigure-logging}} # In a browser go to http://localhost:8080/test-war-one/rest/log # Next go to http://localhost:8080/test-war-two/rest/log, here you'll see less log messages # Now if you go to http://localhost:8080/test-war-one/rest/read you'll see a mix of log messages from both WAR's) > Not able to separate application(EAR) logging with the use of logging profile > ----------------------------------------------------------------------------- > > Key: WFLY-9431 > URL: https://issues.jboss.org/browse/WFLY-9431 > Project: WildFly > Issue Type: Task > Components: Logging, Test Suite > Reporter: James Perkins > Assignee: James Perkins > Attachments: 01933631-new.tar.gz, logging-profile.zip > > > Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file. > WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log. > when we access application we can see logging from EAR1 into EAR2 log file . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1756) Align Rule Unit doc chapter to current OOPath syntax

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1756?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1756: ----------------------------------- Sprint: 2017 Week 40-41 > Align Rule Unit doc chapter to current OOPath syntax > ---------------------------------------------------- > > Key: DROOLS-1756 > URL: https://issues.jboss.org/browse/DROOLS-1756 > Project: Drools > Issue Type: Bug > Components: docs > Reporter: Matteo Mortari > Assignee: Matteo Mortari > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1387) SSLContext for where authentication client resources load from a URI.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1387?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1387: ---------------------------------- Summary: SSLContext for where authentication client resources load from a URI. (was: SSLContext for where authentication client resources load from a resource.) > SSLContext for where authentication client resources load from a URI. > --------------------------------------------------------------------- > > Key: ELY-1387 > URL: https://issues.jboss.org/browse/ELY-1387 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta6 > > > Where resources can be loaded from a URI we may want to define an SSLContext for access to that resource so we can verify it is a trusted resource. > i.e. our local config contains internal key and trust stores but the remove destinations may change so we load the certificates and revocation lists from an internal trusted source. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1082) Documentation is missing in elytron-1_0.xsd

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1082?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse commented on ELY-1082: --------------------------------------- We have a load more documentation here as well https://docs.jboss.org/author/display/WFLY/authentication-client feel free to borrow from here or update if it makes more sense whilst looking at the actual schemas. > Documentation is missing in elytron-1_0.xsd > ------------------------------------------- > > Key: ELY-1082 > URL: https://issues.jboss.org/browse/ELY-1082 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta34 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Critical > > XSD file {{elytron-1_0.xsd}} [1] includes almost no documentation. If this XSD is included in server distribution (as {{docs/schema/elytron-1_0.xsd}}) then it affects user experience. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3041) Cannot add policy resource with no parameter

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3041?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3041: ---------------------------------------- Assignee: Brian Stansberry (was: Michal Petrov) [~michpetrov] I want to take this one, because while the work to get this correct is reasonable, we also have to deal with the fact that we already released this API in a .Final release of WildFly Core, so I'm going to have to do a fair amount of black magic stuff to allow it to work compatibly with what we released. If this wasn't a last minute Blocker I'd be happy to work through the black magic with you, but, well, it is last minute. :) Thanks for picking this up and looking at it! If you hadn't we wouldn't have corrected it in time. > Cannot add policy resource with no parameter > -------------------------------------------- > > Key: WFCORE-3041 > URL: https://issues.jboss.org/browse/WFCORE-3041 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Claudio Miranda > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 3.0.5.Final > > > subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters. > {code} > /profile=full/subsystem=elytron/policy=policy_test:add > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}}, > "rolled-back" => true, > "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => { > "outcome" => "failed", > "failure-description" => "Could find policy provider with name [policy_test]", > "rolled-back" => true > }}}}}} > } > {code} > To add is necessary to inform either custom-policy or jacc-policy > {code} > /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}]) > { > "outcome" => "success", > "result" => undefined, > "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > }}}}}} > } > {code} > There is also a problem related to "default-policy" being set to a non existent policy. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1757) DefaultKnowledgeHelper.modify() does nothing

by Jon Kranes (JIRA)

Jon Kranes created DROOLS-1757: ---------------------------------- Summary: DefaultKnowledgeHelper.modify() does nothing Key: DROOLS-1757 URL: https://issues.jboss.org/browse/DROOLS-1757 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.3.0.Final Reporter: Jon Kranes Assignee: Mario Fusco In org.drools.core.base.DefaultKnowledgeHelper the modify() method has an empty implementation. There is no documentation for this method in the interface org.drools.core.spi.KnowledgeHelper so it's unclear what this method is supposed to do (is it the same as update() or somehow different?). But in any case it seems like an oversight for the method to do nothing at all. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-183) Secure link from CloudForms to MW Provider using SSL

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-183?page=com.atlassian.jira.pl... ] Prachi Yadav resolved HAWKULARQE-183. ------------------------------------- Resolution: Done > Secure link from CloudForms to MW Provider using SSL > ---------------------------------------------------- > > Key: HAWKULARQE-183 > URL: https://issues.jboss.org/browse/HAWKULARQE-183 > Project: Hawkular QE > Issue Type: Task > Reporter: Prachi Yadav > Assignee: Prachi Yadav > > The connection between the middleware provider in CloudForms and the middleware manager should be secure by certificates maintained/managed by CloudForms using SSL — Requires that the client box trusts Hawkular Services certificate. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-183) Secure link from CloudForms to MW Provider using SSL

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-183?page=com.atlassian.jira.pl... ] Prachi Yadav commented on HAWKULARQE-183: ----------------------------------------- This test is passed in DR01 https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testr... > Secure link from CloudForms to MW Provider using SSL > ---------------------------------------------------- > > Key: HAWKULARQE-183 > URL: https://issues.jboss.org/browse/HAWKULARQE-183 > Project: Hawkular QE > Issue Type: Task > Reporter: Prachi Yadav > Assignee: Prachi Yadav > > The connection between the middleware provider in CloudForms and the middleware manager should be secure by certificates maintained/managed by CloudForms using SSL — Requires that the client box trusts Hawkular Services certificate. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
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 October 2017