I just had a closer look
The args are passed from main to LaunchArgHandler.
It passed the URI to ArgDelegator which then waits for an ArgDelegationPeer.
ArgDelegationPeerImpl.handleUri() then does the real work, looking at
the scheme prefix and finding the correct handler or displaying an error.
https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/impl/argdelegation/ArgDelegationPeerImpl.java#L141
I don't think it is ideal for people to call
ArgDelegationPeerImpl.handleUri() directly from other code although the
logic in that function appears to be the correct logic for handling a
URI from outside OSGi (e.g. from the launcher/main method/other code in
the JVM).
Maybe some other class can be created as a facade, e.g.
package net.java.sip.communicator.launcher;
public class Integration {
public static void dial(Uri target) {
// finds existing main class instance
// passes the target URI to LauncherArgs somehow
}
}
The other solution may be JMS - maybe FFMQ can be run as a JMS bundle
and then another bundle can read messages from the queue and call the
handleUri() method.
···
On 07/07/14 23:21, Daniel Pocock wrote:
On 07/07/14 20:14, Emil Ivov wrote:
Hey Daniel,
On 07.07.14, 15:11, Daniel Pocock wrote:
I've been running Jitsi as part of another application, they are
deployed together using JNLP / WebStart and run in the same JVM.
Is there any API method in Jitsi that the other application should call
directly to initiate a call?
This can be done by simply running "jitsi sip:1234". You may want to
check how SIPCommunicator.java passes these arguments to the arg handler
in Jitsi. Maybe this would do the job for you?
I'm quite happy to look at that and use it in testing
Is it an API that you would want to promote for this purpose though, or
would you prefer to have some wrapper layer around it as the official
Jitsi developer API if more people want to do stuff like this?
