You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

OperationResult.java 4.5KB

Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148
  1. /*
  2. * Copyright (C) 2010, Google Inc.
  3. * Copyright (C) 2008, Marek Zawirski <marek.zawirski@gmail.com>
  4. * Copyright (C) 2007-2009, Robin Rosenberg <robin.rosenberg@dewire.com>
  5. * Copyright (C) 2008, Shawn O. Pearce <spearce@spearce.org> and others
  6. *
  7. * This program and the accompanying materials are made available under the
  8. * terms of the Eclipse Distribution License v. 1.0 which is available at
  9. * https://www.eclipse.org/org/documents/edl-v10.php.
  10. *
  11. * SPDX-License-Identifier: BSD-3-Clause
  12. */
  13. package org.eclipse.jgit.transport;
  14. import java.util.Collection;
  15. import java.util.Collections;
  16. import java.util.Map;
  17. import java.util.SortedMap;
  18. import java.util.TreeMap;
  19. import org.eclipse.jgit.lib.Ref;
  20. /**
  21. * Class holding result of operation on remote repository. This includes refs
  22. * advertised by remote repo and local tracking refs updates.
  23. */
  24. public abstract class OperationResult {
  25. Map<String, Ref> advertisedRefs = Collections.emptyMap();
  26. URIish uri;
  27. final SortedMap<String, TrackingRefUpdate> updates = new TreeMap<>();
  28. StringBuilder messageBuffer;
  29. String peerUserAgent;
  30. /**
  31. * Get the URI this result came from.
  32. * <p>
  33. * Each transport instance connects to at most one URI at any point in time.
  34. *
  35. * @return the URI describing the location of the remote repository.
  36. */
  37. public URIish getURI() {
  38. return uri;
  39. }
  40. /**
  41. * Get the complete list of refs advertised by the remote.
  42. * <p>
  43. * The returned refs may appear in any order. If the caller needs these to
  44. * be sorted, they should be copied into a new array or List and then sorted
  45. * by the caller as necessary.
  46. *
  47. * @return available/advertised refs. Never null. Not modifiable. The
  48. * collection can be empty if the remote side has no refs (it is an
  49. * empty/newly created repository).
  50. */
  51. public Collection<Ref> getAdvertisedRefs() {
  52. return Collections.unmodifiableCollection(advertisedRefs.values());
  53. }
  54. /**
  55. * Get a single advertised ref by name.
  56. * <p>
  57. * The name supplied should be valid ref name. To get a peeled value for a
  58. * ref (aka <code>refs/tags/v1.0^{}</code>) use the base name (without
  59. * the <code>^{}</code> suffix) and look at the peeled object id.
  60. *
  61. * @param name
  62. * name of the ref to obtain.
  63. * @return the requested ref; null if the remote did not advertise this ref.
  64. */
  65. public final Ref getAdvertisedRef(String name) {
  66. return advertisedRefs.get(name);
  67. }
  68. /**
  69. * Get the status of all local tracking refs that were updated.
  70. *
  71. * @return unmodifiable collection of local updates. Never null. Empty if
  72. * there were no local tracking refs updated.
  73. */
  74. public Collection<TrackingRefUpdate> getTrackingRefUpdates() {
  75. return Collections.unmodifiableCollection(updates.values());
  76. }
  77. /**
  78. * Get the status for a specific local tracking ref update.
  79. *
  80. * @param localName
  81. * name of the local ref (e.g. "refs/remotes/origin/master").
  82. * @return status of the local ref; null if this local ref was not touched
  83. * during this operation.
  84. */
  85. public TrackingRefUpdate getTrackingRefUpdate(String localName) {
  86. return updates.get(localName);
  87. }
  88. void setAdvertisedRefs(URIish u, Map<String, Ref> ar) {
  89. uri = u;
  90. advertisedRefs = ar;
  91. }
  92. void add(TrackingRefUpdate u) {
  93. updates.put(u.getLocalName(), u);
  94. }
  95. /**
  96. * Get the additional messages, if any, returned by the remote process.
  97. * <p>
  98. * These messages are most likely informational or error messages, sent by
  99. * the remote peer, to help the end-user correct any problems that may have
  100. * prevented the operation from completing successfully. Application UIs
  101. * should try to show these in an appropriate context.
  102. *
  103. * @return the messages returned by the remote, most likely terminated by a
  104. * newline (LF) character. The empty string is returned if the
  105. * remote produced no additional messages.
  106. */
  107. public String getMessages() {
  108. return messageBuffer != null ? messageBuffer.toString() : ""; //$NON-NLS-1$
  109. }
  110. void addMessages(String msg) {
  111. if (msg != null && msg.length() > 0) {
  112. if (messageBuffer == null)
  113. messageBuffer = new StringBuilder();
  114. messageBuffer.append(msg);
  115. if (!msg.endsWith("\n")) //$NON-NLS-1$
  116. messageBuffer.append('\n');
  117. }
  118. }
  119. /**
  120. * Get the user agent advertised by the peer server, if available.
  121. *
  122. * @return advertised user agent, e.g. {@code "JGit/4.0"}. Null if the peer
  123. * did not advertise version information.
  124. * @since 4.0
  125. */
  126. public String getPeerUserAgent() {
  127. return peerUserAgent;
  128. }
  129. }