[JBoss JIRA] (LOGMGR-60) LoggerFactory is ignored
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-60?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved LOGMGR-60.
-------------------------------
Resolution: Duplicate Issue
> LoggerFactory is ignored
> ------------------------
>
> Key: LOGMGR-60
> URL: https://issues.jboss.org/browse/LOGMGR-60
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.GA
> Reporter: Alex Alvarez
> Assignee: David Lloyd
>
> When providing a factory to BridgeRepository.getLogger(final String name, final LoggerFactory factory) the factory is ignored, which leads to ClassCastExceptions up the chain. The most common workaround seems to be to manipulate the classloader or exclude the log manager, but this only adds more complexity, and leads to loss of functionality when overloading the Logger class.
> Use this example factory to test:
> public static class MyTestLoggerFactory implements LoggerFactory {
> public Logger makeNewLoggerInstance(String name) {
> return new MyTestLogger(name);
> }
> }
--
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, 9 months
[JBoss JIRA] (WFLY-3049) IronJacamar 1.1.4.Final
by Jesper Pedersen (JIRA)
Jesper Pedersen created WFLY-3049:
-------------------------------------
Summary: IronJacamar 1.1.4.Final
Key: WFLY-3049
URL: https://issues.jboss.org/browse/WFLY-3049
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Build System
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Priority: Blocker
Fix For: 8.0.1.Final
--
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, 9 months
[JBoss JIRA] (WFLY-975) Deployment replace causes invalid state in DUP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-975?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-975:
----------------------------------------------
Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 924562|https://bugzilla.redhat.com/show_bug.cgi?id=924562] from ON_QA to VERIFIED
> Deployment replace causes invalid state in DUP
> ----------------------------------------------
>
> Key: WFLY-975
> URL: https://issues.jboss.org/browse/WFLY-975
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
> Attachments: v200.jar, v201.jar, webapp-v200.war
>
>
> Webapp A depends on deployment B. Replacing B causes NPE in JPAInterceptorProcessor
> {code}
> 12:52:05,712 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:52:05,889 INFO [org.jboss.as.server] (XNIO-1 task-8) JBAS018559: Deployed "v200.jar" (runtime-name : "v200.jar")
> 12:52:37,207 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "webapp-v200.war" (runtime-name: "webapp-v200.war")
> 12:52:37,349 INFO [org.jboss.web] (ServerService Thread Pool -- 52) JBAS018210: Register web context: /webapp-v200
> 12:52:37,436 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "webapp-v200.war" (runtime-name : "webapp-v200.war")
> 12:53:20,252 INFO [org.jboss.web] (ServerService Thread Pool -- 57) JBAS018224: Unregister web context: /webapp-v200
> 12:53:20,272 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment v200.jar (runtime-name: v200.jar) in 25ms
> 12:53:20,274 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:53:20,293 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of deployment "webapp-v200.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> {code}
> What might be happening here is that replacing B causes ModuleB to go down. Phase FIRST_MODULE_USE of A depends on ModuleB, which causes a call to undeploy() on the DUPs for A. When ModuleB becomes available again, deploy() is called on the DUPs for A again. Possibly because of the cleanup phase, necessary state is lost and we see a NPE.
> AFAICS, this is a variation of the feature request that DUPs support multiple calls to deploy/undeploy.
--
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, 9 months
[JBoss JIRA] (WFLY-3040) Missing modules
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3040:
---------------------------------
Assignee: Tomaz Cerar (was: Thomas Diesler)
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Tomaz Cerar
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 9 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by Matt Jensen (JIRA)
Matt Jensen created WFLY-3048:
---------------------------------
Summary: "Local" authentication fails when LDAP is used for ManagementRealm
Key: WFLY-3048
URL: https://issues.jboss.org/browse/WFLY-3048
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 8.0.0.Final
Environment: Ubuntu 13.04, Xeon-based VPS
Reporter: Matt Jensen
Assignee: Darran Lofthouse
When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local" />
<ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
...
</ldap>
</authentication>
<authorization map-groups-to-roles="false">
<ldap connection="...">
...
</ldap>
</authorization>
</security-realm>
I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
The documentation specifically mentions that <local/> should work along with <ldap/> here:
https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
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, 9 months
[JBoss JIRA] (JBEE-149) Patch Taglibs Bug 33934
by Kevin Formsma (JIRA)
Kevin Formsma created JBEE-149:
----------------------------------
Summary: Patch Taglibs Bug 33934
Key: JBEE-149
URL: https://issues.jboss.org/browse/JBEE-149
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-jstl-api
Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final
Reporter: Kevin Formsma
Assignee: Shelly McGowan
Taglibs fixed a bug where SetTag would retain references to the target object, causing pooled SetTag instances to have much higher memory usage when the target object is large. When using many web threads in JBoss 7.2.2, our heap grows due to these objects being associated to pooled SetTags.
https://issues.apache.org/bugzilla/show_bug.cgi?id=33934
Can this patch be fixed in the jboss fork of taglibs as well?
--
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, 9 months
[JBoss JIRA] (WFLY-3040) Missing modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3040:
----------------------------------------
The org.jboss.genericjms.provider module needs to be provided by the user, containing the necessary binaries provided by the provider (e.g. Tibco) they wish to integrate.
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 9 months
[JBoss JIRA] (WFLY-2581) Provide API for use by ejb-security-interceptors quick start.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2581?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2581:
-----------------------------------
Description:
The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
• org.jboss.as.domain.management.security.RealmUser.
• org.jboss.as.security.remoting.RemotingContext.
• org.jboss.as.controller.security.SubjectUserInfo
The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.
was:The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> Provide API for use by ejb-security-interceptors quick start.
> -------------------------------------------------------------
>
> Key: WFLY-2581
> URL: https://issues.jboss.org/browse/WFLY-2581
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> • org.jboss.as.domain.management.security.RealmUser.
> • org.jboss.as.security.remoting.RemotingContext.
> • org.jboss.as.controller.security.SubjectUserInfo
> The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
> Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
> The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
> Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
> As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.
--
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, 9 months