January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-640) Eliminate duplication of deployment descriptors across repositories (Messaging and AS)

by Ovidiu Feodorov (JIRA)

Eliminate duplication of deployment descriptors across repositories (Messaging and AS) -------------------------------------------------------------------------------------- Key: JBMESSAGING-640 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-640 Project: JBoss Messaging Issue Type: Sub-task Components: Build System Affects Versions: 1.2.0.Alpha2, 1.0.1.GA Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR1 To quickly complete integration with JBAS5, I've copied JBoss-specific deployment descriptors accross repositories. remoting-service.xml, connection-factories-service.xml, messaging-service.xml, hsqldb-persistence-service.xml, destinations-service.xml, jms-ds.xml, as well as messaging-users.properties and messaging-roles.properties are duplicated in both https://svn.jboss.org/repos/messaging/src/etc/server/default/deploy and https://svn.jboss.org/repos/jbossas/messaging/src/etc/deploy. Find a solution that would allow maintaining only one copy (SVN links?) -- 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

18 years, 10 months

4
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-854) JMX Management rationalization

by Brian Stansberry (JIRA)

JMX Management rationalization ------------------------------ Key: JBCACHE-854 URL: http://jira.jboss.com/jira/browse/JBCACHE-854 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.GA In 2.0 JBC no longer inherits from the AS's ServiceMBeanSupport class, and JMX registration is handled differently. This is a parent task for sorting out issues related to JMX in this new environment. -- 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

18 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-546) Please implement "collect( ... ) from" functionality

by Dirk Bergstrom (JIRA)

Please implement "collect( ... ) from" functionality ---------------------------------------------------- Key: JBRULES-546 URL: http://jira.jboss.com/jira/browse/JBRULES-546 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Dirk Bergstrom Assigned To: Mark Proctor I need to count the number of sub-objects that meet various criteria. As an example, suppose I have several hundred Town objects, each of which has a list of perhaps a few hundred Person objects. I need to write rules like: "Find all the towns that have more than three disabled people with incomes over $100K." "For each town with more than 1000 residents that has more than 50 poor children under the age of 8, add a teacher for every 25 children." I'm shaky on JBR syntax, but I think those would translate to something like: rule "disabled" when ArrayList(size > 50) from collect( Person( disabled == "yes", income > 100000 ) from town.getPersons() ) then //do stuff end rule "teachers" when town : Town( population > 1000 ) count : Arraylist from collect( Person( disabled == "yes", income > 100000 ) from town.getPersons() ) count( size > 50 ) then town.addTeachers(count.size() / 25) end (I'm not really working with towns and people, but it makes for easily understood examples) -- 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

18 years, 10 months

5
6
0 / 0

[JBoss JIRA] Created: (JBRULES-543) Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS

by Sridhar Chandrasekharan (JIRA)

Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS ---------------------------------------------------------------------------------------- Key: JBRULES-543 URL: http://jira.jboss.com/jira/browse/JBRULES-543 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Sridhar Chandrasekharan Assigned To: Mark Proctor Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS. Jess has a (halt) command which allows a rule to specify that rule execution should be stopped. I could find no such command in JBoss rules. -- 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

18 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4032) Restore jboss.partition.name property replacement in clustering beans.xml files

by Brian Stansberry (JIRA)

Restore jboss.partition.name property replacement in clustering beans.xml files ------------------------------------------------------------------------------- Key: JBAS-4032 URL: http://jira.jboss.com/jira/browse/JBAS-4032 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta2 Pending completion of JBMICRONTAINER-143, I removed syntax from like the following from the clustering -beans.xml files: <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=HASingletonDeploymentScanner,partitionName=${jboss.partition.name:DefaultPartition}", exposedInterface=org.jboss.ha.singleton.HASingletonDeploymentScannerMBean.class, registerDirectly= true)</annotation> This task is a reminder to restore it once the microcontainer issue is resolved. -- 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

18 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-692) Create extended RunAs roles for additional mapped principals

by Bill Burke (JIRA)

