May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4422) org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host

by Richard Achmatowicz (JIRA)

org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host ------------------------------------------------------------------ Key: JBAS-4422 URL: http://jira.jboss.com/jira/browse/JBAS-4422 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.2.0.CR2 Environment: x86, Windows 2003 , Sun and BEA JVM Reporter: Richard Achmatowicz Priority: Trivial 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. The command line built when executing on Windows is: > cmd /C twiddle get "jboss.system:type=Server" "Started" and the response should be "Started=true" It appears that twiddle had an option for specifying the server host, but this option has been commented out. When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available and the test fails. (please see the linked issue JBPAPP-176 for more details) -- 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, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-491) Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase

by Vladimir Blagojevic (JIRA)

Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase --------------------------------------------------------------------------------------- Key: JGRP-491 URL: http://jira.jboss.com/jira/browse/JGRP-491 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1, 2.5 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6 The idea behind MuxChannel state transfer listeners is to trigger all state transfers together and have all or none result for all registered MuxChannels. As currently implemented underlying plumbing with will trigger each transfer under *separate* FLUSH. In order to have it done under one flush we have to do manual flushing in Multiplexer (startFlush/stopFlush) for these transfers T and we should retrofit FLUSH protocol *not to* trigger flushing for each GET_STATE from T. We have two options: a) add requireFlush field in StateTransferInfo - that is then passed down with GET_STATE - this requires changing signature of JChannel.getState b) retrofit FLUSH to detect special handling of GET_STATE - at state requester A we record that we requested GET_STATE and if another GET_STATE arrives from A while channel is already flushed do not trigger another flush -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3658) Remote classloading service - Redesign

by Dimitris Andreadis (JIRA)

Remote classloading service - Redesign -------------------------------------- Key: JBAS-3658 URL: http://jira.jboss.com/jira/browse/JBAS-3658 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Remoting Reporter: Dimitris Andreadis Assigned To: Tom Elrod Fix For: JBossAS-4.0.6.CR1 We need to redesign the remote classloading service such that there is more control at the deployment layer on what is exposed. I will create a forum thread where this can be discussed in more detail. Requirement 1: Provide sensible defaults, which probably means no remote classloading by default Requirement 2: Individual deployments can choose whether remote classloading is enabled and what is available remotely Requirement 3: Allow "aspects" of the deployment to enhance what can be downloaded remotely, e.g. RMI/IIOP generated proxies or AOP remoting proxies Requirement 4: Use the spec defined RMIClassloaderSPI (exposed via an MBean) to make this configurable Requirement 5: Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that triggers the use of invokers to do remote classloading. -- 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, 11 months

3
7
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1148) SEAM / JSF / Portlet: Compatibility problem

by JP Barbe (JIRA)

SEAM / JSF / Portlet: Compatibility problem ------------------------------------------- Key: JBPORTAL-1148 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1148 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Portlet Affects Versions: 2.6.CR1 Environment: Windows XP MyFaces 1.1.5 SEAM 1.0.1 Reporter: JP Barbe Assigned To: Julien Viet When I use a seam tag into a jsf page, I have the following exception (You can see config files after the exception): 2006-11-30 17:20:57,934 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/seam-desk]] No active conversation context java.lang.IllegalStateException: No active conversation context at org.jboss.seam.core.Process.instance(Process.java:32) at org.jboss.seam.core.TaskInstance.instance(TaskInstance.java:51) at org.jboss.seam.contexts.BusinessProcessContext.getTaskInstance(BusinessProcessContext.java:213) at org.jboss.seam.contexts.BusinessProcessContext.get(BusinessProcessContext.java:51) at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:155) at org.jboss.seam.Component.getInstance(Component.java:1245) at org.jboss.seam.Component.getInstance(Component.java:1230) at org.jboss.seam.contexts.Lifecycle.resumeConversation(Lifecycle.java:328) at org.jboss.seam.jsf.AbstractSeamPhaseListener.restoreAnyConversationContext(AbstractSeamPhaseListener.java:42) at org.jboss.seam.jsf.SeamPortletPhaseListener.beforePhase(SeamPortletPhaseListener.java:51) at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.beforePhase(SeamExtendedManagedPersistencePortletPhaseListener.java:37) at org.apache.myfaces.lifecycle.LifecycleImpl.informPhaseListenersBefore(LifecycleImpl.java:520) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:342) at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:396) at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266) at com.eads.desk.core.portlet.DeskAccessPortlet.doView(DeskAccessPortlet.java:30) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133) #### Here is the faces-config.xml file: <faces-config> <lifecycle> <phase-listener> org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener </phase-listener> </lifecycle> <navigation-rule> <from-view-id>/view/deskAccess.jsp</from-view-id> <navigation-case> <from-outcome>trManager</from-outcome> <to-view-id>/view/viewTRManager.jsp</to-view-id> <redirect /> </navigation-case> </navigation-rule> <navigation-rule> <navigation-case> <from-action>#{pooledTask.assignToCurrentActor}</from-action> <from-outcome>taskAssignedToActor</from-outcome> <to-view-id>/view/viewTRManager.jsp</to-view-id> </navigation-case> </navigation-rule> </faces-config> #### web.xml: <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">  <listener> <listener-class>org.jboss.seam.servlet.SeamListener</listener-class> </listener> </web-app> ### I have seen an issue (Key: JBSEAM-347) but I don't anderstand the solution proposed or if a solution exists ! (http://jira.jboss.org/jira/browse/JBSEAM-347) Thanks. JP. -- 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, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (GPD-81) Add support for reconnecting transitions

by Ronald van Kuijk (JIRA)

Add support for reconnecting transitions ---------------------------------------- Key: GPD-81 URL: http://jira.jboss.com/jira/browse/GPD-81 Project: JBoss jBPM GPD Issue Type: Feature Request Components: jpdl Affects Versions: jBPM JPDL Designer 3.1.0.alpha4 Environment: Clean eclipse 3.2.2 and gpd 3.1alpha4 Reporter: Ronald van Kuijk Assigned To: Koen Aers Fix For: jBPM JPDL Designer 3.1.0.beta1 Not being able to reconnect transitions graphically from e.g. node a to node b is still a big omission for the gpd to be used by 'grey suites' as well as 'jeans and t-shirts', at least within our company. I thought there was a long standing issue for this, but I cannot find it. If someone could point me to a place to start looking into this, I'd be happy to try to implement this (but it will be the only gpd thing I 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

18 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (GPD-77) Need a way to initialize palette objects in GD 3.1

by John Ruud (JIRA)

Need a way to initialize palette objects in GD 3.1 -------------------------------------------------- Key: GPD-77 URL: http://jira.jboss.com/jira/browse/GPD-77 Project: JBoss jBPM GPD Issue Type: Feature Request Reporter: John Ruud Assigned To: Koen Aers For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175 It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the post) -- 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, 11 months

2
16
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-858) org.jboss.test.messaging.jms.bridge.ReconnectTest times out

by Ovidiu Feodorov (JIRA)

org.jboss.test.messaging.jms.bridge.ReconnectTest times out ----------------------------------------------------------- Key: JBMESSAGING-858 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-858 Project: JBoss Messaging Issue Type: Bug Reporter: Ovidiu Feodorov Assigned To: Tim Fox Fix For: 1.2.0.GA Temporarily commented out. -- 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, 11 months

2
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-693) Starting two node clusters simultaneously may end in failed messaging server node boot

by Ovidiu Feodorov (JIRA)

Starting two node clusters simultaneously may end in failed messaging server node boot -------------------------------------------------------------------------------------- Key: JBMESSAGING-693 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-693 Project: JBoss Messaging Issue Type: Bug Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta2 Tim Fox: 10:24:05,296 ERROR [DefaultClusteredPostOffice] Caught Exception in RequestHandler java.lang.IllegalStateException: Don't know about node id: 1 at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.addBindingFromCluster(DefaultClusteredPostOffice.java:597) at org.jboss.messaging.core.plugin.postoffice.cluster.BindRequest.execute(BindRequest.java:55) at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$PostOfficeRequestHandler.handle(DefaultClusteredPostOffice.java:2526) at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:602) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:623) at org.jgroups.blocks.RequestCorrelator.access -- 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, 11 months

6
11
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-750) Remove manually spawning of servers from runtest and build.xml

by Tim Fox (JIRA)

Remove manually spawning of servers from runtest and build.xml -------------------------------------------------------------- Key: JBMESSAGING-750 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-750 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Both runtest and tests/build.xml still use startrmiserver to start (and stop) remote servers prior (and after) to test run. The test framework now has the ability to start servers programmatically so this should be unnecessary. Removing it wil aid clarity of test scripts -- 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, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-697) Convert crash tests to use new server management framework

by Tim Fox (JIRA)

Convert crash tests to use new server management framework ---------------------------------------------------------- Key: JBMESSAGING-697 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-697 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 Now the testing framework supports the ability to kill and restart servers we should transfer the crash tests across to this new way of doing things -- 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, 11 months

3
4
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 May 2007