February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4029) Endorsed directory not working but works with 4.0.5GA

by tony anecito (JIRA)

Endorsed directory not working but works with 4.0.5GA ----------------------------------------------------- Key: JBAS-4029 URL: http://jira.jboss.com/jira/browse/JBAS-4029 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Environment: Windows 2000 Professional JDK 1.6 JAXWS-2.1 Reporter: tony anecito When adding jars to the endorsed directory for JAXWS-2.1 seems servlet runner (TomCat) reports it is using JAXWS-2.0. I want to overide this with the JAXWS-2.1 and that works with 4.0.5GA. Following is clip from command console using beta1 21:10:44,781 INFO [ServiceEndpointManager] WebServices: jbossws-2.0.0.CR2.DEV date=200611171751) -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3548) RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures

by Matt Wringe (JIRA)

RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures -------------------------------------------------------- Key: JBAS-3548 URL: http://jira.jboss.com/jira/browse/JBAS-3548 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.4.GA Environment: Sun 1.5.0_08 JVM RHEL 4, Linux Kernel 2.6.9 Reporter: Matt Wringe The org.jboss.test.jmx.test.RMIAdaptorUnitTestCase testMBeanInfoMarshalling test fails on the Sun 1.5.0 JVM. >From the test report: "Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)" -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-426) Multiplexer: test concurrent processing

by Bela Ban (JIRA)

Multiplexer: test concurrent processing --------------------------------------- Key: JGRP-426 URL: http://jira.jboss.com/jira/browse/JGRP-426 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 4 unit tests: - Message M1 blocks for 10 seconds. Message M2 doesn't block and should get processed immediately #1 Sender A sends M1 to S1 and M2 to S1. M2 should wait until M1 is done #2 Sender A sends M1 to S1 and M2 to S2. M2 should get processed immediately and not have to wait for M1 to complete #3 Sender A sends M1 to S1 and sender B sends M2 to S1. M2 should get processed concurrently to M1 and should not have to wait for M1's completion #4 Sender A sends M1 to S1 and sender B sends M2 to S2. M1 and M2 should get processed concurrently -- 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, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-415) Asynchronous dispatching of messages in Multiplexer

by Brian Stansberry (JIRA)

Asynchronous dispatching of messages in Multiplexer --------------------------------------------------- Key: JGRP-415 URL: http://jira.jboss.com/jira/browse/JGRP-415 Project: JGroups Issue Type: Feature Request Reporter: Brian Stansberry Assigned To: Bela Ban Fix For: 2.5 With the multiplexer, it is fairly straightforward to have a situation where a problem one service is having handling a message prevents receipt by other services of messages from the problem message's sender. E.g., 3 servers, {A, B, C} all running 3 services S1, S2, S3 that share a mux channel. S1 is an instance of JBoss Cache. A.S1 sends a replication message to the cluster. On B, the thread carrying the message blocks waiting to acquire a lock in JBoss Cache. The ordering protocols in B's channel will prevent B.S2 and B.S3 receiving any further messages from A until the lock is acquired on S1 or the attempt times out. JGRP-176 could deal with this at the MessageDispatcher/RequestCorrelator level, but a simpler solution is to add asynchronous message handling in Multiplexer. A set of (bounded) queues is maintained in the Multiplexer, one per service. When messages arrive in Multiplexer.up(), the message is added to the queue, and the JGroups up thread returns. Multiplexer maintains a thread pool that reads messages off the queues and passes them up to the mux channel. The use of queues ensures the messages are received in FIFO order at the application level. It is still possible that one service could block others, if it's queue is full. We need to determine exactly how to size the queues -- i.e. based on number of bytes of queued messages, or based on number of messages. An application could then configure the size of its queue such that the queue shouldn't fill under expected load during any normal events (e.g. a JBC queue should be configured not to fill during the normal lock acquisition timeout.) -- 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, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-824) create annotations for home interface jndi bindings

by William DeCoste (JIRA)

