[JBoss JIRA] (JBRULES-3330) Provide MoveFilter for generic factories
by Lukáš Petrovický (Created) (JIRA)
Provide MoveFilter for generic factories
----------------------------------------
Key: JBRULES-3330
URL: https://issues.jboss.org/browse/JBRULES-3330
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: 5.4.0.Beta1
Reporter: Lukáš Petrovický
Assignee: Mark Proctor
At the moment, generic factories are far too generic - for most of the problems, an optimization can be found so that the amount of reasonable moves is significantly reduced. The intention is to allow customization of the generic move factories, while still using all their power. Generic move factory simply produces every possible move and the user defines, in a MoveFilter, which of them shouldn't be passed to the planner. The feature could work like this:
1. An interface is introduced, called eg. MoveFilter<T extends Move>. This interface declares one method - boolean filter(Solution solution, T move). This method accepts the solution of the MoveFactory, as well as the Move object that's been created by the MoveFactory. It returns true if the GenericMove should be included in the createMoveList() method of the MoveFactory, false otherwise.
(Please make sure that the MoveFilter type is generic, so that filter() always knows the correct type of the move without the user doing any magic or assumptions. This would most probably require making MoveFactory generic as well, but that could be useful.)
2. Implementations of the MoveFilter interface are annotated with @MoveFilter(factory = [SomeMoveFactory.class, SomeOtherMoveFactory.class]). This annotation would specify to which move factory this filter should be related. Some checks should be put in place that the annotation will only work when the MoveFilter and MoveFactory share the same Move type.
3. The same as in (2) can be achieved by specifying filters in the XML configuration of the solver, altough I personally don't like the XML configs much.
4. MoveFactory's createMoveList() method is enhanced so that it runs user-specified MoveFilters and excludes the filtered moves from the resulting MoveList.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3556) Support mappings between trait and core class fields
by Davide Sottara (JIRA)
Davide Sottara created JBRULES-3556:
---------------------------------------
Summary: Support mappings between trait and core class fields
Key: JBRULES-3556
URL: https://issues.jboss.org/browse/JBRULES-3556
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-compiler, drools-core
Affects Versions: 5.4.0.Final
Reporter: Davide Sottara
Assignee: Davide Sottara
Priority: Minor
Fix For: 5.5.0.Beta1
Trait - Core field mapping requires the fields to have the same name and compatible types. Whenever the names cannot be the same, e.g. due to interface naming requirements, it could be desirable to define a custom mapping:
declare trait X
tfield : String @Alias("cField")
end
declare Y
cField : String
end
Here, tField should be mapped onto the hard field cField, even if the names are different
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3521) accumulation function ignores conditions in 5.4.0.Final
by Radai Rosenblatt (JIRA)
Radai Rosenblatt created JBRULES-3521:
-----------------------------------------
Summary: accumulation function ignores conditions in 5.4.0.Final
Key: JBRULES-3521
URL: https://issues.jboss.org/browse/JBRULES-3521
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (fusion)
Affects Versions: 5.4.0.Final
Environment: windows 7 x64, tested with jdk 6 and 7
Reporter: Radai Rosenblatt
Assignee: Mark Proctor
Attachments: accumulationBug.zip
given this drl:
package playground
import playground.datamodel.EventObject
declare EventObject
@role( event )
end
rule "new event under average"
when
$latestEvent : EventObject(level == "Full", status == "success", $size : size ) from entry-point "Event Stream"
Number($averageSize : doubleValue, doubleValue > ($size)) from accumulate( EventObject(level=="Full", this before $latestEvent, status == "success", $bSize : size ) over window:time( 5d ) from entry-point "Event Stream" , average($bSize))
then
System.err.println("new event under 5d average");
end
and the following sequence of 3 events:
{Full,success,100},{Whatever,fail,0},{Full,success,99}
the 3rd event should trigger a firing. the complete breakdown of events should be as follows:
1. 1st event is inserted, average is 0 because there are no previous events - no firing.
2. 2nd event is inserted - does not match the conditions and therefore should not be accumulated.
3. 3rd event is inserted - accumulation should only consider the 1st event, hence the avg. is 100. the event value is 99, which is below the avg - rule should fire.
this works with drools 5.1.1 but fails in 5.4.0.Final - in 5.4 the 2nd event is acounted by the average function and so the rule does not fire.
attached is a complete maven project to recreate this bug - simply unzip and run "mvn clean install" to recreate.
also in the mvn project attached, simply change the drools.version property in the pom.xml from 5.4.0.Final to 5.1.1 (already in there, just commented out) to verify this works in 5.1.1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4854) Failures on clustered remote EJB invocations in event of server shutting down using DIST SYNC cache (NullPointerException: Null keys are not supported!)
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4854:
-----------------------------------
Summary: Failures on clustered remote EJB invocations in event of server shutting down using DIST SYNC cache (NullPointerException: Null keys are not supported!)
Key: AS7-4854
URL: https://issues.jboss.org/browse/AS7-4854
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.3.Final (EAP)
Remote client is up, but one server shuts down, results at first in
{noformat}
2012/05/21 12:09:33:112 EDT [WARN ][Runner - 177] SFCORE_LOG - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:157)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:58)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.NamingException: Failed to create proxy [Root exception is java.lang.RuntimeException: java.io.IOException: Channel Channel ID 8907f2dd (outbound) of Remoting connection 7821f46a to perf18/10.16.90.54:4447 has been closed]
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:115)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:148)
... 4 more
Caused by: java.lang.RuntimeException: java.io.IOException: Channel Channel ID 8907f2dd (outbound) of Remoting connection 7821f46a to perf18/10.16.90.54:4447 has been closed
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:247)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:163)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)
... 7 more
Caused by: java.io.IOException: Channel Channel ID 8907f2dd (outbound) of Remoting connection 7821f46a to perf18/10.16.90.54:4447 has been closed
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:111)
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:103)
at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
at org.jboss.remoting3.remote.RemoteConnectionHandler.receiveCloseRequest(RemoteConnectionHandler.java:205)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:106)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
{noformat}
and on later failures on NullPointerException: Null keys are not supported!
{noformat}
2012/05/21 12:11:41:077 EDT [WARN ][Runner - 7] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:157)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:58)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.NamingException: Failed to create proxy [Root exception is java.lang.RuntimeException: java.lang.NullPointerException: Null keys are not supported!]
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:115)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:148)
... 4 more
Caused by: java.lang.RuntimeException: java.lang.NullPointerException: Null keys are not supported!
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:247)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:163)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)
... 7 more
Caused by: java.lang.NullPointerException: Null keys are not supported!
at org.infinispan.CacheImpl.assertKeyNotNull(CacheImpl.java:196)
at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:201)
at org.infinispan.CacheImpl.put(CacheImpl.java:699)
at org.infinispan.DecoratedCache.put(DecoratedCache.java:319)
at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:308)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore$1.invoke(InfinispanBackingCacheEntryStore.java:173)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore$1.invoke(InfinispanBackingCacheEntryStore.java:170)
at org.jboss.as.clustering.infinispan.invoker.BatchOperation.invoke(BatchOperation.java:19)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:60)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.invoke(InfinispanBackingCacheEntryStore.java:239)
at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.insert(InfinispanBackingCacheEntryStore.java:177)
at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:304)
at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:51)
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.create(PassivatingBackingCacheImpl.java:122)
at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:67)
at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:41)
at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:242)
at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:148)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:243)
... 10 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBRULES-2700) Allow setting globals for access by the scoring rules
by Wouter Horré (JIRA)
Allow setting globals for access by the scoring rules
-----------------------------------------------------
Key: JBRULES-2700
URL: https://jira.jboss.org/browse/JBRULES-2700
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Wouter Horré
Assignee: Mark Proctor
Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed.
The easiest implementation is probably a new method in the Solver interface:
public WorkingMemory getWorkingMemory();
which provides access to the working memory used by the solver.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3571) Planner examples: import filenames should be filtered by regex pattern
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created JBRULES-3571:
-----------------------------------------
Summary: Planner examples: import filenames should be filtered by regex pattern
Key: JBRULES-3571
URL: https://issues.jboss.org/browse/JBRULES-3571
Project: Drools
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Trivial
Especially in the machine reassignement example this is annoying, because when you click the "import" button there, it shows "assignement.*" and "model.*" files, but only model files can be succesfully imported.
The trick is to use a filefilter.
Howto:
Create the method SolutionBusiness.acceptImportFile()
which delegates to AbstractSolutionImporter.acceptInputFile().
Next, in SolverAndPersistenceFrame.ImportAction.actionPerformed(...) set a FileFilter and make it use SolutionBusiness.acceptImportFile().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-5072) value-type not set on ObjectTypeAttributeDefinition
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5072:
--------------------------------
Summary: value-type not set on ObjectTypeAttributeDefinition
Key: AS7-5072
URL: https://issues.jboss.org/browse/AS7-5072
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Jeff Mesnil
Assignee: Tomaz Cerar
I am not able to define an attribute properly and it seems there is a bug with setting value-type on an ObjectTypeAttributionDefinition.
I have a CoreAddressDefinition which defines a runtime read-only attribute "roles". This attribute is a LIST of OBJECT named "role". This OBJECT is composed of a STRING attribute "name" and many BOOLEAN attributes (from the SecurityRoleDefinition).
They are represented by:
private static final AttributeDefinition NAME = create("name", ModelType.STRING)
.build();
private static final ObjectTypeAttributeDefinition ROLE = ObjectTypeAttributeDefinition.Builder.of(CommonAttributes.ROLE, new AttributeDefinition[] { NAME }, SecurityRoleDefinition.ATTRIBUTES)
.build();
static final AttributeDefinition ROLES = ObjectListAttributeDefinition.Builder.of(CommonAttributes.ROLES_ATTR_NAME, ROLE)
.setFlags(AttributeAccess.Flag.STORAGE_RUNTIME)
.build();
After they are registered (using a DefaultResourceDescriptionProvider), the value-type of the OBJECT attribute is not set. I was expecting it to be the concatenation of the various valueTypes I passed to the ROLE attribute.
{
"description" => "A runtime-only resource representing a HornetQ \"address\". Zero or more queues can be bound to a single address. When a message is routed, it is routed to the set of queues bound to the message's address.",
"attributes" => {"roles" => {
"type" => LIST,
"description" => "A list of the security roles (name and permissions) associated with the address.",
"expressions-allowed" => false,
"nillable" => false,
"value-type" => {"role" => {
"type" => OBJECT,
"description" => "A security role associated with the address.",
"expressions-allowed" => false,
"nillable" => false
}}
}},
"operations" => undefined,
"children" => {}
}
I did a dew debugging and one thing that I don't understand is why in ObjectListAttributeDefinition, the 3 implementations of addValueTypeDescription are different and only 1 will check whether the value type corresponds to an OBJECT. Using a DefaultResourceDescriptionProvider I end up using ObjectListAttributeDefinition#addAttributeValueTypeDescription(final ModelNode node, final ResourceDescriptionResolver resolver, final Locale locale, final ResourceBundle bundle) which does *not* set the value-type.
To reproduce this failure, you can run mvn clean install -pl messaging from my branch, all the tests fail because of this one: https://github.com/jmesnil/jboss-as/tree/AS7-4790_ResourceDefinition_conv...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months