Bugzilla – Full Text Bug Listing
| Summary: | Evaluate possibilities for adding support for remote launching | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Gabriel Petrovay <gabipetrovay> |
| Component: | WTP Incubator | Assignee: | Project Inbox <wtp.inc.xquery-inbox> |
| Status: | NEW --- | QA Contact: | XQDT <xqdt> |
| Severity: | normal | ||
| Priority: | P3 | CC: | azerr, d_a_carver, sam.neth, villard |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Gabriel Petrovay
Removed at posters request by Webmaster Removed at posters request by Webmaster My response to Angelo's e-mail was: --------------------------------------------- Hi Angelo, Thanks your your e-mail. I have looked over the proposed solution and the solution works but I think there is a cleaner solution (although a little more complex) to integrate your RunnableProcess into the IInterpreterRunner. This solution I try to explain below: 1. DLTK has the notion of "execution environments" (org.eclipse.dltk.core.environment.IExecutionEnvironment). Both MarkLogic and your use case are not suitable for a LocalExecEnvironment for a series of reasons raging from UI to Lunching and Debug functionality. Therefore this brings again the need of a "RemoteExecEnvironment" which is unfortunately not available in DLTK (at least DLTK 1.0, but it's worth to search for it in DLTK 2.0). This will solve the java.lang.Process problem in an elegant manner. But you have to come up with the RemoteExecEnvironment code. This implies that that an IEnvironment also needs to be coded, probably RemoteEnvironment, just like org.eclipse.dltk.core.internal.environment.LocalEnvironment. To define a new environment, you must use the "org.eclipse.dltk.core.environment" extension point. 2. DebugPlugin.newProcess can be extended with the help of the "org.eclipse.debug.core.processFactories" extension point. In this way you can define your own IProcess. Look how we did it in the Sausalito plugins (org.eclipse.wst.xquery.set.launching/plugin.xml) These two points seem to integrate well with the DLTK infrastructure, at least from what I see in theory. Thus you can have your own RunnableProcess passed to your own RuntimeProcess. IMHO I think that the AbstractInterpreterRunner is generic enough and need no more extensions for this problem. Regards, Gabriel PS: I was usually against DLTK (because I use it). But it's not that bad afterall Removed at posters request by Webmaster Removed at posters request by Webmaster Added people to this bug. The content of attachment 169543 [details] has been deleted by Eclipse Webmaster <webmaster@eclipse.org> who provided the following reason: Poster request The token used to delete this attachment was generated at 2010-05-21 16:12:58 EDT. Created attachment 169564 [details]
Angelo proposed this solution for enabling remote launching with the existing DLTK infrastructure
|