[JBoss JIRA] (DROOLS-1741) Using a function in nested objects
by R D (JIRA)
R D created DROOLS-1741:
---------------------------
Summary: Using a function in nested objects
Key: DROOLS-1741
URL: https://issues.jboss.org/browse/DROOLS-1741
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.Final
Environment: Drools 6.5.0.Final
JDK 1.8
Reporter: R D
Assignee: Mario Fusco
Priority: Minor
Attachments: Compilation_error.PNG
I am working with a project with nested objects.
I have a rule in which I need to make use of a function. If I use this function on a variable in a nested object it does not work (I get a compilation error):
Using the nested object accessor approach (compilation error "Unable to Analyse Expression"):
ObjectA( objectB. ( (someFunction(someVariable)) == 0 ) )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-4610) Disable HTTP TRACE method by default on https
by Junier Lee (JIRA)
[ https://issues.jboss.org/browse/WFLY-4610?page=com.atlassian.jira.plugin.... ]
Junier Lee commented on WFLY-4610:
----------------------------------
Hi Support,
I do have this VA
Current Wildfly is 9.0.2 Final
This is VA that i got hit by this version
https://www.tenable.com/plugins/index.php?view=single&id=11213
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/ht tp-listener=default:read-resource
{
"outcome" => "success",
"result" => {
"allow-encoded-slash" => false,
"allow-equals-in-cookie-value" => false,
"always-set-keep-alive" => true,
"buffer-pipelined-data" => true,
"buffer-pool" => "default",
"certificate-forwarding" => false,
"decode-url" => true,
"enable-http2" => false,
"enabled" => true,
"max-buffered-request-size" => 16384,
"max-cookies" => 200,
"max-header-size" => 1048576,
"max-headers" => 200,
"max-parameters" => 1000,
"max-post-size" => 104857600L,
"no-request-timeout" => undefined,
"proxy-address-forwarding" => false,
"read-timeout" => undefined,
"receive-buffer" => undefined,
"record-request-start-time" => false,
"redirect-socket" => undefined,
"request-parse-timeout" => undefined,
"resolve-peer-address" => false,
"send-buffer" => undefined,
"socket-binding" => "http",
"tcp-backlog" => undefined,
"tcp-keep-alive" => undefined,
"url-charset" => "UTF-8",
"worker" => "default",
"write-timeout" => undefined
}
}
[standalone@localhost:9990 /]
Above i do not have any attribute to state disallowed methods for TRACE and TRACK.
How to i work around with it, since this version of mine will be Final Version and i want to have a workaround
Please assist
> Disable HTTP TRACE method by default on https
> ---------------------------------------------
>
> Key: WFLY-4610
> URL: https://issues.jboss.org/browse/WFLY-4610
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Dan Hooper
> Assignee: Stuart Douglas
>
> A vulnerability scan tool found that the HTTP TRACE method is enabled on our wildfly server. I could not find any information about disabling TRACE on wildfly. Previous versions of JBOSS had disabled TRACE by default.
> The problem seems to only exist when using HTTPS.
> I have linked to a stack overflow post about this topic.
> http://stackoverflow.com/questions/28568730/how-to-disable-trace-track-ht...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9373) Avoid HTTPSWebConnectorTestCase removing default https listener in tearDown()
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9373?page=com.atlassian.jira.plugin.... ]
Petr Kremensky updated WFLY-9373:
---------------------------------
Summary: Avoid HTTPSWebConnectorTestCase removing default https listener in tearDown() (was: Avoid HTTPSWebConnectorTestCase removing default https web connector in tearDown())
> Avoid HTTPSWebConnectorTestCase removing default https listener in tearDown()
> -----------------------------------------------------------------------------
>
> Key: WFLY-9373
> URL: https://issues.jboss.org/browse/WFLY-9373
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
>
> We see some new testsuite failures of org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase with 7.1.0.CR2 bits. This however doesn't look like the functional issue as the tests pass if run as a single test.
> The test fails during the setup phase with missing management resource:
> {noformat}
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"undertow\"),
> (\"server\" => \"default-server\"),
> (\"https-listener\" => \"https\")
> ]' not found",
> {noformat}
> I expect that some other test run prior this one cause this. Note that we no longer run the manualmode tests in alphabetic order (JBEAP-12192), that may be the answer why we didn't see this failure before.
> I'll look more into this and try to find the culprit.
> Failing tests:
> {noformat}
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatefulBeanAsync
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatefulBean
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatelessBeanAsync
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatelessBean
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9373) Avoid HTTPSWebConnectorTestCase removing default https web connector in tearDown()
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9373?page=com.atlassian.jira.plugin.... ]
Petr Kremensky moved JBEAP-13225 to WFLY-9373:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9373 (was: JBEAP-13225)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: (was: 7.1.0.CR2)
> Avoid HTTPSWebConnectorTestCase removing default https web connector in tearDown()
> ----------------------------------------------------------------------------------
>
> Key: WFLY-9373
> URL: https://issues.jboss.org/browse/WFLY-9373
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
>
> We see some new testsuite failures of org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase with 7.1.0.CR2 bits. This however doesn't look like the functional issue as the tests pass if run as a single test.
> The test fails during the setup phase with missing management resource:
> {noformat}
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"undertow\"),
> (\"server\" => \"default-server\"),
> (\"https-listener\" => \"https\")
> ]' not found",
> {noformat}
> I expect that some other test run prior this one cause this. Note that we no longer run the manualmode tests in alphabetic order (JBEAP-12192), that may be the answer why we didn't see this failure before.
> I'll look more into this and try to find the culprit.
> Failing tests:
> {noformat}
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatefulBeanAsync
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatefulBean
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatelessBeanAsync
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.testStatelessBean
> org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase.org.jboss.as.test.manualmode.ejb.ssl.SSLEJBRemoteClientTestCase
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3311:
------------------------------------------
It's possible your ConsoleHandler change bypassed the stdio gymnastics the test uses to be able to track what the output is. There may not be any way to guard against that in the test. Maybe some sort of reversal thing could work in a test; i.e. not checking that nothing appears, but rather ensuring that with a different setup something appears. If the console output is going directly to the primordial stdout/err then it wouldn't be coming through the streams the test sets up. But... I expect there are already tests like that too that didn't fail.
> embedded server --std-out=discard still causes log output to be shown
> ---------------------------------------------------------------------
>
> Key: WFCORE-3311
> URL: https://issues.jboss.org/browse/WFCORE-3311
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Ken Wills
> Assignee: James Perkins
>
> [disconnected /] embed-server --std-out=discard
> 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final
> 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting
> ... etc
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JGRP-2219) Deadlock: regression caused by ViewHandler change in 4.0.5
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2219?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2219 at 9/21/17 3:09 PM:
---------------------------------------------------------
A possible solution is to add all request to a (synchronized) queue, and make _one_ thread process that queue, by removing and processing matching requests in a loop.
h4. Pseudo code
h5. add():
{code:java}
count++; // atomic
lock
add request to queue
if --count == 0 && !processing:
return processing=true;
return false;
unlock
{code}
When add() returns true, process() is called.
h5. process()
{code:java}
loop
while(queue is not empty):
remove matching reqs and process them
lock
if( queue is empty):
processing=false, return
else
continue
unlock
end-loop
{code}
was (Author: belaban):
A possible solution is to add all request to a (synchronized) queue, and make _one_ thread process that queue, by removing and processing matching requests in a loop.
h4. Pseudo code
h5. add():
{code:java}
count++; // atomic
lock
add request to queue
if --count == 0 && !processing:
processing=true;
return processing;
unlock
{code}
When add() returns true, process() is called.
h5. process()
{code:java}
loop
while(queue is not empty):
remove matching reqs and process them
lock
if( queue is empty):
processing=false, return
else
continue
unlock
end-loop
{code}
> Deadlock: regression caused by ViewHandler change in 4.0.5
> ----------------------------------------------------------
>
> Key: JGRP-2219
> URL: https://issues.jboss.org/browse/JGRP-2219
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.7
>
>
> Deadlock caused by https://issues.jboss.org/browse/JGRP-2031:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "jgroups-temp-thread-4253,EntityCollectionInvalidationTest-NodeF-59512": waiting for ownable synchronizer 0x0000000735645138, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "TestDisconnectHandler-1"
> "TestDisconnectHandler-1": waiting to lock monitor 0x00007fdff40036f8 (object 0x00000007359182d0, a org.jgroups.protocols.pbcast.Merger), which is held by "jgroups-4,EntityCollectionInvalidationTest-NodeF-59512"
> "jgroups-4,EntityCollectionInvalidationTest-NodeF-59512": waiting for ownable synchronizer 0x0000000735645138, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "TestDisconnectHandler-1"Java stack information for the threads listed above:===================================================
> "jgroups-temp-thread-4253,EntityCollectionInvalidationTest-NodeF-59512":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0000000735645138> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jgroups.protocols.pbcast.ViewHandler.add(ViewHandler.java:92)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:841)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
> at org.jgroups.stack.Protocol.up(Protocol.java:302)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:591)
> at org.jgroups.protocols.FD.up(FD.java:250)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:276)
> at org.jgroups.protocols.Discovery.up(Discovery.java:262)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1229)
> at org.jgroups.util.SubmitToThreadPool.lambda$loopback$0(SubmitToThreadPool.java:30)
> at org.jgroups.util.SubmitToThreadPool$$Lambda$447/1407332998.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> "TestDisconnectHandler-1":
> at org.jgroups.protocols.pbcast.Merger.cancelMerge(Merger.java:431)
> - waiting to lock <0x00000007359182d0> (a org.jgroups.protocols.pbcast.Merger)
> at org.jgroups.protocols.pbcast.CoordGmsImpl.init(CoordGmsImpl.java:34)
> at org.jgroups.protocols.pbcast.GMS.becomeCoordinator(GMS.java:407)
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleMembershipChange(ParticipantGmsImpl.java:114)
> at org.jgroups.protocols.pbcast.GMS.process(GMS.java:1296)
> at org.jgroups.protocols.pbcast.GMS$$Lambda$95/1582906120.accept(Unknown Source)
> at org.jgroups.protocols.pbcast.ViewHandler.process(ViewHandler.java:173)
> at org.jgroups.protocols.pbcast.ViewHandler.add(ViewHandler.java:111)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:841)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
> at org.jgroups.stack.Protocol.up(Protocol.java:302)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:591)
> at org.jgroups.stack.Protocol.up(Protocol.java:302)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:245)
> at org.infinispan.test.hibernate.cache.util.TestDisconnectHandler.lambda$down$0(TestDisconnectHandler.java:63)
> at org.infinispan.test.hibernate.cache.util.TestDisconnectHandler$$Lambda$392/1960261368.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "jgroups-4,EntityCollectionInvalidationTest-NodeF-59512":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0000000735645138> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jgroups.protocols.pbcast.ViewHandler.resume(ViewHandler.java:140)
> at org.jgroups.protocols.pbcast.Merger.cancelMerge(Merger.java:435)
> - locked <0x00000007359182d0> (a org.jgroups.protocols.pbcast.Merger)
> at org.jgroups.protocols.pbcast.CoordGmsImpl.init(CoordGmsImpl.java:34)
> at org.jgroups.protocols.pbcast.GMS.becomeCoordinator(GMS.java:407)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:688)
> - locked <0x0000000735918798> (a org.jgroups.Membership)
> - locked <0x0000000735643d68> (a org.jgroups.protocols.pbcast.GMS)
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:135)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:918)
> at org.jgroups.stack.Protocol.up(Protocol.java:336)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:428)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:962)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndDeliver(NAKACK2.java:896)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:870)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:690)
> at org.jgroups.protocols.FD.up(FD.java:280)
> at org.jgroups.stack.Protocol.up(Protocol.java:344)
> at org.jgroups.stack.Protocol.up(Protocol.java:344)
> at org.jgroups.stack.Protocol.up(Protocol.java:344)
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1255)
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284)
> at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136)
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Found 1 deadlock.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months