[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ptp-user] Remote Tools search path for the "java" executable
- From: "Jay Alameda" <jalameda@xxxxxxxxxxxxxxxxx>
- Date: Fri, 7 Oct 2011 11:18:53 -0500 (CDT)
- Delivered-to: email@example.com
- Thread-index: AcyEzvqiXqojq8HASRO1Qm8Mwv8NLgAPYqKA
I've been seeing an issue on newer machines where the Dstore server is
complaining about the version of java - or isn't finding it (and doesn't
get launched in either case). I've tried looking at the environment
(through the build mechanism), everything looks sane there, and the
default java in the path is 1.6, both for build and also interactively.
I'm wondering if the issue reported below is related somehow, and also
would like to figure out how to debug this issue better. Do you have any
From: ptp-user-bounces@xxxxxxxxxxx [mailto:ptp-user-bounces@xxxxxxxxxxx]
On Behalf Of Greg Watson
Sent: Friday, October 07, 2011 3:56 AM
To: PTP User list
Subject: Re: [ptp-user] Remote Tools search path for the "java" executable
Please open a bug. That way we can keep track of the issue.
We could use the RM configuration file for this, but that would mean that
you need to configure a RM to use a remote project, whereas remote
projects are currently independent of the RM framework. I think it would
be better to make this a configurable property of the project.
Regarding the debugger, you can set the gdb location using the SDM
preferences (Preferences>Parallel Tools>Debug>SDM). Note however, that
this setting will apply to any debug configuration that uses the SDM. If
this is too restrictive then it might be better to make this a
configuration option in the debug launch configuration.
On Sep 5, 2011, at 7:59 PM, Rodrigo Fraxino Araujo wrote:
> Dear Greg,
> What do you think is the best way to address your solution? One should
> extend this abstract class and override these methods? Or is it a
> necessity for the applications that make use of PTP to address
> org.eclipse.ptp.remote.core.server.AbstractRemoteServerRunner? If so,
> is it just a matter of using the set methods to specify the path?
> I have done some digging and also found out about JAXB resource
> manager (http://tinyurl.com/4yk9ata). From what I understood I think
> it's an alternative to this matter that makes possible to use an XML
> file to define the server properties in the client side. Do you think
> that it is a sound approach to this particular issue?
> Best regards,
>> -------- Original Message --------
>> Re: [ptp-user] Remote Tools search path for the "java" executable
>> Fri, 2 Sep 2011 09:50:10 -0400
>> Greg Watson <g.watson@xxxxxxxxxxxx>
>> PTP User list <ptp-user@xxxxxxxxxxx>
>> PTP User list <ptp-user@xxxxxxxxxxx>
>> Whatever executable is specified in the extension point will be run.
>> If that is just "java" then it will use whatever is in the path. You
>> could use "/path/to/java" to specify an explicit path.
>> Programmatically, you have two options:
>> 1. AbstractRemoteServerRunner#setLaunchCommand() can be used to
>> specify a command with an explicit path.
>> 2. AbstractRemoteServerRunner#setWorkDir() can be used to set the
>> working directory, then you could specify the command as "./java".
>> If you can think of another way you'd like to do this, let me know
>> and I can look at implementing it.
>> On Sep 1, 2011, at 3:36 PM, Corey Ashford wrote:
>>> On 09/01/2011 11:10 AM, Corey Ashford wrote:
>>>> Hello all,
>>>> When we create a remote connection using Remote Tools, there is
>>>> the one issue of needing to make sure that the system finds the
>>>> correct "java" executable with which to run the DStore server.
>>>> Is there way to configure Remote Tools in such a way that it looks
>>>> for java in a predefined location, or does it always just use the
>>>> $PATH of the remote account that's provided?
>>> There's also a similar issue for "gdb". Is there a way we can
>>> specify which "gdb" that SDM will use, or does it rely on $PATH as
>>> - Corey
>>> ptp-user mailing list
>> ptp-user mailing list
> ptp-user mailing list
ptp-user mailing list