[JBoss JIRA] (WFLY-963) NoSuchMethodError pushOwner(ServiceTarget, ServiceName)
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-963?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell commented on WFLY-963:
-----------------------------------
Note: this jira is for code in modules not in deployments. There was a bug in an earlier version of JBoss AS 7.1.x where a sar could not bind into jndi at deployment time. This was fixed in AS 7.2 via - https://issues.jboss.org/browse/AS7-5584
> NoSuchMethodError pushOwner(ServiceTarget,ServiceName)
> ------------------------------------------------------
>
> Key: WFLY-963
> URL: https://issues.jboss.org/browse/WFLY-963
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Jeff Yu
> Assignee: Eduardo Martins
>
> In the JBoss AS-7.1.1.Final, I used the following code to do the JNDI binding/unbinding from the modules (not deployed in the deployment folder).
>
>
> public class JndiRegistry {
>
> private static final Log LOG= LogFactory.getLog(JndiRegistry.class);
>
> public static void bindToJndi(String name, Object object) {
> ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
> if (serviceTarget != null) {
> WritableServiceBasedNamingStore.pushOwner(serviceTarget);
> try {
> InitialContext context = new InitialContext();
> context.bind(name, object);
> } catch (NamingException e) {
> LOG.error("Error in binding the object in JNDI.");
> }
> }
> }
>
> public static void unbindFromJndi(String name){
> ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
> if (serviceTarget != null) {
> WritableServiceBasedNamingStore.pushOwner(serviceTarget);
> try {
> InitialContext context = new InitialContext();
> context.unbind(name);
> } catch (NamingException e) {
> LOG.error("Error in unbinding the object from JNDI.");
> }
> }
> }
>
> }
>
>
>
> With the EAP 6.1.0.Alpha, I am getting the error of "
> Caused by: java.lang.NoSuchMethodError: org.jboss.as.naming.WritableServiceBasedNamingStore.pushOwner(Lorg/jboss/msc/service/ServiceTarget;[Lorg/jboss/msc/service/ServiceName;)V",
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1345) Admin console: Refresh issue in deployment scanner view
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1345?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1345:
------------------------------------------
Bugzilla Update: (was: Perform)
Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=973471)
> Admin console: Refresh issue in deployment scanner view
> -------------------------------------------------------
>
> Key: WFLY-1345
> URL: https://issues.jboss.org/browse/WFLY-1345
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Reporter: Harald Pehl
> Assignee: Harald Pehl
> Priority: Minor
> Fix For: 8.0.0.Alpha3
>
>
> When removing a deployment scanner in "Profile / Core / Deployment Scanners" the cell table is not refreshed and the deleted scanner is still visible.
> Same problem in
> * "Profile / Core / Threads / Thread Factories"
> * "Profile / Core / Threads / Thread Pools"
> Relevant views:
> * {{org.jboss.as.console.client.shared.subsys.deploymentscanner.ScannerView}}
> * {{org.jboss.as.console.client.shared.subsys.threads.ThreadFactoryView}}
> * {{org.jboss.as.console.client.shared.subsys.threads.AbstractThreadPoolView}}
> Problem seems to be related to abstract base class {{org.jboss.as.console.client.shared.viewframework.AbstractEntityView}}. The refresh issue only occurs if entries are deleted without selecteing them before.
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1595) Possible race in jboss-invocation proxies resulting in NPE in initializer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1595?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1595:
-----------------------------------------------
Stuart Douglas <sdouglas(a)redhat.com> made a comment on [bug 978603|https://bugzilla.redhat.com/show_bug.cgi?id=978603]
jboss-invocation proxies use a thread local to pass information into the initializer, in most cases this works fine as long as only a single thread is attempting to define the class. It is possible for a different thread to load the class that the one that defines it.
As far as I can tell this will only affect CMP, as most other proxies are created at deployment time in a single thread.
> Possible race in jboss-invocation proxies resulting in NPE in initializer
> -------------------------------------------------------------------------
>
> Key: WFLY-1595
> URL: https://issues.jboss.org/browse/WFLY-1595
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.0.0.Alpha2
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha3
>
>
> jboss-invocation proxies use a thread local to pass information into the initializer, in most cases this works fine as long as only a single thread is attempting to define the class. It is possible for a different thread to load the class that the one that defines it.
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1271) Infinispan remote-store requires remote-servers but not marked as required in mgmt model
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-1271?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-1271:
----------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> Infinispan remote-store requires remote-servers but not marked as required in mgmt model
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-1271
> URL: https://issues.jboss.org/browse/WFLY-1271
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Takayoshi Kimura
> Assignee: Richard Achmatowicz
>
> Affect version is actually 8.0.0.Alpha1-SNAPSHOT (before 8.0.0.Alpha1, we don't have such selection).
> Command remote-store=REMOTE_STORE:add fails with this exception:
> {quote}
> 15:58:05,112 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014607: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014675: Failed to marshal configuration
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:50) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:80) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:522) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:178) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:359) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:513) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:499) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 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]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014680: Failed to write configuration
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:123) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:43) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 22 more
> Caused by: java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:128) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1205) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.processCommonCacheAttributesElements(InfinispanSubsystemXMLWriter.java:282)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:124)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:42)
> at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1191) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1108) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:103) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 23 more
> {quote}
> Reproduce steps:
> {quote}
> [standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/file-store=FILE_STORE:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014677: Failed to persist configuration change: JBAS014675: Failed to marshal configuration",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> [standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add(remote-servers=[])
> {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }
> {quote}
> In $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd, it looks like the remote-server is required as it's defined as minOccurs="1":
> {quote}
> <xs:element name="remote-server" type="tns:remote-server" minOccurs="1" maxOccurs="unbounded"/>
> {quote}
--
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
12 years, 4 months
[JBoss JIRA] (SECURITY-744) WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-744?page=com.atlassian.jira.plug... ]
Stefan Guilhen commented on SECURITY-744:
-----------------------------------------
Arjan's analysis is really good and I think he is right. I'll incorporate his suggestions so that the Subject is populated accordingly.
> WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal
> ----------------------------------------------------------------------------------
>
> Key: SECURITY-744
> URL: https://issues.jboss.org/browse/SECURITY-744
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security
>
> {{WebJASPIAuthenticator}} creates a new Subject that it passes to the JASPIC Auth Module (SAM):
> {code}
> Subject clientSubject = new Subject();
> if (sam != null) {
> result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh);
> }
> {code}
> [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...]
> Afterwards this Subject instance is put into the {{JBossGenericPrincipal}} when this is being build:
> {code}
> protected Principal buildJBossPrincipal(Subject subject, Principal principal, GroupPrincipalCallback gpc) {
> // ...
> // build and return the JBossGenericPrincipal.
> return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, subject);
> }
> {code}
> [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...]
> This seems to assume that the JASPIC Auth Module has populated the Subject (as happens with JAAS login modules), but this is not what happens. JASPIC Auth Modules unlike JAAS login modules are universal and have no knowledge of the container specific Subject layout.
> The container should thus populate the Subject based on the callbacks.
> {{WebJASPIAuthenticator}} does uses the callbacks to store the caller/user principal and roles directly into the {{JBossGenericPrincipal}}. Calls like {{HttpServletRequest#getUserPrincipal}} directly return {{JBossGenericPrincipal#getUserPrincipal}} and thus work.
> However, {{EJBContext#getCallerPrincipal()}} which is implemented by {{org.jboss.as.security.service.SimpleSecurityManager#getCallerPrincipal}} works with {{securityContext.getSubjectInfo().getAuthenticatedSubject}} and does _not_ work.
> This {{SubjectInfo}} is initialized in {{org.jboss.as.web.security.SecurityContextAssociationValve}} via the following code:
> {code}
> sc.getUtil().createSubjectInfo(new SimplePrincipal(
> principal.getName()),
> principal.getCredentials(),
> principal.getSubject() // clientSubject from JASPIC SAM
> );
> {code}
> (principal here is the {{JBossGenericPrincipal}} that's returned by {{WebJASPIAuthenticator}})
> Because the Subject instance used here is still the empty instance, the authenticated identity will not be available in EJB beans. {{EJBContext#getCallerPrincipal()}} will always return the anonymous principal and every check for a role will return false.
> Adding something like the following code to {{buildJBossPrincipal}} seems to propagate the authenticated identity correctly to the EJB module:
> {code}
> Subject authenticatedSubject = new Subject();
> // Add the caller principal to the Subject
> Group callerPrincipalGroup = new SimpleGroup("CallerPrincipal");
> callerPrincipalGroup.addMember(principal);
> authenticatedSubject.getPrincipals().add(callerPrincipalGroup);
>
> // Add the roles to the Subject
> if (!roles.isEmpty()) {
> Group rolesGroup = new SimpleGroup("Roles");
> for (String role : roles) {
> rolesGroup.addMember(new SimplePrincipal(role));
> }
> authenticatedSubject.getPrincipals().add(rolesGroup);
> }
> return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, authenticatedSubject);
> {code}
> I've tested [locally|https://github.com/javaeekickoff/jboss-as-jaspic-patch/commit/31b...] with this patch and it indeed seems to work.
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1595) Possible race in jboss-invocation proxies resulting in NPE in initializer
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-1595:
------------------------------------
Summary: Possible race in jboss-invocation proxies resulting in NPE in initializer
Key: WFLY-1595
URL: https://issues.jboss.org/browse/WFLY-1595
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 8.0.0.Alpha2
Reporter: Stuart Douglas
Assignee: Stuart Douglas
Fix For: 8.0.0.Alpha3
jboss-invocation proxies use a thread local to pass information into the initializer, in most cases this works fine as long as only a single thread is attempting to define the class. It is possible for a different thread to load the class that the one that defines it.
--
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
12 years, 4 months