[ https://jira.jboss.org/jira/browse/JBDS-1172?page=com.atlassian.jira.plug... ] Gary Lamperillo updated JBDS-1172: ---------------------------------- Attachment: hang_myESBXML.png -- 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-6161?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-6161: --------------------------------------- Component/s: esb Fix Version/s: 3.1.1 Assignee: Brian Fitzpatrick Gary, could you give an example ? i don't get any "hangs" .. -- 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-6161?page=com.atlassian.jira.plu... ] Kevin Conner commented on JBIDE-6161: ------------------------------------- If this is the case then it is an issue with the ESB runtime and not the JBDS. It should not be necessary to add entries into dependencies.xml unless you are doing explicitly depending on something that is not part of the ESB, such as message queues or your own deployments etc. Can you create an ESB issue for this, attaching your specific .esb *deployment* (i.e. not JBDS project) and the resultant log file? -- 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-6161?page=com.atlassian.jira.plu... ] Gary Lamperillo commented on JBIDE-6161: ---------------------------------------- Kevin and David, Here is some more clarification on the issue: 1. quickstarts always deploy correctly and can start up during a fresh restart (run.sh), because the projects include deployment.xml files, which wait for the dependencies on restart. 2. When creating via JBDS, the user will not have the deployment.xml added, so the server hangs on restart of the server. The myESB Project, in this case does not have a deployment.xml. This leads to the tooling appearing as non-functional. This gives the developer a poor experience. Yes, they can add the deployment.xml, but this should be the value of using the tooling, it should be smart enough to take out the complexity of dealing with these intricacies. 3. Here is what I'm proposing: a. ESB Team provide a matrix that lists what items added to the esb.xml and the associated items that should be added to the deployment.xml to the ESB Tooling Team b. ESB Tooling Team modifies the ESB.xml tooling to dynamically adds/substracts entries to the deployment.xml as it is being modified. Here is a sample: ESB.xml item | Dependencies JMS Provider | jboss.esb.quickstart.destination:service=Queue,name=<Queue Names> SOAP Proxy | jboss.esb:deployment=soap.esb Regards, Gary -- 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-6161?page=com.atlassian.jira.plu... ] Gary Lamperillo updated JBIDE-6161: ----------------------------------- Attachment: myESB.esb -- 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-6161?page=com.atlassian.jira.plu... ] Gary Lamperillo commented on JBIDE-6161: ---------------------------------------- It seems to still be needed. I have attached the two projects(myJSR181 is a web service project which myESB is dependent on) without a deployment.xml in the myESB Project, it is hanging on the myESB Project. Here Is what you should see on startup: 15:44:06,707 INFO [TomcatDeployment] deploy, ctxPath=/myESB 15:44:06,724 WARNING [config] Unable to process deployment descriptor for context '/myESB' 15:44:06,724 INFO [config] Initializing Mojarra (1.2_13-b01-FCS) for context '/myESB' 15:44:06,815 INFO [ServiceInvoker] Service: sid:myService not found in the registry 15:44:06,852 INFO [EsbDeployment] Starting ESB Deployment 'slsb.esb' 15:44:06,868 INFO [EsbDeployment] Starting ESB Deployment 'smooks.esb' 15:44:07,057 INFO [SessionFactoryObjectFactory] Not binding factory to JNDI, no JNDI name configured 15:44:07,057 INFO [NamingHelper] JNDI InitialContext properties:{} 15:44:07,696 INFO [EsbDeployment] Starting ESB Deployment 'soap.esb' 15:44:07,712 INFO [EsbDeployment] Starting ESB Deployment 'myESB.esb' it will not return from this line... -- 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-6161?page=com.atlassian.jira.plu... ] Brian Fitzpatrick updated JBIDE-6161: ------------------------------------- Attachment: JbrEsb.esb Comments from Aaron Pestel: "Very sorry, I didn't read my own support case well enough. This was on SOA-P 4.3 CP02. I would have to create a different .esb to get the problem on SOA-P 5 since I think they removed the dependence of the JBR gateway on Smooks in SOA-P 5. I just tested this to make sure it still happens: 1.) Start SOA-P 4.3 CP02 "default" server and wait for it to come up 2.) Drop the JbrEsb.esb in the default/deploy directory 3.) Verify that it starts deploys successfully 4.) Stop the SOA-P server (leaving the .esb file in the deploy directory) 5.) Start the SOA-P server again 6.) Note that it gets an exception when trying to deploy the JbrEesb.esb that we just saw deploy successfully The problem is that the JbrEsb.esb is getting deployed (or maybe started) before jbossesb.esb, smooks.esb, etc. Now support said that's because the JbrEsb.esb doesn't declare dependencies on smooks.esb, etc. The problem is that if you look in the JbrEsb.esb file, you'll find there is nothing there about Smooks - so how would the JBDS user know to do that? The user won't know that the JBR Gateway implicitly depends on smooks (in SOA-P 4.3 CP02). My point is that since this ESB project (that created the .esb) was created in JBDS, probably JBDS should (could) have automatically added dependencies on the core .esb deployments since the user is not going to know that JBR (for example) implicitly depends on Smooks. This assumes that the support folks are right that this will fix the problem. Again, this is just one concrete manifestation. I didn't even follow through with the support case to see if adding a dependency.xml file to the project (ultimately .esb file) or not." -- 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-6161?page=com.atlassian.jira.plu... ] Brian Fitzpatrick updated JBIDE-6161: ------------------------------------- Attachment: server.log Kevin, here's a server.log from reproducing this issue using Aaron's steps on the SOA-P 4.3 instance. -- 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-6161?page=com.atlassian.jira.plu... ] Gary Lamperillo updated JBIDE-6161: ----------------------------------- Attachment: deployment.xml -- 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-6161?page=com.atlassian.jira.plu... ] Gary Lamperillo commented on JBIDE-6161: ---------------------------------------- actually, ignore my last comment, the deployment.xml was incorrect. It did not fix it. -- 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-6161?page=com.atlassian.jira.plu... ] Gary Lamperillo commented on JBIDE-6161: ---------------------------------------- the dependent war may be an issue, see https://jira.jboss.org/jira/browse/JBESB-2870 Kevin - since you have been involved with this. Maybe you can shed some like on it for us to the status. -- 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-6161?page=com.atlassian.jira.plu... ] Kevin Conner commented on JBIDE-6161: ------------------------------------- SOA-2037 covers the SOA 4.3 issue, this will be updated once scheduled. -- 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-6161?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-6161: --------------------------------------- Fix Version/s: 3.1.x 3.2.next (was: 3.1.1) btw. I completely agree that we should not be automatically adjusting deployment.xml as the first thing. 1) the runtime (esb) should be able to reduce maybe even elliminate the need for it 2) if we are able to actually figure out safely what should be added to dependency.xml then it should be done by validations/quickfixes not automagically edits to such a brittle file as deployment.xml and finally, most definitely not for 3.1.1 since it is only in specific cases (usage of smooks) which we currently can't easily detect. -- 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-6161?page=com.atlassian.jira.plu... ] Brian Fitzpatrick commented on JBIDE-6161: ------------------------------------------ Ok, and here's some additional comments from David Ward about this issue to further muddy the water... "But I must admit it was impossible for me to not peek at the contents of myESB.esb when it was attached to the jira. I won't dig into this more, but something did jump out at me, regarding the hanging: <action class="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy" name="myProxy"> <property name="wsdl" value="http://localhost:8080/myJSR181/order?wsdl"/> </action> This will not work. Not any fault of SOAPProxy, mind you, as on a restart Tomcat will simply NOT be listening yet. The http:// wsdl uri format was meant to be for wsdl that lives on other http servers. There are multiple KNOWN workarounds for this. The simplest is to include the .wsdl file itself in the .esb archive, and use a classpath:// wsdl uri, or you can drop it on the filesystem (not preferred) and use a file:// wsdl uri. However, the SUGGESTED mechanism when you're using JBossWS webservices is to use the internal:// wsdl uri. That, ALONG WITH the proper deployment dependency on the barrier service MBean Tom Fennelly created, should fix the hang problem. For example, check out the samples/quickstarts/webservice_proxy_basic quickstart... jboss-esb.xml (the wsdl value starts with "internal://" plus the full MBean name of the web service) ... <action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy"> <property name="wsdl" value="internal://jboss.ws:context=Quickstart_webservice_proxy_basic_ws,endpoint=HelloWorldWS"/> </action> ... wsbarrier-service.xml: <?xml version="1.0" encoding="UTF-8"?> <server> <mbean code="org.jboss.internal.soa.esb.dependencies.WSDeploymentBarrierController" name="jboss.esb:service=ProxyBasicHelloWorldWSBarrierController"> <attribute name="WsObjectName">jboss.ws:context=Quickstart_webservice_proxy_basic_ws,endpoint=HelloWorldWS</attribute> </mbean> </server> deployment.xml: <jbossesb-deployment> <depends>jboss.ws:context=Quickstart_webservice_proxy_basic_ws,endpoint=HelloWorldWS.Barrier</depends> </jbossesb-deployment> -- 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-6161?page=com.atlassian.jira.plu... ] Brian Fitzpatrick commented on JBIDE-6161: ------------------------------------------ So long story short, the ESB smooks fix (https://jira.jboss.org/jira/browse/SOA-2037) will be done for EAP 4.3 CP03 for the dependency issue. But there's a workaround for the SOAPProxy/wsdl property issue as David pointed out. -- 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-6161?page=com.atlassian.jira.plu... ] Brian Fitzpatrick commented on JBIDE-6161: ------------------------------------------ Yeah, that could potentially be a problem if it's demanding a value for the File attribute when it's not marked as required. Is that the case Gary, or is it complaining about the Name & WSDL fields, which are actually marked with the * noting them as required? -- 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-6161?page=com.atlassian.jira.plu... ] David Ward commented on JBIDE-6161: ----------------------------------- "2.using path just described: classpath://META-INF/MyWSDL.wsdl returns a null pointer." 3 slashes, not 2. Read here: http://community.jboss.org/thread/150227?tstart=0 -- 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-6161?page=com.atlassian.jira.plu... ] Brian Fitzpatrick commented on JBIDE-6161: ------------------------------------------ Gary, I'm open to suggestions for trying to improve this on the tooling side. The issues we have with trying to handle the multiple URL types here is that it's custom code. There's nothing in the ESB schema to aid us in presenting these options to the user. So anything we do will be bolted on and break should the ESB schema change release to release, which it does frequently. -- 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-6161?page=com.atlassian.jira.plu... ] Brian Fitzpatrick commented on JBIDE-6161: ------------------------------------------ Gary, what are we pursuing with the ESB team? If there are particular runtime issues, as alluded to by Kevin Conner earlier (https://jira.jboss.org/jira/browse/JBIDE-6161?focusedCommentId=12525293#a...), we need to report them as JBESB JIRAs. Otherwise we can chat about this all day in this bug and not get much done. :) -- 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/browse/JBIDE-6161?page=com.atlassian.jira.plugin.s... ] Brian Fitzpatrick resolved JBIDE-6161. -------------------------------------- Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBIDE-6161?page=com.atlassian.jira.plugin.s... ] Libor Zoubek closed JBIDE-6161. ------------------------------- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira