Community
Participate
Working Groups
The Web Services Explorer Web application should be capable of running outside of the Eclipse environment. Detailed requirements and design are forthcoming in a design document, a link to which will be appended to this defect.
I committed last night several changes to the Explorer that allow it to run outside of Eclipse for the purpose of interacting with UDDI registries. Work that remains: 1. The WSDL half of the Explorer is not working outside of Eclipse yet. 2. There are references to Eclipse API that still need to be designed out, particularly around the WSDL import/export functions. The Web Service Finder and WSDL Consumer frameworks should help us remove these. 3. The Explorer's "properties/favorites_default.wsil" file needs to be relocated from the plugin to the plugin's WAR, and logic needs to be added to make a copy of the file under the favorites metadata directory for all subsequent processing of favorites. 4. The location of the Explorer's favorites metadata directory must be passed in via a URL parameter when the Explorer is running without Eclipse. If this parameter is omitted, the Explorer does not react nicely. The Explorer should detect this missing property and either prompt the user via a new, simple Web page to enter the location of the favourites directory, or infer a reasonable directory from the servlet container.
Created attachment 20515 [details] Windows batch script to copy jars from Eclipse required by WSExplorer
Created attachment 20516 [details] Default Tomcat 4.1.31 server.xml plus Context element for WSExplorer
For anyone who wishes to run the Web Services Explorer from Eclipse WTP M4 but outside of the Eclipse IDE, the following instructions and attachments should help. As noted in earlier comments, support for UDDI appears to be functioning in the standalone WSExplorer (vs. when run inside Eclipse), whereas support for WSDL invocation is NOT functioning in the standalone WSExplorer (vs. when run inside Eclipse). Convenient, eh? 1. Unzip M4 somewhere, and set M4 to its "plugins" directory Eg. SET M4=C:\wtp-sdk-1.0M4\eclipse\plugins 2. Unzip Tomcat somewhere, and set CATALINA_HOME to its home directory Eg. SET CATALINA_HOME=C:\jakarta-tomcat-4.1.31 3. Change to %CATALINA_HOME%\webapps. a. Create new directory "wsexplorer". 4. Change to %CATALINA_HOME%\webapps\wsexplorer. a. Unzip %M4%\org.eclipse.wst.ws.explorer_1.0.0\wsexplorer.war 5. Change to %CATALINA_HOME%\webapps\wsexplorer\WEB-INF\lib. a. Run the attached wsejars.bat script to copy several required jars* from Eclipse WTP M4. Eg. wsejars %M4% 6. Add the following element to %CATALINA_HOME%\conf\server.xml for the Web Services Explorer, or use the attached server.xml. <Context path="/wsexplorer" docBase="wsexplorer" debug="0"/> 7. Run Tomcat. Eg. %CATALINA_HOME%\bin\catalina run 8. Create a temporary directory for the Web Services Explorer to use. Eg. C:\wsexplorer 9. Start your browser and enter the following URL: http://localhost:8080/wsexplorer/wsexplorer.jsp? stateLocation=C:\wsexplorer&defaultFavoritesLocation=C:\wtp-sdk-1.0M4 \eclipse\plugins\org.eclipse.wst.ws.explorer_1.0.0 \properties\favorites_default.wsil Take note of the two required URL parameters above: stateLocation Set this to the temporary directory you created in step [8]. defaultFavoritesLocation Set this to the install location of M4 from step [1] suffixed by the relative path to the Web Services Explorer's "favorites" file: org.eclipse.wst.ws.explorer_1.0.0\properties\favorites_default.wsil * Required jars: org.eclipse.wst.ws.explorer_1.0.0\explorer.jar org.eclipse.wst.ws.parser_1.0.0\parser.jar org.eclipse.wst.ws_1.0.0\ws.jar org.eclipse.wst.wsdl_1.0.0\wsdl.jar org.wsdl4j_1.0.0\lib\qname.jar org.uddi4j_1.0.0\lib\uddi4j.jar org.apache.wsil4j_1.0.0\lib\wsil4j.jar org.apache.axis11_1.1.0\lib\axis-ant.jar org.apache.axis11_1.1.0\lib\axis.jar org.apache.axis11_1.1.0\lib\commons-discovery.jar org.apache.axis11_1.1.0\lib\commons-logging.jar org.apache.axis11_1.1.0\lib\jaxrpc.jar org.apache.axis11_1.1.0\lib\log4j-1.2.8.jar org.apache.axis11_1.1.0\lib\saaj.jar org.apache.axis11_1.1.0\lib\wsdl4j.jar org.eclipse.emf.common_2.1.0\runtime\common.jar org.eclipse.emf.common_2.1.0\runtime\common.resources.jar org.eclipse.emf.ecore_2.1.0\runtime\ecore.jar org.eclipse.emf.ecore_2.1.0\runtime\ecore.resources.jar org.eclipse.xsd_2.1.0\runtime\xsd.jar org.eclipse.xsd_2.1.0\runtime\xsd.resources.jar org.eclipse.core.resources_3.1.0\resources.jar org.eclipse.wst.common.emf_1.0.0\runtime\workbench.jar org.eclipse.core.runtime_3.1.0.jar
This doesn't need to be completed in M5. M6 will do. Note that the bulk of this enhancement is done, and most of what's left is getting WSDL exploration and invocation to work standalone.
*** Bug 107130 has been marked as a duplicate of this bug. ***
Targetting M10.
Summary of investigation / changes remaining: 1. Solve the mystery of WSDL invocation not working in standalone mode. 2. Provide a new, simple Export wizard that deposits a modified copy of wsexplorer.war into the filesystem or workspace at a location of the user's choice. This amounts to copying wsexplorer.war from within the org.eclipse.wst.ws.explorer plugin to a location in the filesystem of the user's choosing, and inserting the necessary jars identified in 89101. This would remove the need for step #5 in 89101. 3. Remove step #8, the requirement to manually create a temporary directory. 4. In step #9, make the "stateLocation" URL parameter optional. If omitted, the WSE should pick a reasonable temporary directory, such as the value of the java.io.tmpdir property. 5. In step #9, make the "defaultFavoritesLocation" URL parameter optional. The favorites_default.wsil file should be relocated within the WAR (ie. under the plugin's wsexplorer/ folder) and automatically copied to the "stateLocation" directory unless it already exists there.
Deferring enhancements to WTP 1.5 per the memo "Achieving WTP 1.0 Quality Targets" by Arthur Ryman [1]. Only item 1 from comment 8, "Solve the mystery of WSDL invocation not working in standalone mode.", should we consider doing for WTP 1.0. If we come up with a solution to that item, we'll open a separate bug targetted to M10 to track it. [1] http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg02831.html
changing target from 1.5 M1 to 1.5 M5 to reflect new numbering system as we join Collisto.
Probably can't be contained in M5 due to other fixes/RFEs that are more important for the M5 milestone. Retargetting to M6.
Definitely can't be contained in WTP 1.5 due to other high priority fixes/RFEs. Clearing target until we're certain of a release in which we can implement this.
I am trying to run web services explorer outside eclipse and till now i don't have luck running it successfully. I followed the steps mentioned in this bug but the code version are different. (wtp 1.5, tomcat 5.5) . I am gettng following error. Does any body has any idea of what i am doing wrong. Thanks Sreedhar exception:WSDLException: faultCode=OTHER_ERROR: java.lang.NullPointerException at org.eclipse.xsd.impl.XSDSchemaDirectiveImpl.resolve(XSDSchemaDirectiveImpl.java:373) at org.eclipse.xsd.impl.XSDIncludeImpl.patch(XSDIncludeImpl.java:233) at org.eclipse.xsd.impl.XSDConcreteComponentImpl.patch(XSDConcreteComponentImpl.java:526) at org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java:1505) at org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchemaImpl.java:2335) at org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDConcreteComponentImpl.java:1240) at org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSchemaImpl.java:829) at org.eclipse.wst.wsdl.util.WSDLResourceImpl.doLoad(WSDLResourceImpl.java:253) at org.eclipse.wst.wsdl.util.WSDLResourceImpl.doLoad(WSDLResourceImpl.java:282) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094) at org.eclipse.wst.wsdl.internal.impl.wsdl4j.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:195) at org.eclipse.wst.ws.internal.parser.wsil.WebServicesParser.getWSDLDefinitionVerbose(WebServicesParser.java:230) at org.eclipse.wst.ws.internal.explorer.platform.wsdl.datamodel.WSDLElement.loadWSDL(WSDLElement.java:130) at org.eclipse.wst.ws.internal.explorer.platform.wsdl.datamodel.WSDLElement.loadWSDL(WSDLElement.java:153) at org.eclipse.wst.ws.internal.explorer.platform.wsdl.actions.OpenWSDLAction.run(OpenWSDLAction.java:60) at org.eclipse.wst.ws.internal.explorer.platform.engine.ActionEngine.executeAction(ActionEngine.java:221) at org.eclipse.wst.ws.internal.explorer.platform.actions.Action.execute(Action.java:111) at org.eclipse.wst.ws.internal.explorer.platform.actions.Action.execute(Action.java:105) at wsdl.actions.OpenWSDLActionJSP_jsp._jspService(Unknown Source) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
Sreedhar, are you trying to use the WSE (standlone) to publish/discovery with UDDI, or to explore/invoke WSDL? From the stack trace it looks like the latter. If that's true, note per comment 4 that we didn't have WSDL invocation working in the standalone WSE back on WTP 1.0. Only the UDDI paths worked. In other words, I don't think you're doing anything wrong, bearing in mind that the versions of the dependency jars listed at the end of comment 4 have changed in WTP 1.5.x. You may simply be trying to drive the standalone WSE thru a scenario known to fail and that we have not had the bandwidth to tackle yet.
Back in WTP 2.0, we had added an Eclipse extension point in the WSE when we implemented RFE 176493 (WSE: Make message/transport stack pluggable - https://bugs.eclipse.org/bugs/show_bug.cgi?id=176493). In addition, the move from Tomcat to Jetty requires the WSE to be packaged as an Eclipse plugin to run in the Jetty engine. With these two recent development, running the WSE outside of Eclipse is even harder to achieve. So I think we would just be shelfing that idea for now. We could revisit that decision if we feel that there is significant demand from the community for this feature to justify re-opening the issue.
If this issue is ever re-opened, what's required when embedding in an app server is to factor out the launching of an instance of the Jetty Http Service and just use the existing service provided by the servletbridge. A similar effort was done for infocenter.
Thanks Kathy. I'm good with closing this out.
