September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2705) Guvnor gwt compile uses different eclipse jdt ecj version in ant script (due to gwt-dev) than in pom

by Geoffrey De Smet (JIRA)

Guvnor gwt compile uses different eclipse jdt ecj version in ant script (due to gwt-dev) than in pom ---------------------------------------------------------------------------------------------------- Key: JBRULES-2705 URL: https://jira.jboss.org/browse/JBRULES-2705 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.1.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.2.0.M1 Blocks removing the ant script and switching to 100% maven build with the maven gwt plugin -- 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, 9 months

1
8
0 / 0

[JBoss JIRA] Created: (JBAS-8169) Make default values of org.jboss.metadata.IorSecurityConfigMetaData configurable

by Dimitris Andreadis (JIRA)

Make default values of org.jboss.metadata.IorSecurityConfigMetaData configurable -------------------------------------------------------------------------------- Key: JBAS-8169 URL: https://jira.jboss.org/browse/JBAS-8169 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: IIOP service Affects Versions: 6.0.0.M3, JBossAS-5.1.0.GA, JBossAS-4.2.2.GA Reporter: Dimitris Andreadis Assignee: Stefan Guilhen User wants to allow the configuration of all IOR default parameters that are hard coded in org.jboss.metadata.IorSecurityConfigMetaData ([SasContext : callerPropagation] and [AsContext : authMethod, realm, required] and [TransportConfig : integrity, confidentiality, detectMisordering, detectReplay, establishTrustInTarget, establishTrustInClient]). Mostly they want to be able to configure [AsContext : realm] and [SasContext : callerPropagation] -- 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, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-1121) Leverage JAXB to the full extent

by Vladimir Blagojevic (JIRA)

Leverage JAXB to the full extent -------------------------------- Key: JGRP-1121 URL: https://jira.jboss.org/jira/browse/JGRP-1121 Project: JGroups Issue Type: Task Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 2.9 Since we are going to base 2.9 release on JDK 6 we can use JAXB for configuration reading, XSD schema and documentation generation. -- 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

13 years, 9 months

3
5
0 / 0

[JBoss JIRA] Created: (JBJCA-432) Spelling mistakes in guide documentation

by Jeremy Whiting (JIRA)

Spelling mistakes in guide documentation ---------------------------------------- Key: JBJCA-432 URL: https://jira.jboss.org/browse/JBJCA-432 Project: IronJacamar Issue Type: Task Components: Documentation Environment: Not Applicable. Reporter: Jeremy Whiting Assignee: Jesper Pedersen Priority: Trivial Attachments: docs-diff.txt Corrections for minor spelling mistakes. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1243) FD_SOCK: reduce number of messages sent on a suspicion

by Bela Ban (JIRA)

FD_SOCK: reduce number of messages sent on a suspicion ------------------------------------------------------ Key: JGRP-1243 URL: https://jira.jboss.org/browse/JGRP-1243 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10.1, 2.11 - When B suspects C, B multicasts a SUSPECT(C) message - Everyone receives the SUSPECT(C) message and passes it up and down the stack as a SUSPECT(C) event - VERIFY_SUSPECT *on every member* sends one (or more) ARE_YOU_DEAD messages to C - C replies to the sender with a I_AM_NOT_DEAD messages, or not if crashed - However, only the coordinator (or next in line) actually processes the SUSPECT(C) event in GMS ! --> All of the VERIFY_SUSPECT processing is superfluous unless it is the coord or next-in-line ! The number of messages used for a false suspicion are (1 SUSPECT mcast) + ((N-1) ARE_YOU_DEAD unicasts) + ((N-1) I_AM_NOT_DEAD unicasts)) ! SOLUTION: - The SUSPECT(C) message could be sent as a unicast only to the coordinator and the next-in-line member. Maybe we could use a max_rank=2 for this, similar to the suggested solution for FD_ALL ? This would be good for non multicast based transports, e.g. TCP - The SUSPECT(C) message is multicast to everyone, but only the coord and next-in-line start the VERIFY_SUSPECT processing Issue: if we have {A,B,C,D,E}, what happens if A,B and C crash at the same time ? - E's connection to A closes: E sends a SUSPECT(A) to B and C (excluding suspected A) --> B and C are dead and won't process the message ! - Then E suspects B and sends a SUSPECT(A,B) to C and D (excluding suspected A and B) - C adds A and B to its suspect list and finds out it is the next-in-line - C then runs the VERIFY_SUSPECT protocol - C passes the SUSPECT(A,B) event up the stack - C becomes the new coord -- 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, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-1102) Invalid hyperlink in error message

