April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-469) Set SFC.control_unicast via a config event

by Brian Stansberry (JIRA)

Set SFC.control_unicast via a config event ------------------------------------------ Key: JGRP-469 URL: http://jira.jboss.com/jira/browse/JGRP-469 Project: JGroups Issue Type: Sub-task Reporter: Brian Stansberry Assigned To: Bela Ban See parent task for meaning of SFC.control_unicast. TP impl should be able to send a config event up the stack to indicate if a TCP-based config is used. If such a config event is received, control_unicast should be set to false automatically. Separated this from the parent task as it's not needed for 2.4.1.SP2. -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4155) run.conf used from other scripts than run.sh

by Tobias Frech (JIRA)

run.conf used from other scripts than run.sh -------------------------------------------- Key: JBAS-4155 URL: http://jira.jboss.com/jira/browse/JBAS-4155 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.0.5.GA Environment: Linux/Unix Reporter: Tobias Frech Priority: Minor Configuration in run.conf is used from other scripts than run.sh. For example shutdown.sh or twiddle.sh include it. They should not because that leads to undesireable or even dangeous effects. Details: Editing run.conf an including JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y" to enable remote debugging Starting the server: sh run.sh -c minimal Stopping the server produces: sh shutdown.sh -S ERROR: transport error 202: bind failed: Address already in use ["transport.c",L41] ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L497] JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initializedFATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113) This may get worse if someone uses a -Xms3000m setting on a server that only has 4GB of memory. Potentially leading to a swap out of a production system to disk. -- 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
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-949) Bean proxy in JNDI not properly refreshed when cluster topology changes

by Brian Stansberry (JIRA)

Bean proxy in JNDI not properly refreshed when cluster topology changes ----------------------------------------------------------------------- Key: EJBTHREE-949 URL: http://jira.jboss.com/jira/browse/EJBTHREE-949 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.0 CR2, EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: AS 4.2.0 GA When a change to the cluster topology occurs, the proxies in JNDI for the affected beans are not being updated. Effect is the target list in the proxy always contains the members that were present when the bean was deployed and the proxy created. EJB2 has a process to rebind the proxy when a topology change occurs; EJB3 probably needs something similar. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-800) Move conways game of life to a stateful example

by Mark Proctor (JIRA)

Move conways game of life to a stateful example ----------------------------------------------- Key: JBRULES-800 URL: http://jira.jboss.com/jira/browse/JBRULES-800 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m2 Conways game of life still has a lot of logic in java and works statefully, so a lot of repopulating of data. Should re-work the example to be stafeful, initially using agenda-groups and then move it to rule-flow, so that we have a good rule-flow example. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-827) in an enterprise appln where thousands of rules are there, how can we load the drls and for specified request how to load specified drl

by dibyananda senapati (JIRA)

in an enterprise appln where thousands of rules are there, how can we load the drls and for specified request how to load specified drl ---------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-827 URL: http://jira.jboss.com/jira/browse/JBRULES-827 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Affects Versions: 3.0.4 Reporter: dibyananda senapati Assigned To: Mark Proctor how can we implement drools in enterprise appln. Should we load all the entire drl files before the appln starts or we should dynamically load the drl. please suggest and provide me the code -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-435) Large integer values in decision tables are converted to scientific notation in DRL which cannot be parsed

by Volker Augustin (JIRA)

Large integer values in decision tables are converted to scientific notation in DRL which cannot be parsed ---------------------------------------------------------------------------------------------------------- Key: JBRULES-435 URL: http://jira.jboss.com/jira/browse/JBRULES-435 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Decision tables, Drl Parser/Builder Reporter: Volker Augustin Assigned To: Mark Proctor When a condition column in a decision table contains values like 25000000, this is compiled using the SpreadsheetCompiler into 2.5E7 in the DRL. However, the DRL parser/compiler cannot cope with this notation and exists with a unexpected token "E7" error message. -- 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
3
0 / 0

[JBoss JIRA] Created: (JBRULES-434) Cannot enter more than one parameter in one column on German computers

by Volker Augustin (JIRA)

Cannot enter more than one parameter in one column on German computers ---------------------------------------------------------------------- Key: JBRULES-434 URL: http://jira.jboss.com/jira/browse/JBRULES-434 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Decision tables Environment: Windows XP, standard GERMAN settings Reporter: Volker Augustin Assigned To: Mark Proctor Section 4.1.4.1 of the JBoss Rules documentation states: The "$para" place holder is used in templates to indicate where data form the cell will be interpolated. You can also use "$1" to the same effect. If the cell contains a comma seperated list of values, $1 and $2 etc. may be used to indicate which positional parameter from the list of values in the cell will be used. As the German decimal separator is ',' and not '.' as in the English locale, no list of this form can be entered on a German computer system if there are e.g. only two values and they happen to be integers. E.g. if you try to create the list containing the two values 10 and 20, according to the documentation you must enter '10,20'. This will be interpreted as 10.20 by a German computer and result in a single decimal value instead of a list of two integers. The separator ',' is hardcoded somewhere (in SnippedBuilder (?) I think). Maybe this can be made configurable. E.g. a "Configuration" section in the Excel spreadsheet would 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, 2 months

