[JBoss JIRA] (WFLY-951) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-951?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated WFLY-951:
-------------------------------
Assignee: Amos Feng (was: Gytis Trikleris)
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: WFLY-951
> URL: https://issues.jboss.org/browse/WFLY-951
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
> Assignee: Amos Feng
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3205) For xa-datasource testConnection should account for deployment classloader
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3205?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3205:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1083457
> For xa-datasource testConnection should account for deployment classloader
> --------------------------------------------------------------------------
>
> Key: WFLY-3205
> URL: https://issues.jboss.org/browse/WFLY-3205
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.1.Final
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Jesper Pedersen
>
> - The fix mentioned in https://issues.jboss.org/browse/WFLY-2047 is resolves the issue for plain Non-XA dataSources. However if an XA-DataSource is configured with the "ldap" based database connection URL then it fails with the following Error:
> {code}
> 13:49:41,399 ERROR [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000906: Error during crash recovery: java:/OracleXA_DS (Could not create connection): javax.resource.ResourceException: Could not create connection
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:461)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:398)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.open(XAResourceRecoveryImpl.java:343)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:170)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.jts:main" from local module loader @3b70c (finder: local module finder @1e6a820 (roots: /home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules,/home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.jboss.jts:main" from local module loader @3b70c (finder: local module finder @1e6a820 (roots: /home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules,/home/userone/XA_DS/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base))]]
> at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:275)
> at oracle.jdbc.xa.client.OracleXADataSource.getPooledConnection(OracleXADataSource.java:454)
> at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:159)
> at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:130)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:444)
> ... 8 morec
> {code}
> - The XA dataSource configuration looks like following:
> {code}
> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
> <datasources>
> <xa-datasource jndi-name="java:/OracleXA_DS" pool-name="OracleXA_DS" enabled="true">
> <xa-datasource-property name="ServerName">
> example.com
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> TestDB
> </xa-datasource-property>
> <xa-datasource-property name="URL">
> jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA
> </xa-datasource-property>
> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
> <driver>oracle</driver>
> <security>
> <user-name>jboss</user-name>
> <password>jboss</password>
> </security>
> </xa-datasource>
> <drivers>
> <driver name="oracle" module="com.oracle.jdbc6"/>
> </drivers>
> </datasources>
> </subsystem>
> {code}
> - When the above datasource is tested via CLI like following then aht above mentioned error is noticed:
> {code}
> /subsystem=datasources/xa-data-source=OracleXA_DS:test-connection-in-pool
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3206) @DeclareRoles throws exception when accessing EJB methods
by Dirk Franssen (JIRA)
Dirk Franssen created WFLY-3206:
-----------------------------------
Summary: @DeclareRoles throws exception when accessing EJB methods
Key: WFLY-3206
URL: https://issues.jboss.org/browse/WFLY-3206
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB, Security
Affects Versions: 8.0.0.Final
Environment: Mac OSX, jdk1.8, jee7
Reporter: Dirk Franssen
Assignee: David Lloyd
When calling the getWisdom() method from the EJB below from a rest resource (principal = anonymous), it throws an exception. If I add @PermitAll it does not throw an exception.
According to jsr-250: "the @DeclareRoles would be used to define roles that could be tested. It could also be used to declare roles that are not implicitly declared as the result of their use in a RolesAllowed annotation on the class or a method of the class."
@Singleton
@DeclareRoles("dukes")
public class Greetings {
private String wisdom;
@PostConstruct
public void initialize(){
wisdom = "Java Programming Language Rocks!!!";
}
public void setWisdom(String wisdom){
this.wisdom = wisdom;
}
public String getWisdom(){
return userid + " said " + wisdom;
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (DROOLS-112) Allow join constraints in sliding windows
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-112?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-112:
------------------------------------------
Fix Version/s: 6.1.0.Beta3
(was: 6.1.0.Beta2)
> Allow join constraints in sliding windows
> -----------------------------------------
>
> Key: DROOLS-112
> URL: https://issues.jboss.org/browse/DROOLS-112
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 6.0.0.Alpha9, 6.0.0.Beta1
> Reporter: Davide Sottara
> Assignee: Mark Proctor
> Priority: Critical
> Fix For: 6.1.0.Beta3
>
>
> When using a sliding window, alpha constraints are evaluated before the window is considered, but beta (join) constraints are evaluated afterwards.
> While it does not usually make a difference when time windows are concerned,
> it DOES make a difference with length windows.
> Imho, a clear warning should be added in the documentation to clarify
> the current behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (DROOLS-88) Support generics in declared types' fields
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.... ]
Michael Biarnes Kiefer updated DROOLS-88:
-----------------------------------------
Fix Version/s: 6.1.0.Beta3
(was: 6.1.0.Beta2)
> Support generics in declared types' fields
> ------------------------------------------
>
> Key: DROOLS-88
> URL: https://issues.jboss.org/browse/DROOLS-88
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Minor
> Fix For: 5.5.1.Final, 6.1.0.Beta3
>
>
> It should be possible to write:
> declare Foo
> list : List<String>
> end
> While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules.
> Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[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.Beta3
(was: 6.1.0.Beta2)
> 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.Beta3
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months