[JBoss JIRA] (DROOLS-1044) KieBase 'includes' does not handle the inclusion of KieBases that use the same package-names correctly.
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-1044:
------------------------------------
Summary: KieBase 'includes' does not handle the inclusion of KieBases that use the same package-names correctly.
Key: DROOLS-1044
URL: https://issues.jboss.org/browse/DROOLS-1044
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Beta1
Environment: Mac OS X 10.11.3, Oracle Hotspot 1.8.0_45
Reporter: Duncan Doyle
Assignee: Mario Fusco
KieBase 'includes' does not handle the inclusion of KieBases that use the same package-names correctly.
I define 2 KJARs, each with a kmodule.xml that defines a KieBase. KJAR1 has a dependency on KJAR2 in its pom.xml.
The KieBase defined in KJAR1 includes the KieBase defined in KJAR2.
If the KieBases get their Drools Resources (e.g. .drl) from different packages (e.g. 'rules' and 'rules2', everything works fine, e.g.:
KJAR1 kmodule.xml:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
<kbase name="kbase1" equalsBehavior="equality" default="true" packages="rules" includes="kbase2">
<ksession name="ksession1" default="true" type="stateful"/>
</kbase>
</kmodule>
{code}
KAJR2 kmodule.xml:
{code:xml}
<kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
<kbase name="kbase2" equalsBehavior="equality" default="false" packages="rules2">
<ksession name="ksession2" default="false" type="stateful"/>
</kbase>
</kmodule>
{code}
However, when both KieBases use the same "packages" name (e.g. 'rules'), only one of the resources gets included in the final KieBase.
KJAR1 kmodule.xml:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
<kbase name="kbase1" equalsBehavior="equality" default="true" packages="rules" includes="kbase2">
<ksession name="ksession1" default="true" type="stateful"/>
</kbase>
</kmodule>
{code}
KAJR2 kmodule.xml:
{code:xml}
<kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
<kbase name="kbase2" equalsBehavior="equality" default="false" packages="rules">
<ksession name="ksession2" default="false" type="stateful"/>
</kbase>
</kmodule>
{code}
Unit tests with reproducer can be found here: https://github.com/DuncanDoyle/drools-kiebase-include-issue
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-6083:
----------------------------------
Summary: Removing of non-existent login-module finishes with outcome success
Key: WFLY-6083
URL: https://issues.jboss.org/browse/WFLY-6083
Project: WildFly
Issue Type: Bug
Components: CLI
Reporter: Ondrej Lukas
Assignee: Alexey Loubyansky
Priority: Minor
In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6082) NullPointerException on jar fetch from server by client
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-6082?page=com.atlassian.jira.plugin.... ]
George Turner commented on WFLY-6082:
-------------------------------------
Should? Please provide a JIRA? Will it be in 10 Final?
> NullPointerException on jar fetch from server by client
> -------------------------------------------------------
>
> Key: WFLY-6082
> URL: https://issues.jboss.org/browse/WFLY-6082
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Environment: RedHat 7 server
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> Reporter: George Turner
> Assignee: Stuart Douglas
>
> JNLP client requests is jars and this error is thrown for all requests, but the client successfully retrieves the jar(s)
> 2016-01-27 11:16:10,549 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /premiereclient/plugins/org.eclipse.swt.win32.win32.x86_64_3.103.2.v20150203-1351.jar: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.transferFrom(HttpResponseConduit.java:664)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.transferFrom(AbstractFixedLengthStreamSinkConduit.java:193)
> at org.xnio.conduits.ConduitStreamSinkChannel.transferFrom(ConduitStreamSinkChannel.java:142)
> at io.undertow.channels.DetachableStreamSinkChannel.transferFrom(DetachableStreamSinkChannel.java:127)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.transferFrom(HttpServerExchange.java:1951)
> at org.xnio.channels.Channels.transferBlocking(Channels.java:512)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.transferFrom(ServletOutputStreamImpl.java:528)
> at io.undertow.io.BlockingSenderImpl.performTransfer(BlockingSenderImpl.java:142)
> at io.undertow.io.BlockingSenderImpl.transferFrom(BlockingSenderImpl.java:135)
> at io.undertow.server.handlers.resource.PathResource$1TransferTask.run(PathResource.java:217)
> at io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:247)
> at io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:105)
> at org.wildfly.extension.undertow.deployment.ServletResource.serve(ServletResource.java:95)
> at io.undertow.server.handlers.resource.CachedResource.serve(CachedResource.java:168)
> at io.undertow.servlet.handlers.DefaultServlet.serveFileBlocking(DefaultServlet.java:358)
> at io.undertow.servlet.handlers.DefaultServlet.doGet(DefaultServlet.java:180)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> I can access the URL with a browser and see the list of the files using:
> http://localhost:8080/premiereclient/plugins/
> which is the same path shown in the error
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6056) Session.invalidate() exception with OPTIMISTIC cache configuration
by Juan AMAT (JIRA)
[ https://issues.jboss.org/browse/WFLY-6056?page=com.atlassian.jira.plugin.... ]
Juan AMAT commented on WFLY-6056:
---------------------------------
I guess that I must trust you on this one as I read the 'duplicate' ticket and I am not sure if I follow everything.
> Session.invalidate() exception with OPTIMISTIC cache configuration
> ------------------------------------------------------------------
>
> Key: WFLY-6056
> URL: https://issues.jboss.org/browse/WFLY-6056
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Juan AMAT
> Assignee: Paul Ferraro
>
> We have an application that must handle 'long' async requests and regular requests at the same time.
> We have the same problem as described here: https://developer.jboss.org/thread/254200
> If I use the configuration that is described in this discussion:
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <transaction locking="OPTIMISTIC"/>
> <locking isolation="READ_COMMITTED"/>
> <file-store/>
> </replicated-cache>
> then everything is fine until I call session.invalidate(). In this case I get an exception:
> Caused by: java.lang.UnsupportedOperationException: Calling lock() on non-transactional caches is not allowed
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:820)
> at org.infinispan.cache.impl.DecoratedCache.lock(DecoratedCache.java:136)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:124)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:89)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:67)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:439)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:181)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> Now I modify the configuration and specify <transaction mode="BATCH" locking="OPTIMISTIC"/>, I do get another exception:
> Caused by: org.infinispan.InvalidCacheUsageException: Explicit locking is not allowed with optimistic caches!
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitLockControlCommand(OptimisticLockingInterceptor.java:142)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
> at org.infinispan.cache.impl.DecoratedCache.lock(DecoratedCache.java:136)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:124)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:89)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:67)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:439)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:181)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> Is there some other configuration that I should use?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6071) Mixed domain test suite should test using the legacy domain.xml files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6071?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6071:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/8618
> Mixed domain test suite should test using the legacy domain.xml files
> ---------------------------------------------------------------------
>
> Key: WFLY-6071
> URL: https://issues.jboss.org/browse/WFLY-6071
> Project: WildFly
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The mixed domain testsuite is doing a lot of testing starting with the current release standard configs, then manipulating to get to something interoperable, and then launching a slave.
> This is fine, but we need explicit coverage of the primary use case: take a config that worked in the legacy release, install it on the DC, and then have the slave start, confirming that the slave was able to join.
> This is basically what users will do -- take profiles that worked and try and use them with a current DC and legacy slaves. Trying to take new profiles and adapt them to work on legacy slaves is more of a corner case. And testing that corner case as the primary coverage leads to holes, where the "correction" logic ends up hiding problems that shouldn't be hidden, e.g. WFCORE-1311.
> So, for each legacy release we should boot the current DC with the standard domain.xml for that release and then start a legacy slave from that release.
> We may need to apply some correction here too, but if we do it's a good opportunity to check why it's necessary, and whether a more user-friendly solution can be found.
> That's not 100% coverage as there are things that weren't in our standard domain.xml, but it's a good smoke test. Subsystem specific test suites can check for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months