Create extended RunAs roles for additional mapped principals ------------------------------------------------------------ Key: EJBTHREE-692 URL: http://jira.jboss.com/jira/browse/EJBTHREE-692 Project: EJB 3.0 Issue Type: Task Reporter: Bill Burke Fix For: EJB 3.0 RC10 - FD See the TODO in RunAsSecurityInterceptorFactory -- 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

18 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-702) Quartz Timer Service in E-EJB3 hangs process, exception on shutdown

by Bill Burke (JIRA)

Quartz Timer Service in E-EJB3 hangs process, exception on shutdown ------------------------------------------------------------------- Key: EJBTHREE-702 URL: http://jira.jboss.com/jira/browse/EJBTHREE-702 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Bill Burke Assigned To: Carlo de Wolf Fix For: EJB 3.0 RC10 - FD to test this out: build embedded.dist go run one of the tutorials. You will see that the applicatoin will never exit. I'm guessing this is becuase a Quartz thread is a non-daemon thread and holding up the exit of the process. Also there is a NullPointerException on shutdown. I have disabled the Quartz Timer Service in embedded-jboss-beans.xml for now. -- 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

18 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-780) dlqmaxresent parameter is not taken from main jboss config

by Ramil Israfilov (JIRA)

dlqmaxresent parameter is not taken from main jboss config ---------------------------------------------------------- Key: EJBTHREE-780 URL: http://jira.jboss.com/jira/browse/EJBTHREE-780 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Reporter: Ramil Israfilov Fix For: EJB 3.0 RC10 - FD During tests recovered JMS message goes immediatelly to DQL queue, in standardjboss.xml file dlqmaxresent parameter is set to 10, but it is not used. If I put this property in MDB as annotation it works, but I don't want to put it there as it is a parameter which can be set on jboss config. -- 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

18 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-779) MDB doesn't rebind after JBOSS MQ recover

by Ramil Israfilov (JIRA)

MDB doesn't rebind after JBOSS MQ recover ------------------------------------------ Key: EJBTHREE-779 URL: http://jira.jboss.com/jira/browse/EJBTHREE-779 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: EJB 3.0 RC9 - FD Environment: Solarisx86, JDK1.5_06 Reporter: Ramil Israfilov Priority: Critical Fix For: EJB 3.0 RC10 - FD I have an MDB which is described using annotations: @Depends("jboss.mq:service=JMSProviderLoader,name=HAJNDIJMSProvider") @MessageDriven(name = "EJBExecutorMDB", activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/certione/ExecutorQueue"), @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "AUTO_ACKNOWLEDGE"), @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "4"), @ActivationConfigProperty(propertyName = "dLQMaxResent", propertyValue = "4"), @ActivationConfigProperty(propertyName = "SubscriptionDurability", propertyValue = "Durable") }, messageListenerInterface=MessageListener.class) public class EJBExecutorMDB implements MessageListener { ... } I deploy it in clustered environment with HAJNDI and clustered JBOSS MQ. So far so good. Then cluster node on which JBOSS MQ is running crashed MDB is not rebind. >From log file I see that JBOSS MQ successfully restarted on second node. And all permamnet queue destinations (defined in config files) are available, but destinations which are defined in annotations don't exist. And in log file I see that server constantly tries bind MDB, but got alway the same error: javax.naming.NameNotFoundException: queue/certione/ExecutorQueue at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:242) at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:155) at sun.reflect.GeneratedMethodAccessor140.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:258) at $Proxy249.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.jboss.util.naming.Util.lookup(Util.java:215) at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDestination(JmsActivation.java:399) at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:306) at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:250) at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.onException(AbstractDLQHandler.java:94) at org.jboss.mq.Connection$ExceptionListenerRunnable.run(Connection.java:1348) at java.lang.Thread.run(Thread.java:595) -- 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

18 years, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (JBRULES-395) drools-repository API

by Michael Neale (JIRA)

drools-repository API --------------------- Key: JBRULES-395 URL: http://jira.jboss.com/jira/browse/JBRULES-395 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Reporter: Michael Neale Assigned To: Michael Neale This is the parent task for the drools-repository module and API. This covers the back end storage, using JCR, and the API over it (not the front end). All specific tasks should be sub tasks of this. -- 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

18 years, 10 months

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