[JBoss JIRA] Created: (JBRULES-2959) Eclipse Guided Editor and DSL sentences
by Vincent Legendre (JIRA)
Eclipse Guided Editor and DSL sentences
---------------------------------------
Key: JBRULES-2959
URL: https://issues.jboss.org/browse/JBRULES-2959
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-eclipse
Affects Versions: 5.2.0.M1
Reporter: Vincent Legendre
Assignee: Mark Proctor
Guided Editor under Eclipse (new/Drools/Guided Rule or rule got from Guvnor) does not handle DSL sentences properly :
*1* Eclipse complains about syntax error for BRL rules ("no viable alternative..."), because DRL is not correctly generated (in the DRL view, DSL are not translated), but the rule has no error when added to a KB and executes well...
*2* Can't select consequences from DSL in "new action" dialog box. When the rule comes from Guvnor, the action part is correctly displayed, and inputs can be changed (with comobox for enums etc etc...), but you can't remove the action nor add a new one. You can also achieve the same by editing the XML directly.
*3* In conditions, a DSL sentence that have more than one placeholder is not correctly displayed : Only one input field is displayed, at first placeholder location, and no button to delete the condition... When you close the editor and re-open the brl file, the condition is correctly displayed ...
I read somewhere that BRL will be deprecated (soon?) to use ruleml. But as the editor can display rules that comes from guvnor, and already has a DSL sentence selector in condition box, these fix should not be so hard to do ?
The really critical one is the compilation error when there are no error ... If you have to bring back some rules from Guvnor (for dev team to debug), and if there are many of them, you get plenty of error messages.
Example :
{code:title=The DSL file}
[consequence][]Add alert {type:ENUM:Alert.severity} '{message}' on object {errObj}=new Alert(Alert.{type}, "{message}", {errObj});
[condition][]Counter with value greater than {x} -> {varObj}={varObj} : Counter(value >= {x})
{code}
{code:xml|title=The Guided rule BRL source (edited by Guvnor)}
<rule>
<name>TestGuided</name>
<modelVersion>1.0</modelVersion>
<attributes/>
<metadataList/>
<lhs>
<dslSentence>
<sentence>Counter with value greater than {123} -> {$c}</sentence>
</dslSentence>
</lhs>
<rhs>
<dslSentence>
<sentence>Add alert {ERROR:ENUM:Alert.severity} '{blah}' on object {$c}</sentence>
</dslSentence>
</rhs>
</rule>
{code}
{code:title=enumeration}
'Alert.severity' : ['FATAL','ERROR','WARN','INFO','DEBUG']
{code}
{code:title=POJO java}
public class Counter {
private double value; // with its set/get
}
public class Alert {
public static final int FATAL = 0;
public static final int ERROR = 1;
public static final int WARN = 2;
public static final int INFO = 3;
public static final int DEBUG = 4;
private int severity;
private String message;
private Object errObj;
public Alert(int severity, String message, Object errObj) {
this.severity = severity;
this.message = message;
this.errObj = errObj;
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBAS-9241) Test Hang in org.jboss.as.controller.test.ExistingConnectionRemoteProxyControllerTestCase
by Andrew Rubinger (JIRA)
Test Hang in org.jboss.as.controller.test.ExistingConnectionRemoteProxyControllerTestCase
-----------------------------------------------------------------------------------------
Key: JBAS-9241
URL: https://issues.jboss.org/browse/JBAS-9241
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Andrew Rubinger
Console Output:
{code}Running org.jboss.as.controller.test.ExistingConnectionRemoteProxyControllerTestCase
connected
connected
connected
Apr 5, 2011 2:26:03 PM org.jboss.as.protocol.ConnectionImpl safeHandleMessage
ERROR: Failed to read a message
java.io.EOFException: Read past end of file
at org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:126)
at org.jboss.marshalling.SimpleDataInput.readByte(SimpleDataInput.java:214)
at org.jboss.as.protocol.SimpleByteDataInput.readByte(SimpleByteDataInput.java:80)
at org.jboss.as.protocol.mgmt.ManagementRequestHeader.read(ManagementRequestHeader.java:67)
at org.jboss.as.protocol.mgmt.ManagementProtocolHeader.<init>(ManagementProtocolHeader.java:55)
at org.jboss.as.protocol.mgmt.ManagementRequestHeader.<init>(ManagementRequestHeader.java:47)
at org.jboss.as.protocol.mgmt.ManagementHeaderMessageHandler.handle(ManagementHeaderMessageHandler.java:53)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:59)
at org.jboss.as.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:254)
at org.jboss.as.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:213)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662){code}
Leads to:
{code}[alr@alr-laptop ~]$ jstack 3449
2011-04-05 14:36:22
Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode):
"Attach Listener" daemon prio=10 tid=0x00007fd978001000 nid=0xe52 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Read thread for /127.0.0.1:38909" prio=10 tid=0x00007fd960005800 nid=0xd94 runnable [0x00007fd996890000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at org.jboss.as.protocol.ConnectionImpl$1.run(ConnectionImpl.java:183)
at java.lang.Thread.run(Thread.java:662)
"Read thread for localhost/127.0.0.1:36386" prio=10 tid=0x00007fd9a0130800 nid=0xd93 runnable [0x00007fd996991000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at org.jboss.as.protocol.ConnectionImpl$1.run(ConnectionImpl.java:183)
at java.lang.Thread.run(Thread.java:662)
"Accept thread" prio=10 tid=0x00007fd9a028b800 nid=0xd92 runnable [0x00007fd99749c000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
- locked <0x00000000ebca89d8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at org.jboss.as.protocol.ProtocolServer$1.run(ProtocolServer.java:82)
at java.lang.Thread.run(Thread.java:662)
"Read thread for /127.0.0.1:53094" prio=10 tid=0x00007fd960004000 nid=0xd8e runnable [0x00007fd996d95000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at org.jboss.as.protocol.ConnectionImpl$1.run(ConnectionImpl.java:183)
at java.lang.Thread.run(Thread.java:662)
"Read thread for localhost/127.0.0.1:37444" prio=10 tid=0x00007fd9a0294000 nid=0xd8d runnable [0x00007fd996e96000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at org.jboss.as.protocol.ConnectionImpl$1.run(ConnectionImpl.java:183)
at java.lang.Thread.run(Thread.java:662)
"Read thread for /127.0.0.1:37638" prio=10 tid=0x00007fd960003000 nid=0xd88 runnable [0x00007fd99729a000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at org.jboss.as.protocol.ConnectionImpl$1.run(ConnectionImpl.java:183)
at java.lang.Thread.run(Thread.java:662)
"Read thread for localhost/127.0.0.1:51154" prio=10 tid=0x00007fd9a0290800 nid=0xd87 runnable [0x00007fd99739b000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at org.jboss.as.protocol.ConnectionImpl$1.run(ConnectionImpl.java:183)
at java.lang.Thread.run(Thread.java:662)
"Low Memory Detector" daemon prio=10 tid=0x00007fd9a00b3800 nid=0xd84 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread1" daemon prio=10 tid=0x00007fd9a00b1800 nid=0xd83 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread0" daemon prio=10 tid=0x00007fd9a00af000 nid=0xd82 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x00007fd9a00ac800 nid=0xd81 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=10 tid=0x00007fd9a0090000 nid=0xd80 in Object.wait() [0x00007fd997bfa000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000eca41088> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <0x00000000eca41088> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x00007fd9a008e000 nid=0xd7f in Object.wait() [0x00007fd997cfb000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000eca080f0> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x00000000eca080f0> (a java.lang.ref.Reference$Lock)
"main" prio=10 tid=0x00007fd9a0007000 nid=0xd7b in Object.wait() [0x00007fd9a416e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000ebcb5d28> (a org.jboss.as.protocol.mgmt.ManagementRequest$ResponseFuture)
at java.lang.Object.wait(Object.java:485)
at org.jboss.as.protocol.mgmt.ManagementRequest$ResponseFuture.get(ManagementRequest.java:283)
- locked <0x00000000ebcb5d28> (a org.jboss.as.protocol.mgmt.ManagementRequest$ResponseFuture)
at org.jboss.as.protocol.mgmt.ManagementRequest.executeForResult(ManagementRequest.java:111)
at org.jboss.as.controller.client.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:122)
at org.jboss.as.controller.remote.ModelControllerClientToModelControllerAdapter.execute(ModelControllerClientToModelControllerAdapter.java:73)
at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:90)
at org.jboss.as.controller.test.ExistingConnectionRemoteProxyControllerTestCase$DelegatingProxyController.execute(ExistingConnectionRemoteProxyControllerTestCase.java:171)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$4.addDescription(GlobalOperationHandlers.java:552)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$4.execute(GlobalOperationHandlers.java:490)
at org.jboss.as.controller.BasicModelController.doExecute(BasicModelController.java:366)
at org.jboss.as.controller.BasicModelController.execute(BasicModelController.java:259)
at org.jboss.as.controller.BasicModelController.execute(BasicModelController.java:216)
at org.jboss.as.controller.BasicModelController.execute(BasicModelController.java:77)
at org.jboss.as.controller.SynchronousOperationSupport.execute(SynchronousOperationSupport.java:88)
at org.jboss.as.controller.AbstractModelController.execute(AbstractModelController.java:40)
at org.jboss.as.controller.test.AbstractProxyControllerTest.testRecursiveReadResourceDescriptionWithOperations(AbstractProxyControllerTest.java:151)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
"VM Thread" prio=10 tid=0x00007fd9a0087800 nid=0xd7e runnable
"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007fd9a001a000 nid=0xd7c runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007fd9a001b800 nid=0xd7d runnable
"VM Periodic Task Thread" prio=10 tid=0x00007fd9a00be800 nid=0xd85 waiting on condition
JNI global references: 1322{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBAS-9274) Upload of deployments can fail
by Heiko Rupp (JIRA)
Upload of deployments can fail
------------------------------
Key: JBAS-9274
URL: https://issues.jboss.org/browse/JBAS-9274
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Heiko Rupp
Uploading to domain-api/add-content can fail in standard setup, as the code expects directories
to be there that aren't:
[Host Controller] 09:52:11,867 ERROR [org.jboss.as.domain.http.api] (pool-2-thread-9) Unexpected error executing deployment upload request: java.io.IOException: No such file or directory
[Host Controller] at java.io.UnixFileSystem.createFileExclusively(Native Method) [:1.6.0_24]
[Host Controller] at java.io.File.checkAndCreate(File.java:1704) [:1.6.0_24]
[Host Controller] at java.io.File.createTempFile(File.java:1792) [:1.6.0_24]
[Host Controller] at org.jboss.as.domain.http.server.DomainHttpServer.extractPostContent(DomainHttpServer.java:240)
[Host Controller] at org.jboss.as.domain.http.server.DomainHttpServer.processUploadRequest(DomainHttpServer.java:123)
[Host Controller] at org.jboss.as.domain.http.server.DomainHttpServer.handle(DomainHttpServer.java:105)
Debugging into it shows
Server tmp dir is /devel/jbas7/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/domain/tmp/uploads
where domain/tmp and domain/tmp/uploads does not exist.
This is because the constructor of DomainHttpServer tries to create tmp/uploads, but fails to check if tmp/ already exists (and also ignores the information that creation of tmp/uploads failed).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Commented: (JBRULES-46) Prolog Style Query Based Backward Chaining
by Vincent Legendre (JIRA)
[ https://issues.jboss.org/browse/JBRULES-46?page=com.atlassian.jira.plugin... ]
Vincent Legendre commented on JBRULES-46:
-----------------------------------------
My comment was lacking some precisions ...
Other vendors has a sequential mode in which facts updates in first rules are taken in account for rules triggered after (BlazeAdvisor does this, not sure about JRules).
Anyway, it could be an interresting feature.
Drools sequential mode collects all t-uples, then apply rules. This prevents 'first' rules to do some updates that could change one t-uple value or even trigger (or not trigger) other rules that comes after in the rule sequence.
With a backward chaining way of evaluating rules (in a backward sequential mode), you can take in account updates after one rule execution for others. This could solve one use-case that I often encounter : Rules application that compute counters then validate them.
rule "UpdateCounter"
salience 10000
when
$c : Counter( .... , $value : value)
$o : BusinessObject( .... )
then
$c.setValue($value + $o.getSomething());
update($c);
end
rule "CheckCounter"
when
$c : Counter(value > 1234)
then
Alerts.addNew(...);
end
This way of writing rules is quite natural (and thus easier for a business user to author).
Of course there are solutions (use a rule flow, don't call the update($c) when counting and use $c.getValue() in action part, then update all counter in a separate task, and finally run the validation rules).
Another solution could be a kind of sequential mode that accepts updates for subsequents rules.
A last solution could be to handle ruleflows in sequential mode, having as many sequential evaluation as tasks, with the RETE updated a end of tasks. Yes this last point have nothing to do with backward chaining ... but I would find that very useful (and that could solve my common problem more efficiently than a backward-sequential-mode).
> Prolog Style Query Based Backward Chaining
> ------------------------------------------
>
> Key: JBRULES-46
> URL: https://issues.jboss.org/browse/JBRULES-46
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Mark Proctor
> Assignee: Mark Proctor
>
> Forward Chaining means that facts are asserted and propgated forward throughout the network, during forward propagation matching takes place which results in rules being fired - the rules are event based, in that they are fired in response to changed in the working memory.
> Backward chaining is query based. Rules attempt to fire first but do not have the necessary matched facts, so facts are pulled in from an external source.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBAS-9303) @Resource(lookup="java:module/ModuleName") doesnt work
by Felix Ullrich (JIRA)
@Resource(lookup="java:module/ModuleName") doesnt work
-------------------------------------------------------
Key: JBAS-9303
URL: https://issues.jboss.org/browse/JBAS-9303
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: 6.0.0.Final
Reporter: Felix Ullrich
Assignee: Carlo de Wolf
I cant inject the current application- or modulename with the resource-annotation in an EJB
This doesnt work:
{code:}
@Resource(lookup="java:module/ModuleName")
private String moduleName;
@Resource(lookup="java:app/AppName")
private String appName;
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Resolved: (JBJCA-30) Allow flushing of connection pool on fatal connection events
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-30?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen resolved JBJCA-30.
----------------------------------
Resolution: Done
A <flush-strategy> as added to the pool configuration.
Valid values are:
* FailingConnectionOnly (default)
* IdleConnections
* EntirePool
> Allow flushing of connection pool on fatal connection events
> ------------------------------------------------------------
>
> Key: JBJCA-30
> URL: https://issues.jboss.org/browse/JBJCA-30
> Project: IronJacamar
> Issue Type: Feature Request
> Components: Core
> Reporter: Chris Bredesen
> Assignee: Jesper Pedersen
> Priority: Critical
> Fix For: 1.0.0.Beta6
>
>
> As an alternative to validating connections (either on borrow or in the background), we could implement a feature similar to WebSphere's purge policy. The idea is that we can assume in certain cases that a single fatal exception means every connection in the pool will subsequently throw fatal exceptions. Such is the case in situations where the connected database has been restarted. Rather than implementing a purge policy per se, we would implement an "on fatal behavior". The behavior could define one of three actions to be taken when a fatal exception is encountered:
> 1. Destroy single connection (equivalent to WAS policy of "single connection")
> 2. Initiate validation run
> 3. Flush entire pool (equivalent to WAS policy of "whole pool")
> Note that all of the above (indeed this entire feature) requires the use of an ExceptionSorter.
> In terms of implementation, I see two possibilities:
> 1. Implement this feature as an MBean, which means we'd need some way of registering connection event listeners outside JCA.
> 2. Implement this feature as part of the JCA adapter which I think makes more sense, but is more impactful.
> Regarding #1, if it's possible to simply add a way to register connection event listeners from outside the adapter, that could become its own feature request and this feature simply turns into an MBean that can be implemented separately.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months