5
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-950) Incorrect signatures for EJB3 APIs

by Shelly McGowan (JIRA)

Incorrect signatures for EJB3 APIs ----------------------------------- Key: EJBTHREE-950 URL: http://jira.jboss.com/jira/browse/EJBTHREE-950 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 CR2 Reporter: Shelly McGowan The following differences were detected in the JBoss EJB3 API signatures in Branch_4_2 and trunk (5.0.0) according to the EJB3 API Javadoc located at: http://java.sun.com/javaee/5/docs/api/ javax.ejb.ActivationConfigProperty: No Target or Retention Policy defined Defined as: class abstract public interface !annotation javax.ejb.ActivationConfigProperty Should be defined: javax.ejb.ActivationConfigProperty: class abstract public interface !annotation javax.ejb.ActivationConfigProperty anno 0 java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy value=RUNTIME) anno 0 java.lang.annotation.Target(java.lang.annotation.ElementType[] value=[]) ---------------------- javax.ejb.EJB: Target value includes PARAMETER anno 0 java.lang.annotation.Target(java.lang.annotation.ElementType[] value=[METHOD, TYPE, FIELD, PARAMETER]) should only be: anno 0 java.lang.annotation.Target(java.lang.annotation.ElementType[] value=[TYPE, METHOD, FIELD]) ---------------------- javax.ejb.Init: Defined as: method abstract public !hasdefault java.lang.String[] value() Should be: method abstract public !hasdefault java.lang.String value() -------------------------- javax.ejb.AccessMode This is obsolete and should be removed. ------------------------------------------ javax.ejb.SessionContext: Defined as: public Object getBusinessObject(Class businessInterface) throws IllegalStateException; Should be defined: <T> T getBusinessObject(Class<T> businessInterface) throws IllegalStateException; ------------------------------------------ javax.ejb.EJBAccessException: Constructors for EJBAccessException should be: public EJBAccessException() public EJBAccessException(String message) JBoss implementation has an additional constructor: public javax.ejb.EJBAccessException(String message, Exception ex) ------------------------------------------ javax.ejb.EJBTransactionRolledbackException: Constructors for EJBTransactionRolledbackException should be: public EJBTransactionRolledbackException() public EJBTransactionRolledbackException(String message) public EJBTransactionRolledbackException(String message, Exception ex) The JBoss implementation has an additional constructor: public EJBTransactionRolledbackException(Exception ex) ---------------------------------------------------- -- 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
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.

by Joel Lindheimer (JIRA)

Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary. ---------------------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-520 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Affects Versions: 1.0.1.CR4 Environment: Windows XP, JBossServer4.0.4GA, Oracle10G Reporter: Joel Lindheimer Assigned To: Ovidiu Feodorov Create a simple receiver, but do not place it within a Transaction boundary; shut down the server; look up the tables and you will see all the messages are still in the Messages and MessageRef tables. ========================================= Observations using a debbuger reveal the following: ========================================= Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method will always call createXAQueueSession() and create an XAQueconnection as transacted and Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion problems with the current version (RC4) because the API removes all messages that are "not transacted and (!ack==1). I am guessing that using XA is problematic because the persistence layer is expecting manipulation of the transacted XASession--which for some reason is not working in this version of Messaging. More specifically, I suspect that when MDBs are tested you are not seeing this problem because the container is doing needed magic to manage the XASession transacted state, and therefore everything works fine therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver, there is something missing in the equation ergo the problems that I have been reporting regarding the ClickCommerce applications which use Receivers and not MDBs. Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while waiting for a fix. -- 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

5
11
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1363) java.lang.NullPointerException for Users Role after deleting demo Test page

by William Byrne (JIRA)

java.lang.NullPointerException for Users Role after deleting demo Test page --------------------------------------------------------------------------- Key: JBPORTAL-1363 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1363 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.CR1 Environment: Win XP SP2, PostgreSQL 8.2, postgresql-8.2-505.jdbc3.jar, jboss-portal-2.6-CR1-bundled.zip Reporter: William Byrne Assigned To: Sohil Shah Both PGSQL and JBossPortal are clean installations. Problem exhibited with both PGSQL 8.1 and 8.2. Problem does NOT show up with HSQLDB script.. 1) Clean install of PGSQL DB 2) Clean install of JBossPortal bundle configured for PGSQL using "portal-postgresql-ds.xml" 3) Run portal 4) Login as admin 5) Delete Test page under default portal 6) Logout 7) Login as user java.lang.NullPointerException shown in center portal region. Will attach complete log file. Refer to: 2007-04-28 04:02:49,339 ERROR [STDERR] java.lang.NullPointerException -- 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

2
2
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 April 2007