[JBoss JIRA] Created: (JBRULES-2863) Tuple is null when firing an activation
by Edson Tirelli (JIRA)
Tuple is null when firing an activation
---------------------------------------
Key: JBRULES-2863
URL: https://issues.jboss.org/browse/JBRULES-2863
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.2.0.M1
For some reason, an activation is firing with a nulled tuple, i.e., it seems the activation is being created, but not properly removed from the agenda. There are not many details but the rule in question uses both ruleflow-group and no-loop.
Reported by Dan Quinn.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[JBoss JIRA] Created: (AS7-796) OSGi bypasses other DUPs when osgi metadata is found
by Jason Greene (JIRA)
OSGi bypasses other DUPs when osgi metadata is found
----------------------------------------------------
Key: AS7-796
URL: https://issues.jboss.org/browse/AS7-796
Project: Application Server 7
Issue Type: Bug
Reporter: Jason Greene
Assignee: Jason Greene
Priority: Blocker
If an EE, or JDBC driver happens to include osgi metadata, it will no longer deploy. This is because the OSGi subsystem bypasses other deployers, and treats it as just a bundle.
Both Mysql and Hypersonic can not be deployed due to this problem.
Ideally the OSGi subsystem would just add services and augment the model configs so that other deployers can function.
Alternatively we can explore the possibility of deploying bundles differently than regular deployments, perhaps requiring special packaging, or extra deployment data.
If we can't come up with a solution by CR1, I think we need to disable the OSGi subsystem by default.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[JBoss JIRA] Created: (EJBTHREE-1647) @Resource injection of primitive types from JNDI
by Dennis Reed (JIRA)
@Resource injection of primitive types from JNDI
------------------------------------------------
Key: EJBTHREE-1647
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1647
Project: EJB 3.0
Issue Type: Bug
Components: injection
Affects Versions: AS 4.2.1.GA
Reporter: Dennis Reed
The following does not work to inject an arbitrary JNDI entry for primitive/primitive wrapper/String fields:
@Resource( mappedName = "java:/blah/blah" )
String myVar;
In older versions, a "NYI" exception was thrown (then changed to a different exception before getting to the user).
In newer versions, the literal value in mappedName is injected.
For all other types, the JNDI entry injection works. For example, the following does inject that same String from JNDI:
@Resource( mappedName = "java:/blah/blah" )
Object myVar;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[JBoss JIRA] Created: (JBRULES-2588) Error creates null package without generating error message
by Thomas Hehl (JIRA)
Error creates null package without generating error message
-----------------------------------------------------------
Key: JBRULES-2588
URL: https://jira.jboss.org/browse/JBRULES-2588
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.0.1.FINAL
Environment: Windows XP/Eclipse Ganymeade
Reporter: Thomas Hehl
Assignee: Mark Proctor
Priority: Minor
Fix For: 5.0.2, 5.1.0.CR1, FUTURE
PackageBuilder contains the following method:
public void addPackageFromDrl(final Reader reader) throws DroolsParserException,
IOException {
this.resource = new ReaderResource( reader );
final DrlParser parser = new DrlParser();
final PackageDescr pkg = parser.parse( reader );
this.results.addAll( parser.getErrors() );
if ( !parser.hasErrors() ) {
addPackage( pkg );
}
this.resource = null;
}
The problem is that if the parser generates errors, then the package is null and my application blows up later on with a null pointer exception, but the error messages are lost.
To fix this problem I recommend a code change like:
public void addPackageFromDrl(final Reader reader) throws DroolsParserException,
IOException {
this.resource = new ReaderResource( reader );
final DrlParser parser = new DrlParser();
final PackageDescr pkg = parser.parse( reader );
this.results.addAll( parser.getErrors() );
if ( parser.hasErrors() ) {
System.err.println("Parser errors generating null package:" + this.results.toString());
else{
addPackage( pkg );
}
this.resource = null;
}
This will cause an error dump in the log without changing any functionality.
--
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
14 years, 11 months