October 2010 - jboss-jira - Jboss List Archives

[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

14 years, 3 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

14 years, 3 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

14 years, 3 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

14 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBWEB-184) user X receive page for user Y

by Cyril Haller (JIRA)

user X receive page for user Y ------------------------------ Key: JBWEB-184 URL: https://jira.jboss.org/browse/JBWEB-184 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Environment: apache 2.2.3 + mod_proxy_ajp + jboss 4.2.3-GA Reporter: Cyril Haller Assignee: Remy Maucherat Sometimes, a user X to attempt to realize some a long action on the application receive an html page for a another user. This problem is very infrequent and so it's impossible to reproduce at any time. Maybe, this problem can comming from AJP?? Thanks. -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBAS-8483) errors injecting the Weld BeanManager.

by Marius Bogoevici (JIRA)

[ https://jira.jboss.org/browse/JBAS-8483?page=com.atlassian.jira.plugin.sy... ] Marius Bogoevici commented on JBAS-8483: ---------------------------------------- Nimo, Would you mind uploading an example for reproducing this? > errors injecting the Weld BeanManager. > -------------------------------------- > > Key: JBAS-8483 > URL: https://jira.jboss.org/browse/JBAS-8483 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M5 > Environment: jboss as 6 milestone 5 > Reporter: nimo stephan > Assignee: Marius Bogoevici > > The same weld-war does work in jboss as 6 milestone 4. Deploying it in jboss as 6 milestone 5 does work, only when invoking a bean, then weld throws exception: > (The full stacktrace can be seen here: http://community.jboss.org/thread/157055) > 10:57:33,719 SEVERITY [javax.enterprise.resource.webcontainer.jsf.application] javax.ejb.EJBException: java.lang.RuntimeException: Unable to inject jndi dependency: env/org.jboss.weld.integration.ejb.SessionBeanInterceptor/beanManager into property org.jboss.weld.integration.ejb.SessionBeanInterceptor.beanManager: MyWAR not bound: javax.faces.el.EvaluationException: javax.ejb.EJBException: java.lang.RuntimeException: Unable to inject jndi dependency: env/org.jboss.weld.integration.ejb.SessionBeanInterceptor/beanManager into property org.jboss.weld.integration.ejb.SessionBeanInterceptor.beanManager: MyWAR not bound > at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102) [:2.0.2-FCS] -- 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, 3 months

1
0
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

14 years, 3 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

14 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-8486) DataSourcePersistentManager error with FORM login

by Brian Stansberry (JIRA)

DataSourcePersistentManager error with FORM login ------------------------------------------------- Key: JBAS-8486 URL: https://jira.jboss.org/browse/JBAS-8486 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 6.0.0.CR1 Upstream issue for JBPAPP-5171 -- see that issue for further discussion. When using the DataSourcePersistentManager [1] to store web sessions, submitting a FORM login page results in a 408 error because the session is not found. The initial request for the protected resource sets the JSESSIONID cookie and returns the login form. But the session is not saved in the database, so submitting the form results in a 408 error. If the session already exists prior to the request for the protected resource, it works correctly. [1] http://community.jboss.org/wiki/HAWebSessionsviaDatabasePersistence -- 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, 3 months

1
1
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

14 years, 3 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 October 2010