by Brian Stansberry (JIRA)

Invalid hyperlink in error message ---------------------------------- Key: JGRP-1102 URL: https://jira.jboss.org/jira/browse/JGRP-1102 Project: JGroups Issue Type: Bug Affects Versions: 2.7, 2.6.13, 2.4.7 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 2.6.14, 2.8, 2.4.7 As reported by Rado Husar on JBPAPP-3117: > Setting an incorrent mcast_addr results in the exception below, which points to stale location: > > http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking > > [JBoss] 05:57:35,544 WARN [UDP] could not bind to /234.1.78.86 (IPv4 address); make sure your mcast_addr is of the same type as the preferred IP stack (IPv4 or IPv6) by checking the value of the system properties java.net.preferIPv4Stack and java.net.preferIPv6Addresses. > [JBoss] Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). > [JBoss] Exception was: java.net.BindException: Cannot assign requested address I'll change this to the permanent (knock on wood) URL for this page: https://www.jboss.org/community/docs/DOC-9469 -- 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

13 years, 9 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-8482) Integrate EJB3 JNDI binder into AS trunk

by jaikiran pai (JIRA)

Integrate EJB3 JNDI binder into AS trunk ---------------------------------------- Key: JBAS-8482 URL: https://jira.jboss.org/browse/JBAS-8482 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Integrate org.jboss.ejb3.jndi.binder into AS trunk. The EJB3 jndi binders implements the EJB3.1 Global JNDI naming spec requirements. -- 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, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2326) request to improve upon error message received from invalid rule syntax (currently getting NPE)

by Jeremy Ary (JIRA)

request to improve upon error message received from invalid rule syntax (currently getting NPE) ----------------------------------------------------------------------------------------------- Key: JBRULES-2326 URL: https://jira.jboss.org/jira/browse/JBRULES-2326 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.0.M1 Reporter: Jeremy Ary Assignee: Mark Proctor My (albeit improper) rule syntax that caused the NPE error: when QueueList ( queueIds contains 1 ) ( not EventList ( events contains 1 ) || ( $eventList : EventList ( events contains 1 ) && RfEvent ( eventTypeId == 1, lastActivationLong after[-1h] sessionTime ) from $eventList.events ) ) then modify (eventList) { add(1) } Stack Trace: org.drools.runtime.rule.ConsequenceException: java.lang.NullPointerException at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:23) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:943) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:885) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1086) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:660) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:627) at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:183) at com.famc.service.RuleFlowRunner.main(RuleFlowRunner.java:118) Caused by: java.lang.NullPointerException at org.drools.base.mvel.DroolsMVELFactory.getTupleObjectFor(DroolsMVELFactory.java:182) at org.drools.base.mvel.DroolsMVELFactory.setContext(DroolsMVELFactory.java:176) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:57) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:934) ... 6 more Request for ticket: [10:19] <etirelli> jary: raising a NPE is clearly a bug, but the reason is that you have modify(eventList) instead of modify($eventList)... in any case, the way you authored the rule is not ideal [10:19] <etirelli> jary: could you please open a JIRA so that we can provide an appropriate error message, please? -- 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

13 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2268) Unknown Parser Error when spreading rule condition over multiple lines

by Jeremy Ary (JIRA)

Unknown Parser Error when spreading rule condition over multiple lines ---------------------------------------------------------------------- Key: JBRULES-2268 URL: https://jira.jboss.org/jira/browse/JBRULES-2268 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.CR1 Environment: XP-SP3, eclipse 3.4.2, 5.0.0.CR1 Reporter: Jeremy Ary Assignee: Mark Proctor Full message: Unknown error while parsing. This is a bug. Please contact the Development team. To recreate: I broke a condition over multiple lines and mistakenly misgrouped my parentheses, leading to an unknown error while parsing: {code} rule "recreate bug" when Loan ( amount >= 175000 ) && ( program == "FHA" ) ) then modify (queueList) { add (QueueIds.UWENTRY) } end {code} When corrected to the following, the rule is parsed properly: {code} rule "recreate bug" when Loan ( ( amount >= 175000 ) && ( program == "FHA" ) ) then modify (queueList) { add (QueueIds.UWENTRY) } end {code} -- 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

13 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-8461) Update the DC<-->SM communication to use non-persistent connections

by John Bailey (JIRA)

Update the DC<-->SM communication to use non-persistent connections ------------------------------------------------------------------- Key: JBAS-8461 URL: https://jira.jboss.org/browse/JBAS-8461 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: John Bailey Assignee: John Bailey Fix For: 7.0.0.M1 -- 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, 9 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2010