[JBoss JIRA] (DROOLS-1468) Support OOPath in accumulate functions
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-1468:
-------------------------------------
Summary: Support OOPath in accumulate functions
Key: DROOLS-1468
URL: https://issues.jboss.org/browse/DROOLS-1468
Project: Drools
Issue Type: Feature Request
Components: core engine
Affects Versions: 7.0.0.Beta7
Reporter: Tibor Zimányi
Assignee: Mario Fusco
Priority: Minor
It would be nice to have the ability to use OOPath in accumulate functions. E.g. _sum(/fact/property)_.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8307) If name of database table is written in small letters Artemis can't detect its existence
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8307?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-9346 to WFLY-8307:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8307 (was: JBEAP-9346)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Affects Version/s: (was: 7.1.0.DR13)
> If name of database table is written in small letters Artemis can't detect its existence
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-8307
> URL: https://issues.jboss.org/browse/WFLY-8307
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Environment: Oracle 12c database
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> If the name of database table is written in small letters - e.g. node1_messages_table, Artemis can't detect its existence and it tries to create it again what leads to error \[1\]. This happens after restarting of server.
> I don't see the issue if name of database table is written in capital letters - e.g. NODE1_MESSAGES_TABLE.
> \[1\]
> {code}
> 14:00:26,208 ERROR [org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver] (ServerService Thread Pool -- 72)
> SQL STATEMENTS:
> CREATE TABLE node1_large_messages_table(ID NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY, FILENAME VARCHAR(255), EXTENSION VARCHAR(10), DATA BLOB, PRIMARY KEY(ID))
> SQL EXCEPTIONS:
> SQLState: 42000 ErrorCode: 955 Message: ORA-00955: name is already used by an existing object
> 14:00:26,372 ERROR [org.apache.activemq.artemis.journal] (ServerService Thread Pool -- 72) Could not start file factory, unable to connect to database: java.sql.SQLSyntaxErrorException: ORA-00955: name is already used by an existing objec
> t
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)
> at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059)
> at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522)
> at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257)
> at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587)
> at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210)
> at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30)
> at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150)
> at oracle.jdbc.driver.OracleStatement.executeUpdateInternal(OracleStatement.java:1707)
> at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:1670)
> at oracle.jdbc.driver.OracleStatementWrapper.executeUpdate(OracleStatementWrapper.java:310)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
> at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.createTableIfNotExists(AbstractJDBCDriver.java:170) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.createTable(AbstractJDBCDriver.java:99) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createSchema(JDBCSequentialFileFactoryDriver.java:66) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.start(AbstractJDBCDriver.java:71) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactory.start(JDBCSequentialFileFactory.java:91) [artemis-jdbc-store-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager.init(JDBCJournalStorageManager.java:74) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.<init>(AbstractJournalStorageManager.java:216) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.<init>(JournalStorageManager.java:104) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager.<init>(JDBCJournalStorageManager.java:52) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:1860) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2000) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:62) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:520) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:469) [artemis-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:412) [artemis-jms-server-1.5.3.003-redhat-1.jar:1.5.3.003-redhat-1]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:199) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-14.jar:7.1.0.Alpha1-redhat-14]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:63) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-14.jar:7.1.0.Alpha1-redhat-14]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:97) [wildfly-messaging-activemq-7.1.0.Alpha1-redhat-14.jar:7.1.0.Alpha1-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_121]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_121]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final-redhat-1.jar:2.2.1.Final-redhat-1]
> {code}
> *Customer impact:* If names of database tables are written in small letters, EAP fails at second start. From logs it's not easy to find out what is wrong and how workaround the issue. It is serious user experience problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2362) Regression: Legacy LDAP security-realm reads system-property only during boot
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2362?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2362:
---------------------------------
Description:
In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Currently it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature.
This issue does not affects scenarios, where system property is set in standalone.conf.
was:
In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Since EAP 7.1.0.DR12 it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature.
This issue does not affects scenarios, where system property is set in standalone.conf.
We request blocker flag due to regression.
> Regression: Legacy LDAP security-realm reads system-property only during boot
> -----------------------------------------------------------------------------
>
> Key: WFCORE-2362
> URL: https://issues.jboss.org/browse/WFCORE-2362
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: print-roles.war
>
>
> In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Currently it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature.
> This issue does not affects scenarios, where system property is set in standalone.conf.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2362) Regression: Legacy LDAP security-realm reads system-property only during boot
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2362?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2362:
---------------------------------
Attachment: print-roles.war
> Regression: Legacy LDAP security-realm reads system-property only during boot
> -----------------------------------------------------------------------------
>
> Key: WFCORE-2362
> URL: https://issues.jboss.org/browse/WFCORE-2362
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: print-roles.war
>
>
> In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Currently it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature.
> This issue does not affects scenarios, where system property is set in standalone.conf.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2362) Regression: Legacy LDAP security-realm reads system-property only during boot
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFCORE-2362:
------------------------------------
Summary: Regression: Legacy LDAP security-realm reads system-property only during boot
Key: WFCORE-2362
URL: https://issues.jboss.org/browse/WFCORE-2362
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
In legacy LDAP security-realm, {{org.jboss.as.domain.management.security.parseGroupNameFromLdapDN}} system property is used for decision between parsing role from DN (for property=true) or LDAP role search (otherwise). LDAP security-realm was able to read this property dynamically from server configuration. Since EAP 7.1.0.DR12 it seems that LDAP security-realm reads this property only during server boot. This means that if this property is set through system-property resource in application server then reload of server is needed to start this feature.
This issue does not affects scenarios, where system property is set in standalone.conf.
We request blocker flag due to regression.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8306) Soap attachments are being truncated when moving from jboss 7 to wildfly9/10
by Einat Peretz (JIRA)
Einat Peretz created WFLY-8306:
----------------------------------
Summary: Soap attachments are being truncated when moving from jboss 7 to wildfly9/10
Key: WFLY-8306
URL: https://issues.jboss.org/browse/WFLY-8306
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Environment: Windows
Reporter: Einat Peretz
Assignee: Stuart Douglas
Priority: Blocker
Client access wildfly 9 or 10 web service (soap using Axis2) using https with zip attachment and the zip is received truncated on the server.
The same deployed application with same client worked fine on Jboss 7.3.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1467) Bound variables become uneditable once they are saved in the rule
by Saurabh Sharma (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1467?page=com.atlassian.jira.plugi... ]
Saurabh Sharma closed DROOLS-1467.
----------------------------------
Resolution: Duplicate Issue
DroolsDROOLS-1466 already raised
> Bound variables become uneditable once they are saved in the rule
> -----------------------------------------------------------------
>
> Key: DROOLS-1467
> URL: https://issues.jboss.org/browse/DROOLS-1467
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 6.4.0.Final
> Environment: IBM WebSphere Application Server Network
> Deployment 8.5.5.9 (64-bit)
> Reporter: Saurabh Sharma
> Assignee: Mario Fusco
> Attachments: SimpleRule.jpg, SimpleRuleEdit.jpg
>
>
> Calculation of a mid price of an instrument
> While defining the WHEN condition, when a new price (NEWPRC) is bound from GSO.newPrice
> The required fields for that price is bound so that they can be changed in the THEN condition.
> The properties of the price are similar to any of the Bid or the Ask price except the unit price value. Those values are bound as well in the rule WHEN condition, and used in the
> THEN clause.
> In the THEN condition, the individual bound variables are set with values, the UI lets me add those values correctly without any issues the first time around.
> The problem occurs when the rule is saved, and opened again for editing. All the fields become uneditable and i have to repeat the steps of binding the variables of
> NEWPRC and then modify/set the values of those variables again in the WHEN condition.
> Is there any way to open the rule and get those bound variables in the edit mode
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1467) Bound variables become uneditable once they are saved in the rule
by Saurabh Sharma (JIRA)
Saurabh Sharma created DROOLS-1467:
--------------------------------------
Summary: Bound variables become uneditable once they are saved in the rule
Key: DROOLS-1467
URL: https://issues.jboss.org/browse/DROOLS-1467
Project: Drools
Issue Type: Bug
Components: tools
Affects Versions: 6.4.0.Final
Environment: IBM WebSphere Application Server Network
Deployment 8.5.5.9 (64-bit)
Reporter: Saurabh Sharma
Assignee: Mario Fusco
Attachments: SimpleRule.jpg, SimpleRuleEdit.jpg
Calculation of a mid price of an instrument
While defining the WHEN condition, when a new price (NEWPRC) is bound from GSO.newPrice
The required fields for that price is bound so that they can be changed in the THEN condition.
The properties of the price are similar to any of the Bid or the Ask price except the unit price value. Those values are bound as well in the rule WHEN condition, and used in the
THEN clause.
In the THEN condition, the individual bound variables are set with values, the UI lets me add those values correctly without any issues the first time around.
The problem occurs when the rule is saved, and opened again for editing. All the fields become uneditable and i have to repeat the steps of binding the variables of
NEWPRC and then modify/set the values of those variables again in the WHEN condition.
Is there any way to open the rule and get those bound variables in the edit mode
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months