create annotations for home interface jndi bindings --------------------------------------------------- Key: EJBTHREE-824 URL: http://jira.jboss.com/jira/browse/EJBTHREE-824 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: William DeCoste Assigned To: William DeCoste Fix For: EJB 3.0 RC10 - FD -- 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, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPM-705) Provide monitoring for standalone applications

by Ryan Campbell (JIRA)

Provide monitoring for standalone applications ---------------------------------------------- Key: JBPM-705 URL: http://jira.jboss.com/jira/browse/JBPM-705 Project: JBoss jBPM Issue Type: Feature Request Reporter: Ryan Campbell Assigned To: Tom Baeyens Fix For: jBPM 3.2 Provide jmx interfaces for monitor processes not in a webapp. Or can you point the monitoring webapp at a jBPM datastore? -- 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, 4 months

3
8
0 / 0

[JBoss JIRA] Created: (JBPM-742) Reimplement JbpmThreadsServlet as a ServletContextListener

by Alejandro Guizar (JIRA)

Reimplement JbpmThreadsServlet as a ServletContextListener ---------------------------------------------------------- Key: JBPM-742 URL: http://jira.jboss.com/jira/browse/JBPM-742 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1.1 Reporter: Alejandro Guizar ServletContextListeners are a viable alternative to servlets for management of the jBPM scheduler/command threads. From the Servlet 2.4 spec, section 10.2: >>> Servlet event listeners support event notifications for state changes in the ServletContext, HttpSession and ServletRequest objects. Servlet context listeners are used to **manage resources** or state held at a JVM level for the application. <<< Their intent definitely seems to match our purposes. Further below: >>> There may be multiple listener classes listening to each event type. <<< We could have separate listeners for the scheduler and command executor so that applications may remove either of them in case the related service is not used. Section 10.2.2 provides an example. When the application starts up, the listener creates a connection to the database and stores it in the servlet context. Servlets access the connection from the context as needed. When the application shuts down, the listener closes the connection. Our listener could start the thread and store it in the servlet context, then stop it using the mechanisms provided by JBPM-741. -- 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, 4 months

4
12
0 / 0

[JBoss JIRA] Created: (JBPM-811) sorted task lists

by Gavin King (JIRA)

sorted task lists ----------------- Key: JBPM-811 URL: http://jira.jboss.com/jira/browse/JBPM-811 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Gavin King Assigned To: Tom Baeyens JbpmContext.getTaskList() should allow sorting and filtering of the task list, by either priority, creation date, or type Something like Hibernate Criteria API makes sense: ctx.createTaskLiskQuery().orderByPriority().filterByType("approve document").getTaskList() Same facility should also exist for querying process definitions. -- 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, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPM-820) free choice of initial node type

by Tom Baeyens (JIRA)

free choice of initial node type -------------------------------- Key: JBPM-820 URL: http://jira.jboss.com/jira/browse/JBPM-820 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM 3.2 currently, you are forced to have a start-state to mark the initial node in your process-definition. i think it is a good idea to expand this so that any type of node could be the first node in the process. we already did this with SEAM. IMO, the most elegant way to achieve this is by adding an optional attribute 'initial' to the process-definition. the value must be a node name. when the initial node is specified as an attribute, the process should not have a start-state. the result is that with the initial attribute on the process-definition, any node type can be used as the start state. we would have to update the core engine new ProcessInstance(processDefinition) method. after creating the process instance and positioning the token in the initial node, the initial node has to be executed. now that is not the case. the initial node is not executed. because the start-state now has an empty implementation, this will be backwards compatible. -- 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, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-639) QuickOpen rule text box (autocomplete to bring up the name of a rule to open/view)

by Michael Neale (JIRA)

QuickOpen rule text box (autocomplete to bring up the name of a rule to open/view) ---------------------------------------------------------------------------------- Key: JBRULES-639 URL: http://jira.jboss.com/jira/browse/JBRULES-639 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 4 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 February 2007