Uploaded image for project: 'Tools (JBoss Tools)'
  1. Tools (JBoss Tools)
  2. JBIDE-22426

Connection: authorization strategy is always overwritten (in the client) upon #isConnected

XMLWordPrintable

      The current implementation of Connection#isConnected() will always overwrite the authorization strategy in the client that it is using. This seems wrong given that #getResources, #createResource, #updateResource (and other methods) also set it but check if it already exists beforehand. Making sure that they dont overwrite an existing strategy.

      Connection#isConnected
      	public boolean isConnected(IProgressMonitor monitor) {
      		client.setAuthorizationStrategy(getAuthorizationStrategy());
      		try {
      
      Connection#createResource
      	public <T extends IResource> T createResource(T resource) {
      		try {
      			if(client.getAuthorizationStrategy() == null) {
      				client.setAuthorizationStrategy(getAuthorizationStrategy());
      			}
      			return client.create(resource);
      

      A very likely side-effect of this is in Connection#ownsResource which compares clients (the one in the connection and the one attached to the given resource. The 2 clients are compared with the authorization strategy:

      com.openshift.internal.restclient.DefaultClient#equals
      	@Override
      	public boolean equals(Object obj) {
      		...
      		return ObjectUtils.equals(strategy, other.strategy);
      

      the lookup for a connection for a given resource in ConnectionRegistryUtils#safeGetConnectionFor will therefore fail after a Connection#isConnected:

      ConnectionsRegistryUtil#safeGetConnectionFor(IResource)
       
      	public static Connection safeGetConnectionFor(IResource resource) {
      		Collection<Connection> all = ConnectionsRegistrySingleton.getInstance().getAll(Connection.class);
      		for (Connection connection : all) {
      			if(connection.ownsResource(resource)) {
      				return connection;
      			}
      		}
      		return null;
      	}
      

            adietish@redhat.com André Dietisheim
            adietish@redhat.com André Dietisheim
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: