[ https://jira.jboss.org/jira/browse/JBIDE-3498?page=com.atlassian.jira.plu... ] John Graham updated JBIDE-3498: ------------------------------- Fix Version/s: LATER -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-3498?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-3498: ------------------------------------ Comments: The server's view does not need to be opened to find out what is published and what is not, or what the server state is. However, in order to initially start the server, you would have had to open one of the servers views ;) But it can be closed at any point. ServerCore in webtools has an API to listen to server state changes, publish, etc. When that part is reached I can explain the API to Denny. I don't know our tooling plugins have any dependency on FTP, or if there even *is* an ftp plugin we'd like to use or suggest. Without an FTP plugin in the toolset, the attempt to listen to an FTP end point are futile. As for listening to other JMS queues, that's a good idea, but only if there is some functionality exposed via JMX. Using JNDI directly to get a reference to the target queue / topic would require us to compile against JBoss jars (am i right? Let me know). This would be "bad". -- 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

[ https://jira.jboss.org/jira/browse/JBIDE-3498?page=com.atlassian.jira.plu... ] Jeff DeLong commented on JBIDE-3498: ------------------------------------ In reading the attached pdf I have a few comments: 7. Call mechanisms - should support: 1) inVM 2) ESB Aware client - this tests the queue/provider/listener configuration as well as the service itself 3) JMS Gateway 4) Web services - this later can now be done through other tools such as SoapUI, so it is not really necessary. however if it were easy to provide in a single test tool that would be nice. 8. Entering test data: 1. Typing directly into text box in test UI? Not sure how this would work. A service is expecting either Java objects or XML. For Java objects it seems like the user would have to first specify a Java class file, and then the UI would provide the text boxes to enter in data for this class. The ability to support multiple classes would be required. There are also subtleties as far as where the object are in the message (e.g., on the default location, in a named map, etc.) that could complicate this. -- 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