[JBoss JIRA] (DROOLS-115) Add support for strong negation
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-115?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-115:
------------------------------------------
Fix Version/s: 6.1.0.CR1
(was: 6.1.0.Beta4)
> Add support for strong negation
> -------------------------------
>
> Key: DROOLS-115
> URL: https://issues.jboss.org/browse/DROOLS-115
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Minor
> Fix For: 6.1.0.CR1
>
>
> Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...".
> However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..."
> It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT.
> The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as:
> when $p : Person() and Car( owner == $p ) then
> // a positive, matching Car is present in the WM
> when $p : Person() and neg Car( owner == $p ) then
> // a negative, matching Car is present in the WM
> when $p : Person() and not Car( owner == $p ) then
> // neither a positive nor a negative fact exists in the WM
> For a more detailed description and motivation see e.g.:
> https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-432) Types declared in a foreign package are processed one at a time
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-432?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-432:
------------------------------------------
Fix Version/s: 6.1.0.CR1
(was: 6.1.0.Beta4)
> Types declared in a foreign package are processed one at a time
> ---------------------------------------------------------------
>
> Key: DROOLS-432
> URL: https://issues.jboss.org/browse/DROOLS-432
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.1.Final
> Reporter: Davide Sottara
> Assignee: Mark Proctor
> Fix For: 6.1.0.CR1
>
>
> The following snippet has two issues
> {code}
> package a;
> declare b.X field : b.Y end
> declare b.Y end
> {code}
> While processing package a, the packageBuilder will infer the existence of package b and create the appropriate typeDeclarations.
> However, a partial, independent package b is created for X and Y:
> - it is inefficient
> - internal dependencies cannot be resolved : b.X does not (yet) see b.Y
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3185) Strip cluster name from node names
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3185?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-3185:
------------------------------------
Including the cluster name in the node name will become especially redundant when we integrate fork channels and allow each cache container to share the same channel.
> Strip cluster name from node names
> ----------------------------------
>
> Key: WFLY-3185
> URL: https://issues.jboss.org/browse/WFLY-3185
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.CR1
>
>
> Currently, we generate cluster node names using the following format:
> node-name/cluster-name
> Including the cluster-name in the node name is redundant and only serves to add unnecessary bytes to messages.
> We just need to make sure to include the cluster name in any log messages that refer to the node name.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-2369) request.getSession() throws IllegalStateException in distributable webapp
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-2369?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-2369:
------------------------------------
Just to say, stuff like this can happen in 8.0.0 when using asynchronous replication (the default) if the load balancer does not use session affinity. In 8.1.0 we force locking on infinispan cache reads which should prevent this issue.
> request.getSession() throws IllegalStateException in distributable webapp
> -------------------------------------------------------------------------
>
> Key: WFLY-2369
> URL: https://issues.jboss.org/browse/WFLY-2369
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Jonathan Fuerth
> Assignee: Paul Ferraro
>
> A webapp I'm working is experiencing an IllegalStateException from calling the no-args request.getSession() method. The app has the <distributable/> marker in its web.xml. Taking <distributable/> out makes this issue go away.
> Here is the stack trace:
> {code}
> 17:29:05,728 DEBUG [org.uberfire.security.server.UberFireSecurityFilter] (default task-1) Authentication failure. Sending HTTP 401 response.: org.uberfire.security.auth.AuthenticationException: Validation fails.
> at org.uberfire.security.server.HttpSecurityManagerImpl.authenticate(HttpSecurityManagerImpl.java:220) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> at org.uberfire.security.server.UberFireSecurityFilter.authenticate(UberFireSecurityFilter.java:333) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> at org.uberfire.security.server.UberFireSecurityFilter.doFilter(UberFireSecurityFilter.java:277) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException: UT000028: Session Q2FoOHf4ij6rcxT6v_9WsBOG already exists
> at org.wildfly.clustering.web.undertow.session.SessionManagerAdapter.createSession(SessionManagerAdapter.java:98)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:680) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:340) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:345) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> at org.uberfire.security.server.auth.HttpSessionStorage.load(HttpSessionStorage.java:36) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> at org.uberfire.security.server.auth.HttpAuthenticationManager.authenticate(HttpAuthenticationManager.java:87) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> at org.uberfire.security.server.HttpSecurityManagerImpl.authenticate(HttpSecurityManagerImpl.java:216) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> ... 25 more
> {code}
> In case you need to see it, the source code for the app that generated this trace is at https://github.com/jfuerth/errai-cdi-workbench/tree/11794888a873ae7182524...
> For completeness, the snapshot versions of its dependencies come from these git commits in the respective projects.
> * Errai: bd130e238ed39a90d513e366336b0e20b8761146
> * UberFire: 3756076ce8005ba1b0cbab6745b5d274c97d56d8
> If you need to dig this deep, please ping me. I'm happy to help :)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3175) Create non-clustered implementations of org.wildfly.clustering.api services
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3175?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3175:
-------------------------------
Fix Version/s: 9.0.0.Alpha1
(was: 9.0.0.CR1)
> Create non-clustered implementations of org.wildfly.clustering.api services
> ---------------------------------------------------------------------------
>
> Key: WFLY-3175
> URL: https://issues.jboss.org/browse/WFLY-3175
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Alpha1
>
>
> There are several reasons to do this:
> * The implementations are very simple
> * An application that uses the public clustering api will can still deploy and function in a non-clustered environment
> * We no longer need to use OPTIONAL dependencies in the web and ejb clustering layers
> The clustering services would now be installed from a DUP within the infinispan subsystem instead of the jgroups subsystem.
> If a cache container defines a transport, then the clustered version of the channel-based service is installed, otherwise the local version will be installed.
> If a cache is clustered, then the clustered version of the cache-based services is installed, otherwise a local version will be installed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3180) OOMs are still possible when using clustered web sessions/SFSBs w/passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3180?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3180:
-------------------------------
Fix Version/s: 9.0.0.Alpha1
(was: 9.0.0.CR1)
> OOMs are still possible when using clustered web sessions/SFSBs w/passivation
> -----------------------------------------------------------------------------
>
> Key: WFLY-3180
> URL: https://issues.jboss.org/browse/WFLY-3180
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Alpha1
>
>
> Currently, the owner of a web session or SFSB is responsible for schedule passivation. Unfortunately, much to my surprise, infinispan eviction commands are not broadcasted to the cluster, but are local-only. Consequently, the number of cache entries stored in memory can grow beyond the configured passivation limits, since remote copies of old cache entries are never evicted.
> To fix this, we can use the CommandDispatcher to manually broadcast eviction commands to the cluster.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3345:
-------------------------------
Fix Version/s: 8.1.0.Final
9.0.0.Alpha1
> Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows
> ----------------------------------------------------------------------
>
> Key: WFLY-3345
> URL: https://issues.jboss.org/browse/WFLY-3345
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Paul Ferraro
> Fix For: 8.1.0.Final, 9.0.0.Alpha1
>
>
> In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error:
> {code}
> [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month