[JBoss JIRA] (WFLY-8630) Tests broken as part of WildFly Core 3.0.0.Beta16
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8630:
--------------------------------------
Summary: Tests broken as part of WildFly Core 3.0.0.Beta16
Key: WFLY-8630
URL: https://issues.jboss.org/browse/WFLY-8630
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Brian Stansberry
Assignee: Darran Lofthouse
Tests shown here are going to be ignored or otherwise modified in order to get the core 3.0.0.Beta16 release integrated.
org.jboss.as.test.integration.domain.elytron.SlaveHostControllerElytronAuthenticationTestCase.testSlaveRegistration
org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule
org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule
org.jboss.as.test.integration.security.perimeter.CLISecurityTestCase.testConnect
Failure examples: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=113878&buildTy...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1535) DMN engine not checking scope of variables on DTs
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-1535:
-------------------------------------
Summary: DMN engine not checking scope of variables on DTs
Key: DROOLS-1535
URL: https://issues.jboss.org/browse/DROOLS-1535
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.0.0.CR1
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Priority: Critical
Fix For: 7.0.0.Final, 7.1.0.Final
DMN engine is not checking variables while compiling DTs and silently succeeding even if the referenced variable does not exist.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2713) Improve the WFCORE-1870 solution by accounting for ReloadRequiredAddStepHandler
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2713:
----------------------------------------
Summary: Improve the WFCORE-1870 solution by accounting for ReloadRequiredAddStepHandler
Key: WFCORE-2713
URL: https://issues.jboss.org/browse/WFCORE-2713
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
WFCORE-1870 made it easier to get correct metadata reporting whether restart was required for an add handler by assuming it was if the registration logic didn't specifically say and AbstractBoottimeAddStepHandler was the base for add OSH.
This latter bit can be expanded to cover ReloadRequiredAddStepHandler as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (HIBERNATE-154) SubqueryExpression throws NullpointerException in toSqlString(...) where getLoadQueryInfluencers() is getting null. in hibernate 3.6.9 version.
by Pramod Badatiya (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-154?page=com.atlassian.jira.plu... ]
Pramod Badatiya commented on HIBERNATE-154:
-------------------------------------------
Hi Steve,
Did we get chance to look into it.
> SubqueryExpression throws NullpointerException in toSqlString(...) where getLoadQueryInfluencers() is getting null. in hibernate 3.6.9 version.
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HIBERNATE-154
> URL: https://issues.jboss.org/browse/HIBERNATE-154
> Project: Hibernate Integration
> Issue Type: Bug
> Environment: Hibernate 3.6.9.Final
> Reporter: Santhakumar Appandairaj
> Assignee: Steve Ebersole
> Priority: Blocker
>
> We are getting below exception when I try to list some data.
> I have also tried debugging where its exactly occurring we are getting issue in the LoadqueryInflucers object is getting as null
> ~_public String toSqlString(Criteria criteria, CriteriaQuery criteriaQuery) throws HibernateException {
> SessionFactoryImplementor factory = criteriaQuery.getFactory();
> OuterJoinLoadable persister = (OuterJoinLoadable) factory
> .getEntityPersister(this.criteriaImpl.getEntityOrClassName());
> createAndSetInnerQuery(criteriaQuery, factory);
> this.criteriaImpl.setSession(deriveRootSession(criteria));
> CriteriaJoinWalker walker = new CriteriaJoinWalker(persister, this.innerQuery, factory, this.criteriaImpl,
> this.criteriaImpl.getEntityOrClassName(), this.criteriaImpl.getSession().getLoadQueryInfluencers(),
> this.innerQuery.getRootSQLALias());_~
> *Exception*
> Caused by: java.lang.NullPointerException
> at org.hibernate.criterion.SubqueryExpression.toSqlString(SubqueryExpression.java:72)
> at org.hibernate.criterion.LogicalExpression.toSqlString(LogicalExpression.java:62)
> at org.hibernate.criterion.Junction.toSqlString(Junction.java:82)
> at org.hibernate.loader.criteria.CriteriaQueryTranslator.getWhereCondition(CriteriaQueryTranslator.java:380)
> at org.hibernate.loader.criteria.CriteriaJoinWalker.<init>(CriteriaJoinWalker.java:102)
> at org.hibernate.loader.criteria.CriteriaJoinWalker.<init>(CriteriaJoinWalker.java:82)
> at org.hibernate.loader.criteria.CriteriaLoader.<init>(CriteriaLoader.java:92)
> Can any of you please check and let me know.
> We are trying to upgrade hibernate and other 3rd party jar upgrade
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8617) Distributed workmanager fails to obtain view
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8617?page=com.atlassian.jira.plugin.... ]
Kabir Khan resolved WFLY-8617.
------------------------------
Fix Version/s: 11.0.0.Beta1
Resolution: Done
> Distributed workmanager fails to obtain view
> --------------------------------------------
>
> Key: WFLY-8617
> URL: https://issues.jboss.org/browse/WFLY-8617
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Priority: Critical
> Labels: KK-DR17
> Fix For: 11.0.0.Beta1
>
>
> When starting two EAP instances with a distributed workmanager configured, the following exception is logged on the first instance ~6 seconds after the second instance starts:
> {code}
> 16:11:24,204 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started in 5905ms - Started 467 of 700 services (472 services are lazy, passive or on-demand)
> 16:11:42,066 ERROR [org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport] (thread-2) ViewAccepted: org.jgroups.TimeoutException: timeout waiting for response from node2, request: UnicastRequest, mode=GET_ALL, target=node2: javax.resource.spi.work.WorkException: org.jgroups.TimeoutException: timeout waiting for response from node2, request: UnicastRequest, mode=GET_ALL, target=node2
> at org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport.sendMessage(JGroupsTransport.java:589)
> at org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport.viewAccepted(JGroupsTransport.java:943)
> at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:618)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:666)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:124)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:118)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:727)
> at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:225)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:917)
> at org.jgroups.stack.Protocol.up(Protocol.java:418)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:487)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:989)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:919)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:851)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:611)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> at org.jgroups.protocols.TP$3.run(TP.java:1591)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jgroups.TimeoutException: timeout waiting for response from node2, request: UnicastRequest, mode=GET_ALL, target=node2
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:442)
> at org.jgroups.blocks.RpcDispatcher.callRemoteMethod(RpcDispatcher.java:241)
> at org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport.sendMessage(JGroupsTransport.java:579)
> ... 31 more
> {code}
> Judging by the stacktrace, it looks like a view of both of the wms is never created and the two workmanagers never manage to communicate with each other. That would also explain why it looks like work is never done on a different node than where it's scheduled (even though there are proper selector and policy settings). I'll file another issue for that where I'll add a reproducing test.
> Since it's a timeout exception, I've been trying to find out if the error is on my end (network issues), but it doesn't look like that - common clustering sessions, which use the JGroups stack too, are replicated properly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8618) BootstrapContext wasn't found when reloading server with distributed workmanager
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8618?page=com.atlassian.jira.plugin.... ]
Kabir Khan resolved WFLY-8618.
------------------------------
Fix Version/s: 11.0.0.Beta1
Resolution: Done
> BootstrapContext wasn't found when reloading server with distributed workmanager
> --------------------------------------------------------------------------------
>
> Key: WFLY-8618
> URL: https://issues.jboss.org/browse/WFLY-8618
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Labels: KK-DR17
> Fix For: 11.0.0.Beta1
>
>
> On single node, set up distributed workmanager:
> {code}
> /subsystem=jca/distributed-workmanager=newdwm:add(name=newdwm)
> /subsystem=jca/distributed-workmanager=newdwm/short-running-threads=newdwm:add(queue-length=10,max-threads=10)
> /subsystem=jca/bootstrap-context=customContext1:add(name=customContext1,workmanager=newdwm)
> run-batch
> reload
> {code}
> We should now have our distributed workmanager correctly linked with the {{customContext1}}. When we now deploy the {{dwmtest.ear}} (attached, same as in JBEAP-9422), everything is OK and we can access the admin objects, schedule work, etc.
> However, when the server is reloaded or restarted, the deployment fails and the following exception is thrown:
> {code}
> 15:03:59,758 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 67) MSC000001: Failed to start service jboss.ra.deployer."dwmtest.ear#dwm.rar": org.jboss.msc.service.StartException in service jboss.ra.deployer."dwmtest.ear#dwm.rar": WFLYJCA0046: Failed to start RA deployment [dwmtest.ear#dwm.rar]
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$1.run(ResourceAdapterDeploymentService.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020051: Unable to start org.jboss.as.test.integration.jca.rar.DistributedResourceAdapter1
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.startContext(AbstractResourceAdapterDeployer.java:343)
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2009)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$WildFLyRaDeployer.doDeploy(ResourceAdapterDeploymentService.java:226)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:124)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: The BootstrapContext couldn't be created: customContext1
> at org.jboss.jca.core.bootstrapcontext.BootstrapContextCoordinator.createBootstrapContext(BootstrapContextCoordinator.java:215)
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.startContext(AbstractResourceAdapterDeployer.java:331)
> ... 8 more
> Caused by: java.lang.IllegalArgumentException: The BootstrapContext wasn't found: customContext1
> at org.jboss.jca.core.bootstrapcontext.BootstrapContextCoordinator.createBootstrapContext(BootstrapContextCoordinator.java:196)
> ... 9 more
> {code}
> If {{dwmtest.ear}} is deployed without first setting up {{customContext1}}, the exact same exception is thrown (though it is expected and valid in that case).
> Note that the attached deployment requires the context to be {{customContext1}} as defined in its {{ironjacamar.xml}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years