August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-467) Sort out JBoss AS dependencies

by Ovidiu Feodorov (JIRA)

Sort out JBoss AS dependencies ------------------------------ Key: JBMESSAGING-467 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-467 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Alpha1 Currently we've imported JBossAS in the lib area of our project to keep the project compiling. This is hardly an acceptable solution. The proper solution involves: 1) Deciding what JBossAS depenencies we need and getting rid of arificially dependencies 2) Work with AS team to identifiy the AS interfaces that need to be isolated and exposed in the repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

4
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-455) CVS to SVN repository migration

by Ovidiu Feodorov (JIRA)

CVS to SVN repository migration ------------------------------- Key: JBMESSAGING-455 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-455 Project: JBoss Messaging Issue Type: Task Components: Build System Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

4
7
0 / 0

[JBoss JIRA] Created: (JBRULES-439) Feature request for the rule parser / compiler that would make the code in the eclipse IDE easier

by Kris Verlaenen (JIRA)

Feature request for the rule parser / compiler that would make the code in the eclipse IDE easier ------------------------------------------------------------------------------------------------- Key: JBRULES-439 URL: http://jira.jboss.com/jira/browse/JBRULES-439 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Reporter: Kris Verlaenen Assigned To: Mark Proctor This JIRA explains what improvements to the DRL parser could be very useful in the IDE. Currently, the eclipse IDE uses the rule parser to - create an outline view based on the PackageDescr returned when parsing the DRL file - retrieve all imports, all functions, all queries, all templates and the package of a DRL file (so they can be used later, for example when performing auto-completion) - determine the location of the cursor when requesting auto-completion (the part of the rule before the cursor is parsed, and based on the (unsually partically incomplete) PackageDescr returned by the parser, I try to determine in what kind of location the cursor is situation, e.g. the beginning of a column constraint, or inside an eval statement) - retrieve all parameters defined in a rule (possibly before a certain location) when auto-completion has been requested - retrieve errors and warnings that signal certain syntax errors in the DRL file Other places were the results of the DRL parser could be used: - determine which element is selected based on a character selection range - provide real-time syntax checking - determine what has changed after the DRL has been changed - do refactoring - automatic error solving Although the info returned by the parser is very useful, I think we are kind of reaching the boundary of what we can do with the info that is currently returned. I'll try to describe possible enhancements that could allow us to do more advanced IDE features as well. * Use of character number in addition with line number + column Eclipse uses character numbers instead of line + column numbers in almost all situations. A character number describes at which location a certain character occurs since the beginning of the file (and not like column since the beginning of the line). Although we could try to create a mapping between character number and line + column number, this has resulted in some annoying errors related to the newline character which is different on different platforms. Using character numbers would eliminate this problem. * All elements in the PackageDescr should have a start location Currently, most do (PatternDescr has a getLine() and getColumn()), but some elements in the PackageDescr returned by the parser still don't: - FunctionDescr has no line and column - imports are just strings - the package has no location To be able to use this information for more advanced features, it would be necessary that all elements contain a start location (now the IDE usually does additional parsing to determine the location of these elements). * All elements should also have an end location Although PatternDescr has a getEndLine() and getEndColumn(), currently, only the end location of ColumnDescr is stored (thx mic for adding this already since it was necessary for code completion). To be able to use this information for more advanced features, it would be necessary that all elements contain an end location (now the IDE usually does additional parsing to determine the end location of these elements). * For nested elements, this should be the same as much as possible Like RuleDescr contains ColumnDescr contains FieldConstraintDescrs, each of these elements should contain a start and end location (where the start and end of the sub-descriptions are of course located inside the start and end location of its parent. I believe that this is already working quite well in the current implementation for the start location of elements. * The parser should return as much info as possible, even if the rule is incomplete This is very important since the DrlParser is used a lot when the DRL is not yet completely finished (for example when performing auto-completion). It would be crucial that the parser does not just return an error when it encounters an error, but tries to parse the remainder of the file as well, and tries to return as much info as possible. For example, when trying to parse the following incomplete rule: rule MyRule MyClass ( the parser should ideally return a RuleDescr with name MyRule, containing as lhs one ColumnDescr, with name MyClass, a start location, but no end location (since the end of the ColumnDescr has not been reached yet, since the closing bracket is missing). This used to work like this in the 3.0.x release. I have noticed though that the 3.1 branch now returns null as only sub-description. Similarly, when using an eval, currently the EvalDescr is only added to the RuleDescr once the eval has been closed. As a result, the IDE has to redo a lot of parsing to check for these situations as well. If the parser always returns as much info as available (by for example adding subdescr once they are started, not only when they are finished), the IDE would not have to do as much parsing itself. * All errors and warnings try to give exact locations in the drl Although previous improvements have made the errors returned by the parser already very useful, more precise feedback could be given when the exact location of the errors could be returned, preferably as character start and end, but line numbers can be used here as well. Currently, the error is mostly indicated on the start line of the rule that contains the error. More precise error determination is necessary for more precise error visualization, automatic error solving, etc. I hope this kind of explains what improvements to the parser could be very useful to the IDE and why. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-372) QueryResult.get fires ClassCastException when using the string argument

by Giovanni Cuccu (JIRA)

QueryResult.get fires ClassCastException when using the string argument ----------------------------------------------------------------------- Key: JBRULES-372 URL: http://jira.jboss.com/jira/browse/JBRULES-372 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss Rules 3.0.1 and JBoss Rules as downloaded from svn trunk as of 12/07/06 Reporter: Giovanni Cuccu Assigned To: Mark Proctor here is the simple test case: package simpletest; public class AssertedObject { private String value; public String getValue() { return value; } public void setValue(String value) { this.value = value; } public AssertedObject(String value) { // TODO Auto-generated constructor stub this.value = value; } } package simpletest; import simpletest.AssertedObject; rule rule1 when then assert( new AssertedObject( "value1") ); assert( new AssertedObject( "value2") ); end query "assertedobjquery" assertedobj : AssertedObject( value=="value1" ) end package simpletest; import java.io.InputStreamReader; import java.util.HashMap; import java.util.Iterator; import java.util.Map; import mit.rules.test.Prestazione; import mit.rules.test.StrutturaErogante; import mit.rules.test.TempiAttesa; import mit.rules.test.TestRules; import org.drools.QueryResult; import org.drools.QueryResults; import org.drools.RuleBase; import org.drools.RuleBaseFactory; import org.drools.WorkingMemory; import org.drools.audit.WorkingMemoryFileLogger; import org.drools.compiler.PackageBuilder; public class TestQuery { public static void main(String[] args) throws Exception { // TODO Auto-generated method stub final PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl( new InputStreamReader( TestQuery.class.getResourceAsStream( "testquery.drl" ) ) ); final RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage( builder.getPackage() ); final WorkingMemory workingMemory = ruleBase.newWorkingMemory(); fireRules(workingMemory); } public static void fireRules(WorkingMemory workingMemory) { final WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger( workingMemory ); logger.setFileName( "log/testquery" ); workingMemory.fireAllRules(); QueryResults results = workingMemory.getQueryResults( "assertedobjquery" ); if (results==null || !results.iterator().hasNext()) { System.err.println("Empty list"); } else { for ( Iterator it = results.iterator(); it.hasNext(); ) { QueryResult result = ( QueryResult )it.next();; AssertedObject assertedObject=(AssertedObject)result.get( "assertedobj" ); System.out.println("AssertedObject with value " + assertedObject.getValue()); } } logger.writeToDisk(); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-447) correct NullPointer when processing PRIORITY rule tag

by G￡bor Lipt￡k (JIRA)

correct NullPointer when processing PRIORITY rule tag ----------------------------------------------------- Key: JBRULES-447 URL: http://jira.jboss.com/jira/browse/JBRULES-447 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Decision tables Affects Versions: 3.0.4 Reporter: G￡bor Lipt￡k Assigned To: Mark Proctor Attachments: jboss_rules_priority.diff diff attached. I'm not sure if using LshBuilder is the correct thing to do ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

5
11
0 / 0

[JBoss JIRA] Created: (JBRULES-445) behavior of globals?

by G￡bor Lipt￡k (JIRA)

behavior of globals? -------------------- Key: JBRULES-445 URL: http://jira.jboss.com/jira/browse/JBRULES-445 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.4 Reporter: G￡bor Lipt￡k Assigned To: Mark Proctor Priority: Minor It seems that the value of DRL globals without external env backup is removed between rules: package globaltest import Policy; global java.lang.String text; rule "Foo" salience 999 when Policy() then text="foo"; System.out.println("foo+"+text); end rule "Bar" salience 998 when Policy() then System.out.println("bar+"+text); text="bar"; System.out.println("bar+"+text); end results in: foo+foo bar+null bar+bar The documentation does not seem to provide details if this is the expected behavior. Please comment. Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-742) PojoCache needs to propogate POJO events to remote nodes

by Ben Wang (JIRA)

PojoCache needs to propogate POJO events to remote nodes -------------------------------------------------------- Key: JBCACHE-742 URL: http://jira.jboss.com/jira/browse/JBCACHE-742 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ben Wang Assigned To: Ben Wang Priority: Critical Fix For: PojoCache 2.1.0 Currently, in the new 2.0 design, the POJO events, attach, detach, and field updates are local only. That is, remote node won't have any notification. This is an defficency. To crroect this, we will need to have another RPC layer that sits on the same channel as the the Cache to propogate the events. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-657) StatefulBean passivation is broken (ClassCastException in org.jboss.ejb3.stateful.NestedStatefulBeanContext)

by Carlo de Wolf (JIRA)

StatefulBean passivation is broken (ClassCastException in org.jboss.ejb3.stateful.NestedStatefulBeanContext) ------------------------------------------------------------------------------------------------------------ Key: EJBTHREE-657 URL: http://jira.jboss.com/jira/browse/EJBTHREE-657 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Carlo de Wolf Priority: Critical StatefulBean passivation is broken, because there is a conflict between what gets serialized (attribute contains) and what gets unserialized (attribute beanMO). 11:41:37,109 ERROR [STDERR] Caused by: java.lang.ClassCastException: java.util.ArrayList 11:41:37,109 ERROR [STDERR] at org.jboss.ejb3.stateful.NestedStatefulBeanContext.readExternal(Neste dStatefulBeanContext.java:60) 11:41:37,109 ERROR [STDERR] at org.jboss.serial.persister.ExternalizePersister.readData(Externalize Persister.java:72) 11:41:37,109 ERROR [STDERR] at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectD escriptionFromStreaming(ObjectDescriptorFactory.java:411) 11:41:37,109 ERROR [STDERR] at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromD escription(ObjectDescriptorFactory.java:81) 11:41:37,109 ERROR [STDERR] at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectIn put.readObject(DataContainer.java:639) 11:41:37,109 ERROR [STDERR] at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride (ObjectInputStreamProxy.java:68) 11:41:37,109 ERROR [STDERR] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:333) 11:41:37,109 ERROR [STDERR] at java.util.ArrayList.readObject(ArrayList.java:592) 11:41:37,109 ERROR [STDERR] ... 74 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

3
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-511) JDBC and Transaction close/cleanup operations should be bullet-proofed JDBCChannelMapper and elsewhere.

by Joel Lindheimer (JIRA)

JDBC and Transaction close/cleanup operations should be bullet-proofed JDBCChannelMapper and elsewhere. ------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-511 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-511 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.0.1.CR4 Environment: Windows Reporter: Joel Lindheimer Assigned To: Ovidiu Feodorov I am concerned with object close and wrap.end() methods in JDBCChannelMapper possibly being bypassed if an exception is thrown in the rs.close(), ps.close() blocks (code below is an example of what is currently in the JDBCChannelMapper). JDBCChannelMapper : public DurableSubscription getDurableSubscription(String clientID, String subscriptionName, MessageStore ms, PersistenceManager pm, MemoryManager mm) throws Exception { // Look in memory first DurableSubscription sub = getDurableSubscription(clientID, subscriptionName); if (sub != null) { return sub; } //Now look in the db Connection conn = null; PreparedStatement ps = null; ResultSet rs = null; TransactionWrapper wrap = new TransactionWrapper(); try { conn = ds.getConnection(); ps = conn.prepareStatement(selectDurableSub); (do stuff here... ) return sub; } finally { if (rs != null) { // JL what if it blose up here? rs.close(); } if (ps != null) { // JL or here? ps.close(); } if (conn != null) { // or here? conn.close(); } wrap.end(); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-463) audit log for all system actions

by Michael Neale (JIRA)

audit log for all system actions -------------------------------- Key: JBRULES-463 URL: http://jira.jboss.com/jira/browse/JBRULES-463 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

3
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2006