[JBoss JIRA] (WFLY-4349) SEVERE JSF error on undeploy of WS module after Mojarra upgrade to 2.2.10
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4349?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-4349:
-----------------------------
Affects Version/s: 9.0.0.Alpha1
(was: 9.0.0.Beta1)
> SEVERE JSF error on undeploy of WS module after Mojarra upgrade to 2.2.10
> -------------------------------------------------------------------------
>
> Key: WFLY-4349
> URL: https://issues.jboss.org/browse/WFLY-4349
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 9.0.0.Alpha1
> Environment: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha18)
> Oracle JDK 1.7.0_80-ea-b05, Solaris SPARC 10
> Reporter: Frank Langelage
> Assignee: Farah Juma
> Labels: mojarra, undertow
>
> Since latest update I get a SEVERE entry in server.log for every web-module getting undeployed. Those Web-modules contain webservices and are war files inside and ear.
> 15.02. 21:31:48,151 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/production
> 15.02. 21:31:48,151 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi/maj2e-langfr-dev/web
> 15.02. 21:31:48,155 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,201 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/planning
> 15.02. 21:31:48,204 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,239 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,217 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/core
> 15.02. 21:31:48,359 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/sales
> 15.02. 21:31:48,372 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/costing
> 15.02. 21:31:48,379 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/purchase
> 15.02. 21:31:48,381 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,383 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/external
> 15.02. 21:31:48,396 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,397 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,399 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,402 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/inventory
> 15.02. 21:31:48,444 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,404 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/common
> 15.02. 21:31:48,407 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/distribution
> 15.02. 21:31:48,408 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,480 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> Undeploy of my war file does not generate this SEVERE error.
> 15.02. 21:43:24,243 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /web-maj2e-langfr-dev
> When I go back to the previous Mojarra 2.2.9-jbossorg-2 the error message disappears.
> There are also a lot of theses SEVERE error messages in the testsuite output files (*.txt).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFCORE-566) space- and comma-separated attribute marshaller are broken
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFCORE-566:
----------------------------------
Summary: space- and comma-separated attribute marshaller are broken
Key: WFCORE-566
URL: https://issues.jboss.org/browse/WFCORE-566
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Alpha19
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 1.0.0.Beta1
The AttributeMarshaller's STRING_LIST and COMMA_STRING_LIST are broken as they override marshallAsElement while it's their marshallAsAttribute method (inherited from DefaultAttributeMarshaller) that is called.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFCORE-565) StaticDiscoveryResourceDefinition allows undefined values for its attributes
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-565:
---------------------------------------
Summary: StaticDiscoveryResourceDefinition allows undefined values for its attributes
Key: WFCORE-565
URL: https://issues.jboss.org/browse/WFCORE-565
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
StaticDiscoveryResourceDefinition reuses the AttributeDefinitions from RemoteDomainControllerAddHandler, but those ADs allow undefined. That's appropriate for that OSH, but not for the StaticDiscoveryResourceDefinition ADs.
Also, the RemoteDomainControllerAddHandler AD's could use some clarification and validation as well, e.g. use setRequires(...) on the builder such that each of protocol, host, port requires the other two. So none are required, but if any is set all 3 must be.
The StaticDiscovery constructor should validate inputs with assert statements and javadoc its parameters, include whether null is allowed. (A null protocol or host will result in an IAE in discover(), so the current code does not support null.)
The DiscoveryOption interface should document whether the 3 "get" methods can return null.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (DROOLS-707) NullPointer when changing order of the rules
by Francesco Peloi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-707?page=com.atlassian.jira.plugin... ]
Francesco Peloi commented on DROOLS-707:
----------------------------------------
Thank you very much Mario! Will save a lot of confusion in my team :)
> NullPointer when changing order of the rules
> --------------------------------------------
>
> Key: DROOLS-707
> URL: https://issues.jboss.org/browse/DROOLS-707
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
> Reporter: Francesco Peloi
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final
>
>
> Hi there,
> we are having some serious issues with some rules, they are throwing a NullPointerException and we don't understand why. I have tried to narrow down the problem to the smallest rule possible, now this rule doesn't really make much sense put like this but the real rule is more complex with more constraints. At the end the result is the same: a NPE.
> I have tried it with many Drools versions from 5.x to latest 6.3.0-SNAPSHOT.
> I tested this in isolation with the minimum amount of code possible, and attached it as well if someone wants to try it quickly.
> Note that if line 2 of the when:
> $a : Integer()
> is moved as first line, the rule runs ok.
> Please find the reproducer here: https://groups.google.com/forum/#!topic/drools-usage/-oNqu3l4cqE
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1908:
--------------------------------
Any progress ? I want to release 3.6.3 soon, and I'd rather not have to push this into 3.6.x or 4.0
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.3
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[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
> 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
> Fix For: 9.0.0.Beta1
>
>
> 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)
9 years, 1 month
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1910:
--------------------------------
OK, fixed in JGRP-1876.
The optimization was to include *all* coordinators of subclusters, even if they didn't send an {{INFO}} message in {{MERGE3}}.
To disable the optimization, set {{GMS.use_merger2}} to {{false}} (default: {{true}}).
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFLY-67) method-params containing an array not correctly processed for EJB2.1 with CMT
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-67?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration commented on WFLY-67:
---------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1180565|https://bugzilla.redhat.com/show_bug.cgi?id=1180565] from NEW to POST
> method-params containing an array not correctly processed for EJB2.1 with CMT
> -----------------------------------------------------------------------------
>
> Key: WFLY-67
> URL: https://issues.jboss.org/browse/WFLY-67
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09
> Reporter: Robert Panzer
> Assignee: Ondrej Zizka
> Fix For: 8.0.0.Alpha1
>
> Attachments: cmt-never-array-params.zip
>
>
> It seems that the method-params for container transactions are not matched correctly if the contain arrays.
> I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]);
> If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with
> JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6)
> I define the container transaction like this:
> <container-transaction>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String[]</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>int</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>Second</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> </method>
> <trans-attribute>Never</trans-attribute>
> </container-transaction>
> I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFLY-4385) Authentication is not propagated to EJB in the login request
by Paulo Cesar Silva Reis (JIRA)
[ https://issues.jboss.org/browse/WFLY-4385?page=com.atlassian.jira.plugin.... ]
Paulo Cesar Silva Reis updated WFLY-4385:
-----------------------------------------
Attachment: wildfly-4385.zip
Follow what you've requested.
Please, run setup.groovy to configure datasource, security, install mysql module etc.
Sorry but I've tried to make it really easy for you to run, I hope it helps.
After that, you must invoke the follow url: http://localhost:8080/login
The server will print the principal from request and ejb and then the same information should return to you as JSON but you will see this instead:
{"httpRequestPrincipal":"test","ejbCallerPrincipal":"anonymous"}
If I remove AuthBusiness and perform the login directly in the REST Resource class, ejb context is aware of the principal, but as Im using another EJB to do the login job, things get ugly!!
Let me know if you have any doubt.
Thanks in advance!
> Authentication is not propagated to EJB in the login request
> ------------------------------------------------------------
>
> Key: WFLY-4385
> URL: https://issues.jboss.org/browse/WFLY-4385
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Environment: MAC OSX YOSEMITE
> JAVA ORACLE 1.8
> WILDFLY 8.2.0.FINAL STANDALONE
> Reporter: Paulo Cesar Silva Reis
> Assignee: Darran Lofthouse
> Labels: authentication, ejb, http, login, roles, web
> Attachments: wildfly-4385.zip
>
>
> I'm migrating from glassfish to wildfly and noticed few weird things.
> When you perform login through web container (request.login(user, pwd)), the principal is not propagated to EJB Container, only for web container.
> To test that, this is what I did:
> . BASIC AUTH
> . EJB receives HttpServletRequest with user data and perform login
> . Print request.getUserPrincipal() => ok, logged in
> . Print EJBContext.getCallerPrincipal() => anonymous
> This happens in the same request that user logged in. In the subsequent requests (using Set-Cookie response and cookie with JSESSIONID in request), the EJB is aware of the authentication.
> Is that the right behavior? 'Cause in glassfish is different, the principal is propagated immediately to EJB.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month