[JBoss JIRA] (LOGMGR-89) LogContext's root logger is not created with a strong child hash map when strong=true
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-89:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1052198|https://bugzilla.redhat.com/show_bug.cgi?id=1052198] from VERIFIED to CLOSED
> LogContext's root logger is not created with a strong child hash map when strong=true
> -------------------------------------------------------------------------------------
>
> Key: LOGMGR-89
> URL: https://issues.jboss.org/browse/LOGMGR-89
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit)
> Reporter: Kyle Lape
> Assignee: David Lloyd
> Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost.
> Given this configuration
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">
> <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender">
> <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/>
> <param name="MaxFileSize" value="2MB"/>
> <param name="MaxBackupIndex" value="5"/>
> <param name="Append" value="true"/>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
> </layout>
> </appender>
> <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender">
> <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/>
> <param name="MaxFileSize" value="2MB"/>
> <param name="MaxBackupIndex" value="5"/>
> <param name="Append" value="true"/>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
> </layout>
> </appender>
> <logger name="com.redhat" additivity="false">
> <level value="TRACE"/>
> <appender-ref ref="SAMPLE_APP_MDB"/>
> </logger>
> <root>
> <priority value="TRACE"/>
> <appender-ref ref="SAMPLE_APP"/>
> </root>
> </log4j:configuration>
> {code}
> Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used. One message like this is also printed to the log:
> {noformat}
> 11:33:00,110 INFO [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB].
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-2777) JNDI external context binding doesn't properly set a module class loader
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2777?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2777:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1057168|https://bugzilla.redhat.com/show_bug.cgi?id=1057168] from VERIFIED to CLOSED
> JNDI external context binding doesn't properly set a module class loader
> ------------------------------------------------------------------------
>
> Key: WFLY-2777
> URL: https://issues.jboss.org/browse/WFLY-2777
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.CR1
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 8.0.0.Final
>
>
> The current implementation of JNDI external context binding takes a module class loader if based by a module for loading a initialContextClassName only (note that this initialContextClassName is one of InitialContext, InitialDirContext or InitialLdapContext). While it rather needs to switch TCCL to the module class loader to be available when trying to get a new instance of it at line 87, see the snippet below. As this is the moment when it constructs a new initial context from a factory class given by environment properties.
> {code:java|title=naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java}
> 83 Module module = Module.getBootModuleLoader().loadModule(ModuleIdentifier.fromString(initialContextModule));
> 84 loader = module.getClassLoader();
> 85 initialContextClass = Class.forName(initialContextClassName, true, module.getClassLoader());
> 86 Constructor ctor = initialContextClass.getConstructor(Hashtable.class);
> 87 context = (Context) ctor.newInstance(newEnvironment);
> {code}
> Due to this issue the binding fails with an exception as follows:
> {noformat}
> 17:02:46,740 ERROR [stderr] (default task-1) Caused by: java.lang.reflect.InvocationTargetException
> 17:02:46,740 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 17:02:46,740 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 17:02:46,741 ERROR [stderr] (default task-1) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 17:02:46,741 ERROR [stderr] (default task-1) at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 17:02:46,742 ERROR [stderr] (default task-1) at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> 17:02:46,742 ERROR [stderr] (default task-1) at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:46)
> 17:02:46,743 ERROR [stderr] (default task-1) at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> 17:02:46,743 ERROR [stderr] (default task-1) ... 36 more
> 17:02:46,744 ERROR [stderr] (default task-1) Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory from classloader ModuleClassLoader for Module "deployment.messagesender.war:main" from Service Module Loader
> 17:02:46,744 ERROR [stderr] (default task-1) at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> 17:02:46,744 ERROR [stderr] (default task-1) at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 17:02:46,745 ERROR [stderr] (default task-1) at javax.naming.InitialContext.<init>(InitialContext.java:216)
> 17:02:46,745 ERROR [stderr] (default task-1) at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
> 17:02:46,745 ERROR [stderr] (default task-1) at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:90)
> 17:02:46,746 ERROR [stderr] (default task-1) at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> 17:02:46,746 ERROR [stderr] (default task-1) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 17:02:46,746 ERROR [stderr] (default task-1) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
> 17:02:46,746 ERROR [stderr] (default task-1) at javax.naming.InitialContext.init(InitialContext.java:242)
> 17:02:46,747 ERROR [stderr] (default task-1) at javax.naming.InitialContext.<init>(InitialContext.java:216)
> 17:02:46,747 ERROR [stderr] (default task-1) ... 43 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-640:
--------------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1085497|https://bugzilla.redhat.com/show_bug.cgi?id=1085497] from VERIFIED to CLOSED
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-1351) Incorrect exception handling in CoreGroupCommunicationService#handle
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1351?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1351:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 963448|https://bugzilla.redhat.com/show_bug.cgi?id=963448] from VERIFIED to CLOSED
> Incorrect exception handling in CoreGroupCommunicationService#handle
> --------------------------------------------------------------------
>
> Key: WFLY-1351
> URL: https://issues.jboss.org/browse/WFLY-1351
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Dennis Reed
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Alpha3
>
>
> org/jboss/as/clustering/impl/CoreGroupCommunicationService#handle catches and hides any internal exceptions, and just returns null instead.
> This breaks callers of CoreGroupCommunicationService when they get a null value where it's not expected (after verifying that the response was not flagged as an exception)
> java.lang.NullPointerException
> at org.jboss.as.clustering.lock.AbstractClusterLockSupport.lock(AbstractClusterLockSupport.java:157)
> It also catches an exception from the called method, and returns it as the return value, instead of just throwing it as an exception so it can be properly returned as an exception inside JGroups' RequestCorrelator.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-815:
--------------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1085497|https://bugzilla.redhat.com/show_bug.cgi?id=1085497] from VERIFIED to CLOSED
> NegotiationAuthenticator loses post data
> ----------------------------------------
>
> Key: SECURITY-815
> URL: https://issues.jboss.org/browse/SECURITY-815
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_5
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2
>
>
> The NegotiationAuthenticator loses post data.
> A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding.
> If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL.
> If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-2266) Deployment Overlay feature is not able to replace the application libraries.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2266:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1016995|https://bugzilla.redhat.com/show_bug.cgi?id=1016995] from VERIFIED to CLOSED
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
> Key: WFLY-2266
> URL: https://issues.jboss.org/browse/WFLY-2266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Environment: All Operating Systems
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
> Labels: deployment
> Fix For: 8.0.0.CR1
>
>
> -----------------------
> According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."
> Here it talks about "replacing jar libraries" which is not working as expected and causes the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> *Step-1).* Undeploy if any existing application is deployed and then freshly deploy the application.
> {quote}
> [standalone@localhost:9999 /] undeploy DeploymentOverlayDemo.war
> [standalone@localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> *Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature. In the attached ant based Demo just do _"ant compile"_ to create a new Jar _"${project.dir}/tmp/Hello.jar"_
> *Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone@localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>
> Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 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]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months