October 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2720) Guvnor: In the about dialog the version and revision should be automatically up to date or removed. Make the version up to date and remove the revision.

by Geoffrey De Smet (JIRA)

Guvnor: In the about dialog the version and revision should be automatically up to date or removed. Make the version up to date and remove the revision. -------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2720 URL: https://jira.jboss.org/browse/JBRULES-2720 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 Priority: Optional Fix For: 5.2.0.M1 There's an old ANT script, revision-number.xml, which is commented out and a version.txt file to do this, But it hasn't been used in over a year apparently: - on trunk, the version.txt says "5.0.0.SNAPSHOT 25673M" -- The version is wrong 5.0.0.SNAPSHOT should be 5.2.0.SNAPSHOT -- The revision is wrong: the current revision is at least 10000 revisions higher - on branch 5.1.X it's the same "5.0.0.SNAPSHOT 25673M" I am removing the old ANT script and version.txt, replacing it with maven filtered properties, see drools/drools-guvnor/src/main/filtered-resources/org/drools/guvnor/client/messages/BuildConstants.properties Making the version up to date with ${pom.version}. Note: when you build from eclipse you might see ${pom.version} because eclipse doesn't support maven filtering, but any maven or hudson or release build will have the correct version filled in. Not adding the revision (yet?). If anyone wants this (QA maybe?), I can do that in the BuildConstants.properties too, with the buildnumber-maven-plugin. http://mojo.codehaus.org/buildnumber-maven-plugin/index.html but that plugin is beta, might slow down the build (network access) and by default it wants to have svn on command line (which doesn't work if your svn command line is out of date with the version used by your IDE), however there's a way to use javasvn instead apparently. -- 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

15 years, 7 months

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

15 years, 7 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

15 years, 7 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

15 years, 7 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

15 years, 7 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

15 years, 7 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

15 years, 7 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

15 years, 7 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

15 years, 7 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

15 years, 7 months

3
6
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 October 2010