March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plug... ] Kabir Khan updated SECURITY-805: -------------------------------- Attachment: SECURITY-805.diff Attached patch > Overload SecurityVaultFactory.get() to be able to specify the classloader > ------------------------------------------------------------------------- > > Key: SECURITY-805 > URL: https://issues.jboss.org/browse/SECURITY-805 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assignee: Kabir Khan > Attachments: SECURITY-805.diff > > > To work better with modular class loading in WF -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-456) ResourceConfigurationImpl class not found when using drools-karaf-feature

by Gary Brown (JIRA)

Gary Brown created DROOLS-456: --------------------------------- Summary: ResourceConfigurationImpl class not found when using drools-karaf-feature Key: DROOLS-456 URL: https://issues.jboss.org/browse/DROOLS-456 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Beta1 Reporter: Gary Brown Assignee: Mark Proctor While porting RTGov to Karaf, I have been using Drools 2.0.0.CR5 successfully. However when I updated the version to 2.0.1.Final, and subsequently to 2.1.0.Beta1, I now get a class not found issue: {noformat} 11:26:49,440 | ERROR | l Console Thread | ResourceTypeImpl | 290 - org.kie.internalapi - 6.1.0.20140307-1723 | Error loading resource configuration from properties java.lang.ClassNotFoundException: org.drools.core.builder.conf.impl.ResourceConfigurationImpl not found by org.kie.internalapi [290] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955) at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_07] at java.lang.Class.forName0(Native Method)[:1.7.0_07] at java.lang.Class.forName(Class.java:186)[:1.7.0_07] at org.kie.internal.io.ResourceTypeImpl.fromProperties(ResourceTypeImpl.java:41)[290:org.kie.internalapi:6.1.0.20140307-1723] {noformat} -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2850) AJP connector with external authentication

by Sylvain Brouillat (JIRA)

[ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.... ] Sylvain Brouillat edited comment on WFLY-2850 at 3/14/14 7:28 AM: ------------------------------------------------------------------ I wasn't using AS7/EAP6 but an old configuration AS4, and tomcatAuthentication was set to false by adding ajp connector configuration in server/default/deploy/jbossweb-tomcat55.sar/server.xml : <Connector port="8009" address="bind.address" emptySessionPath="true" enableLookup="true" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" /> It exists a different way to disable tomcatAuthentication in JBoss7.1 from system-properties (https://issues.jboss.org/browse/WFLY-254). You've said : "I have implemented an authenticator based on this in Undertow", are you talking about io.undertow.security.impl.ExternalAuthenticationMechanism class ? Is there a way to enable it from wildfly standalone.xml configuration ? Like using <system-properties> or something else ? was (Author: sylvain.b): Tomcat define tomcatAuthentication attribute for ajp connector, that when set to false, disable tomcatAuthentication and allows apache to handle authentication and pass remote_user throught AJP channel to tomcat (http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html). I wasn't using AS7/EAP6 but an old configuration AS4, and tomcatAuthentication was set to false by adding ajp connector configuration in server/default/deploy/jbossweb-tomcat55.sar/server.xml : <Connector port="8009" address="${bind.address}" emptySessionPath="true" enableLookup="true" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" /> It seems to exist a different way to disable tomcatAuthentication in JBoss7.0 (https://issues.jboss.org/browse/WFLY-254). > AJP connector with external authentication > ------------------------------------------ > > Key: WFLY-2850 > URL: https://issues.jboss.org/browse/WFLY-2850 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Reporter: Geert Coelmont > Assignee: Stuart Douglas > Priority: Critical > > Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along. > A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see. > For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404). -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2648) Review/move the per-logging deployment tests

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.... ] Petr Kremensky commented on WFLY-2648: -------------------------------------- I'll take this. > Review/move the per-logging deployment tests > -------------------------------------------- > > Key: WFLY-2648 > URL: https://issues.jboss.org/browse/WFLY-2648 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: James Perkins > Assignee: Petr Kremensky > Priority: Minor > > The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute. > Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2648) Review/move the per-logging deployment tests

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.... ] Petr Kremensky reassigned WFLY-2648: ------------------------------------ Assignee: Petr Kremensky (was: James Perkins) > Review/move the per-logging deployment tests > -------------------------------------------- > > Key: WFLY-2648 > URL: https://issues.jboss.org/browse/WFLY-2648 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: James Perkins > Assignee: Petr Kremensky > Priority: Minor > > The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute. > Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by Kabir Khan (JIRA)

Kabir Khan created SECURITY-805: ----------------------------------- Summary: Overload SecurityVaultFactory.get() to be able to specify the classloader Key: SECURITY-805 URL: https://issues.jboss.org/browse/SECURITY-805 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assignee: Kabir Khan To work better with modular class loading in WF -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3117) Add tests for add-logging-api-dependencies logging attribute

by Petr Kremensky (JIRA)

Petr Kremensky created WFLY-3117: ------------------------------------ Summary: Add tests for add-logging-api-dependencies logging attribute Key: WFLY-3117 URL: https://issues.jboss.org/browse/WFLY-3117 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Petr Kremensky Assignee: Petr Kremensky https://issues.jboss.org/browse/PRODMGT-591 introduced a new logging subsystem attribute add-logging-api-dependencies. Logging dependencies are still added by default. There are already tests in org.jboss.as.test.integration.logging covering default functionality. We have to test the case when logging modules are not available (set value of *add-logging-api-dependencies* to false). *LoggingDependenciesTestCase* * start the server * deploy a archive with dependency on Log4j * verify that deployment was successful and undeploy it * set *add-logging-api-dependencies=false* * reload the server so the changes are propagated * deploy the archive again * exception should be thrown this time during deployment -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2850) AJP connector with external authentication

by Sylvain Brouillat (JIRA)

[ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.... ] Sylvain Brouillat commented on WFLY-2850: ----------------------------------------- Tomcat define tomcatAuthentication attribute for ajp connector, that when set to false, disable tomcatAuthentication and allows apache to handle authentication and pass remote_user throught AJP channel to tomcat (http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html). I wasn't using AS7/EAP6 but an old configuration AS4, and tomcatAuthentication was set to false by adding ajp connector configuration in server/default/deploy/jbossweb-tomcat55.sar/server.xml : <Connector port="8009" address="${bind.address}" emptySessionPath="true" enableLookup="true" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" /> It seems to exist a different way to disable tomcatAuthentication in JBoss7.0 (https://issues.jboss.org/browse/WFLY-254). > AJP connector with external authentication > ------------------------------------------ > > Key: WFLY-2850 > URL: https://issues.jboss.org/browse/WFLY-2850 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Reporter: Geert Coelmont > Assignee: Stuart Douglas > Priority: Critical > > Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along. > A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see. > For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404). -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-455. -------------------------------- Fix Version/s: 6.1.0.Beta2 Resolution: Done > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.Beta2 > > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-455: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1076361|https://bugzilla.redhat.com/show_bug.cgi?id=1076361] from NEW to ASSIGNED > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Edson Tirelli > Priority: Critical > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- 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

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014