January 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7596) Microcontainer does not always choose the right constructor when creating ModClusterService

by Paul Ferraro (JIRA)

Microcontainer does not always choose the right constructor when creating ModClusterService ------------------------------------------------------------------------------------------- Key: JBAS-7596 URL: https://jira.jboss.org/jira/browse/JBAS-7596 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-6.0.0.M1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: JBossAS-6.0.0.M2 A user encountered the following error when attempting to start EAP 5.0.0 w/mod_cluster 1.1.0.Beta1: 09:25:15,078 ERROR [AbstractKernelController] Error installing to Instantiated: name=ModClusterService state=Described mode=On Demand requiredState=Installed java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[org.jboss.modcluster.config.ModClusterConfig, org.jboss.modcluster.load.LoadBalanceFactorProviderFactory] actual=[org.jboss.modcluster.config.ha.HAModClusterConfig, org.jboss.modcluster.load.impl.DynamicLoadBalanceFactorProvider] at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395) The microcontainer is trying to instantiate ModClusterService using the wrong constructor. The mod_cluster-jboss-beans.xml should be updated to explicitly define the parameter types to remove this ambiguity. -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBOOT-117) Unify Module Release Cycle

by Andrew Lee Rubinger (JIRA)

Unify Module Release Cycle -------------------------- Key: JBBOOT-117 URL: https://jira.jboss.org/jira/browse/JBBOOT-117 Project: JBoss Bootstrap Issue Type: Task Components: api, api-as, api-embedded, api-mc, build, impl-as, impl-base, impl-embedded, impl-mc, main, spi, spi-as, spi-mc Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Experiments in ShrinkWrap and EmbeddedAS have proven successful, so unify the jboss-bootstrap release cycle such that all modules share a version within the tree. As it currently stands, modules such as spi-test have outdated versions configured, and end up testing artifacts that are not the current SNAPSHOTs, leading to a false sense of security. -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Updated: (GPD-376) candidate-groups info lost

by Koen Aers (JIRA)

[ https://jira.jboss.org/jira/browse/GPD-376?page=com.atlassian.jira.plugin... ] Koen Aers updated GPD-376: -------------------------- Fix Version/s: jBPM jPDL Designer 4.4 (was: jBPM jPDL Designer 4.3) > candidate-groups info lost > -------------------------- > > Key: GPD-376 > URL: https://jira.jboss.org/jira/browse/GPD-376 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Reporter: Joram Barrez > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.4 > > > When manually adding 'candidate-groups="administrator" ' to a task in the XML, this field is lost after having saved, gone back to the diagram and back to the xml. > Also the PNG is messed up. -- 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

16 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2397) DroolsCompilerAntTask.java assumes all dsl files will be located in the srcDir

by David Haskett (JIRA)

DroolsCompilerAntTask.java assumes all dsl files will be located in the srcDir ------------------------------------------------------------------------------ Key: JBRULES-2397 URL: https://jira.jboss.org/jira/browse/JBRULES-2397 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David Haskett Assignee: Mark Proctor The drools-Ant task currently assumes that all *.dsl files will be located in the srcDir Below, we use a combination of generated rules (using decision tables), and standard developer-written rules. When using rules resources from different locations, we need to specify the full path, relative to the srcDir. e.g. {code} <property name="compile_classpath" refid="maven.compile.classpath" /> <property name="plugin_classpath" refid="maven.plugin.classpath" /> <path id="taskCp"> <pathelement path="${compile_classpath}" /> </path> <taskdef name="rulebase" classname="org.drools.contrib.DroolsCompilerAntTask" classpathref="taskCp" /> <rulebase tofile="${project.build.outputDirectory}/rules/provider.knowledge" binformat="knowledge" bintype="knowledge" srcdir="${basedir}/" classpathref="ruleBase.classpath"> <include name="resources/application/rules/matching/provider.drl" /> <include name="resources/application/rules/matching/provider.rf" /> <include name="resources/application/rules/matching/providerAddress.dslr" /> <include name="target/generated-resources/drools-maven-plugin/rules/matching/providerRule.drl" /> </rulebase> {code} The srcdir is a parent of each of the paths above. When the DroolsCompilerAntTask class sees the .dslr file, it looks for its correspondong dsl file, assuming it to be in the srcdir. This may not always be the case. In the case above, it prevents us from using a combination of generated rules using decision tables, and dslr generated rules. There does not seem to be a workaround for this. A suggestion would be to have an extra parameter e.g. dsldir, which the DroolsCompilerAntTask class could use to determine the location of the dsl file? Thank you. -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-1729) JMS Topic::listAllMessages JMX operation returns empty list.

