[JBoss JIRA] (WFLY-4359) WSEndpointDeploymentUnit should implement a WS-specific interface
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4359?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-4359:
---------------------------------------
Changing this would most likely mean wrapping any deployment unit that the WS subsystem processes into another object implementing a similar interface as the deployment mechanims was meant to work on DU and the DU was part of the AS ;-).
I take this as a part of the efforts for splitting WFCORE from the WLFY and can work on a solution for proper separation, if that's really required.
> WSEndpointDeploymentUnit should implement a WS-specific interface
> -----------------------------------------------------------------
>
> Key: WFLY-4359
> URL: https://issues.jboss.org/browse/WFLY-4359
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Alessio Soldano
>
> WSEndpointDeploymentUnit implements the DeploymentUnit interface, but not really. A bunch of methods throw UnsupportedOperationException.
> This tells me it's using that interface as a minor short-cut, not because it's truly meant to be a DeploymentUnit impl.
> This is the only impl of this interface outside of WFCORE, and having it here makes it harder to evolve the interface.
> The WS subsystem code should use its own interface (e.g. as a param to WSDeploymentBuilder.build()), and for the call paths that want to use the DeploymentUnit from WFCORE, wrap the DU in an impl of this WS interface and delegate to it.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1876.
----------------------------
Resolution: Done
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-718) Reloading KJAR which contains DSL and RDSLR via KieScanner fails.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-718?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-718.
--------------------------------
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/9ca6cc934
> Reloading KJAR which contains DSL and RDSLR via KieScanner fails.
> -----------------------------------------------------------------
>
> Key: DROOLS-718
> URL: https://issues.jboss.org/browse/DROOLS-718
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.CR4
> Environment: Mac OS X 10.10.2, Oracle HotSpot 1.7.0_71
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
>
> When using the KieScanner to reload a KJAR with a DSL and RDSLR, reloading fails due to that the compiler is unable to find mappings for the language in the RDSLR.
> This is the error I get in my reproducer:
> 2015-02-18 00:45:02,764 [ERROR] [main] [org.drools.compiler.kie.builder.impl.KieContainerImpl] ERROR Unable to update KieBase: KBase1 to release org.kie:scanner-test:1.0-SNAPSHOT
> [7] No mapping entries for expanding: There is a SimpleFact
> [7] Unable to expand: There is a SimpleFact
> [8] No mapping entries for expanding: -with id "2"
> [8] Unable to expand: -with id "2"
> [10] No mapping entries for expanding: Print "Found a simple fact with id 2."
> [10] Unable to expand: Print "Found a simple fact with id 2."
> [7,7]: [ERR 102] Line 7:7 mismatched input 'is' in rule "bla"
> Reproducer project can be found here: https://github.com/DuncanDoyle/brms-kjar-with-dsl-kiescanner
> Just clone the repo and run 'mvn clean test'.
> Note that the reproducer creates the first KJAR, runs test, and then creates the second KJAR. Compilation of the second KJAR fails. When you alter the test to only load the second KJAR, everything works fine.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1876:
--------------------------------
OK, implemented. This is in master, please try it out and let me know whether this fixes the problem of multiple subgroups of the same member.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4332) Wrong path with Stateless WebService and serviceName
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4332?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-4332:
---------------------------------------
If you remove the @Stateless above, the endpoint is not an EJB3 anymore, it becomes a POJO endpoint. The algorithm for computing the default publish path is different for EJB3 and POJO endpoints (because of spec requirements). So nothing wrong here afaics.
> Wrong path with Stateless WebService and serviceName
> ----------------------------------------------------
>
> Key: WFLY-4332
> URL: https://issues.jboss.org/browse/WFLY-4332
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Janario Oliveira
> Assignee: Alessio Soldano
>
> When I have a WebService with serviceName and it is a Stateless It adds a different url.
> e.g.
> @WebService(serviceName = "StatelessWeb") @Stateless
> public class StatelessWebService {
> public boolean executeTest() {return true;}
> }
> It will be available in /StatelessWeb/StatelessWebService. Once if it isn't a stateless it will be in /StatelessWeb
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4332) Wrong path with Stateless WebService and serviceName
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4332?page=com.atlassian.jira.plugin.... ]
Alessio Soldano resolved WFLY-4332.
-----------------------------------
Resolution: Rejected
> Wrong path with Stateless WebService and serviceName
> ----------------------------------------------------
>
> Key: WFLY-4332
> URL: https://issues.jboss.org/browse/WFLY-4332
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Janario Oliveira
> Assignee: Alessio Soldano
>
> When I have a WebService with serviceName and it is a Stateless It adds a different url.
> e.g.
> @WebService(serviceName = "StatelessWeb") @Stateless
> public class StatelessWebService {
> public boolean executeTest() {return true;}
> }
> It will be available in /StatelessWeb/StatelessWebService. Once if it isn't a stateless it will be in /StatelessWeb
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3251) @WebContext overrides realm in web.xml
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3251?page=com.atlassian.jira.plugin.... ]
Alessio Soldano resolved WFLY-3251.
-----------------------------------
Resolution: Done
I believe this is now fixed; you can use the new 'realmName' attribute of @WebContext to specify the name of realm to be used.
> @WebContext overrides realm in web.xml
> --------------------------------------
>
> Key: WFLY-3251
> URL: https://issues.jboss.org/browse/WFLY-3251
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Alessio Soldano
> Fix For: 9.0.0.Beta1
>
>
> In WEB-INF/web.xml I'm having this declaration (to be used for REST and SOAP):
> {code}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Shop</realm-name>
> </login-config>
> {code}
> Furthermore, I'm having a SOAP-based web service:
> {code}
> @WebService(name = "KundeSOAP",
> targetNamespace = "urn:shop:soap:kunde",
> serviceName = "KundeSOAPService")
> @SOAPBinding
> @WebContext(authMethod = "BASIC",
> transportGuarantee = "CONFIDENTIAL",
> secureWSDLAccess = true)
> @Stateless
> @Interceptors(ConstraintViolationInterceptor.class)
> @RolesAllowed({ "...", "..." })
> @SecurityDomain("...")
> public class KundeSOAP {...}
> {code}
> But when the client invokes the server, then the realm name is "EJBWebServiceEndpointServlet Realm".
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4363) Class (own class) not found Exception during trial of getting of StepExecutions with own classes in PersistentUserData
by Serg Jackbean (JIRA)
[ https://issues.jboss.org/browse/WFLY-4363?page=com.atlassian.jira.plugin.... ]
Serg Jackbean commented on WFLY-4363:
-------------------------------------
thanks. to my sorrow i can not now attach test zip.
the issue is simply setting of of own serialisable object -own class in checkPointInfo (in Chunk Job) or UserPersistentData (in StepExecution) in BatchJob for saving in DB tables.
Is there any solution till this fix?
everything is ok after some minutes (5-10) after new start of server and seems (may be it is no important - simply time) after calling of different operations of BatchRuntime: Instances, Executions, StepExecutions
> Class (own class) not found Exception during trial of getting of StepExecutions with own classes in PersistentUserData
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4363
> URL: https://issues.jboss.org/browse/WFLY-4363
> Project: WildFly
> Issue Type: Bug
> Components: Batch, EJB
> Affects Versions: 8.2.0.Final
> Environment: JRE 7, Maven build
> Reporter: Serg Jackbean
> Assignee: Cheng Fang
>
> Exception Class (own class that is saved as Serialisable in PersistentUserData) not Found (in JBeret?) disappears in some in some minutes after some calls of EJB with Batch Jobs according some sequence after new start of server.
> (there was exception -class not found for own class for checkpointInfo also)
> Log:
> 09:55:22,252 ERROR [org.jboss.as.ejb3.invocation] (default task-3) JBAS014134: EJB Invocation failed on component BatchRuntimeService for method public test.Job test.BatchRuntimeService.getJobStepExecutions(java.lang.String,int) throws test.ServiceException: javax.ejb.EJBException: javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at test.BatchRuntimeService$$$view4.getJobStepExecutions(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at test.BatchRuntimeService$Proxy$_$$_Weld$EnterpriseProxy$.getJobStepExecutions(Unknown Source) [classes:]
> at test.web.rest.JobTimerResource.listJobExecutions(JobTimerResource.java:122) [classes:]
> at test.web.rest.JobTimerResource$Proxy$_$$_WeldClientProxy.listJobExecutions(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.10.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
> at org.jberet.repository.JdbcRepository.selectStepExecutions(JdbcRepository.java:651) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.getStepExecutions(JdbcRepository.java:256) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.getStepExecutions(JobOperatorImpl.java:263) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at test.BatchRuntimeService.getJobStepExecutions(BatchRuntimeService.java:153) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> ... 85 more
> Caused by: java.lang.ClassNotFoundException: test.JobBatchResult from [Module "org.jberet.jberet-core:main" from local module loader @675dd521 (finder: local module finder @41539e8b (roots: C:\server\wildfly-8.2.0.Final\modules,C:\server\wildfly-8.2.0.Final\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_45]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:625) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_45]
> at org.jberet.util.BatchUtil.bytesToSerializableObject(BatchUtil.java:111) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.createStepExecutionsFromResultSet(JdbcRepository.java:746) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.selectStepExecutions(JdbcRepository.java:649) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 123 more
> 09:55:22,265 ERROR [test.web.rest.ExceptionHttpStatusResolver] (default task-3) javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBNAME-62) Incorrect callback handler used during authentication (SASL)
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/JBNAME-62?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez updated JBNAME-62:
--------------------------------------------
Description:
Cluster topology messages are not using the proper callbackhandler when the connection is being established.
{code}
06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
... 7 more
{code}
Before that, this log is produced:
{code}
DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
{code}
was:
Cluster topology messages are not using the proper callbackhandler when the connection is being established.
{code}
06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
... 7 more
{code}
> Incorrect callback handler used during authentication (SASL)
> -------------------------------------------------------------
>
> Key: JBNAME-62
> URL: https://issues.jboss.org/browse/JBNAME-62
> Project: JBoss Naming
> Issue Type: Bug
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
>
> Cluster topology messages are not using the proper callbackhandler when the connection is being established.
> {code}
> 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
> ... 7 more
> {code}
> Before that, this log is produced:
> {code}
> DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFCORE-520) Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-520?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-520:
------------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1192181|https://bugzilla.redhat.com/show_bug.cgi?id=1192181] from NEW to POST
> Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
> --------------------------------------------------------------------------------
>
> Key: WFCORE-520
> URL: https://issues.jboss.org/browse/WFCORE-520
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: Brad Maxwell
> Assignee: Brian Stansberry
> Attachments: JMXTest.java, server.log
>
>
> A NullPointerException randomly occurs in org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) when getMBeanCount is called over and over.
> See attached server.log and reproducer
> {noformat}
> 00:16:01,315 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-2) WFLYCTL0013: Operation ("check-default-resource-access") failed - address: ([
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "-1652526387")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:1136) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:130) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:467) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:700) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:328) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:197) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:51) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:154) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:561) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months