by Howard Gao (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1729?page=com.atlassian.ji... ] Howard Gao commented on JBMESSAGING-1729: ----------------------------------------- correction: in the above comment, 'The reason you can list" should be "The reason you can't list". > JMS Topic::listAllMessages JMX operation returns empty list. > ------------------------------------------------------------ > > Key: JBMESSAGING-1729 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1729 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.4.GA > Reporter: Ondrej Žižka > Assignee: Howard Gao > Fix For: 1.4.0.SP3.CP10, 1.4.6.GA.SP1, 1.4.7.GA > > > SSIA . Rep. steps: > 1) Create a topic (MyTopic) > 2) Send few durable messages to it (Ejb3TestApps can be used) > 3) Find the "name=MyTopic,service=Topic" Mbean > 4) Ensure that messages count is not zero > 5) Perform the listAllMessages operation > 6) See that the result is an empty list. > Tested with EAP 5 CR3, "all" config, default DB (HSQL) -- 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

16 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-1729) JMS Topic::listAllMessages JMX operation returns empty list.

by Howard Gao (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1729?page=com.atlassian.ji... ] Howard Gao closed JBMESSAGING-1729. ----------------------------------- Resolution: Rejected > JMS Topic::listAllMessages JMX operation returns empty list. > ------------------------------------------------------------ > > Key: JBMESSAGING-1729 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1729 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.4.GA > Reporter: Ondrej Žižka > Assignee: Howard Gao > Fix For: 1.4.0.SP3.CP10, 1.4.6.GA.SP1, 1.4.7.GA > > > SSIA . Rep. steps: > 1) Create a topic (MyTopic) > 2) Send few durable messages to it (Ejb3TestApps can be used) > 3) Find the "name=MyTopic,service=Topic" Mbean > 4) Ensure that messages count is not zero > 5) Perform the listAllMessages operation > 6) See that the result is an empty list. > Tested with EAP 5 CR3, "all" config, default DB (HSQL) -- 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

16 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-1729) JMS Topic::listAllMessages JMX operation returns empty list.

by Howard Gao (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1729?page=com.atlassian.ji... ] Howard Gao commented on JBMESSAGING-1729: ----------------------------------------- This is expected behavior. The reason you can list the messages because the messages are being delivered to the subscriber side. Unless you close the connection or the session. The amount of messages that JBM delivered to a consumer in one batch is controlled by PrefetchSize attribute of connection factory. default is 150. It can be set to as small as 1. Using default 150 value, the first time you need to send more than 200 messages to be able to see something returned by listAllMessages() if the consumer (subscriber)'s session and/or connection keeps open. I'll close this issue by rejecting it. > JMS Topic::listAllMessages JMX operation returns empty list. > ------------------------------------------------------------ > > Key: JBMESSAGING-1729 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1729 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.4.GA > Reporter: Ondrej Žižka > Assignee: Howard Gao > Fix For: 1.4.0.SP3.CP10, 1.4.6.GA.SP1, 1.4.7.GA > > > SSIA . Rep. steps: > 1) Create a topic (MyTopic) > 2) Send few durable messages to it (Ejb3TestApps can be used) > 3) Find the "name=MyTopic,service=Topic" Mbean > 4) Ensure that messages count is not zero > 5) Perform the listAllMessages operation > 6) See that the result is an empty list. > Tested with EAP 5 CR3, "all" config, default DB (HSQL) -- 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

16 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7589) Remove ejb3/build.xml

by jaikiran pai (JIRA)

Remove ejb3/build.xml --------------------- Key: JBAS-7589 URL: https://jira.jboss.org/jira/browse/JBAS-7589 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Build System, EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: JBossAS-6.0.0.M2 The ejb3/build.xml is no longer used. The configurations are now done in pom.xml. The build.xml needs to be deleted to avoid any confusion. -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7595) Investigate org.jboss.test.web.test.WebProgrammaticLoginTestCase failures

by Brian Stansberry (JIRA)

Investigate org.jboss.test.web.test.WebProgrammaticLoginTestCase failures ------------------------------------------------------------------------- Key: JBAS-7595 URL: https://jira.jboss.org/jira/browse/JBAS-7595 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Security, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M2 This is failing because some stuff in JaccContextValve wasn't ported from Branch_5_x -- the handling of ActiveRequestResponseValve.activeResponse. This results in an NPE. I'll have another look at the JBAS-7500 diff of the M1 tag vs trunk for the tomcat module to see if any other stuff wasn't ported. -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7376) Implement unit tests for the jpa2 and bean validation

by Scott Marlow (JIRA)

Implement unit tests for the jpa2 and bean validation ------------------------------------------------------ Key: JBAS-7376 URL: https://jira.jboss.org/jira/browse/JBAS-7376 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Scott Marlow Assignee: Scott Marlow Fix For: JBossAS-5.2.0.Beta1 Need something in AS to verify that JPA2 and BV are not broken -- 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

16 years, 4 months

2
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 January 2010