You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jclouds.apache.org by an...@apache.org on 2015/05/08 03:30:21 UTC
[1/2] jclouds-site git commit: Removing duplicate text about closing
the context
Repository: jclouds-site
Updated Branches:
refs/heads/update-concepts [created] 940039cf5
Removing duplicate text about closing the context
Follow-on from 56a75bbb1
Project: http://git-wip-us.apache.org/repos/asf/jclouds-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/jclouds-site/commit/d5214768
Tree: http://git-wip-us.apache.org/repos/asf/jclouds-site/tree/d5214768
Diff: http://git-wip-us.apache.org/repos/asf/jclouds-site/diff/d5214768
Branch: refs/heads/update-concepts
Commit: d5214768bf9e4fe9fb52ca618c2860a124321f58
Parents: 56a75bb
Author: Andrew Phillips <an...@apache.org>
Authored: Thu May 7 21:28:05 2015 -0400
Committer: Andrew Phillips <an...@apache.org>
Committed: Thu May 7 21:28:05 2015 -0400
----------------------------------------------------------------------
start/concepts.md | 2 --
1 file changed, 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/jclouds-site/blob/d5214768/start/concepts.md
----------------------------------------------------------------------
diff --git a/start/concepts.md b/start/concepts.md
index aaf0a16..adada7f 100644
--- a/start/concepts.md
+++ b/start/concepts.md
@@ -84,5 +84,3 @@ Creating a context is an expensive operation, so in general it is a good idea to
It is important to [close a context](http://jclouds-javadocs.elasticbeanstalk.com/org/jclouds/Context.html) when you no longer need it, to free its associated resources.
You can also get a view back from the ContextBuilder and _later_ unwrap it to access the underlying API or provider.
-
-The context also provides access to some low level resources, such as the dependency injection framework or the executors used to perform concurrent operations, so it is important to close it once you are done, to free all its associated resources.
[2/2] jclouds-site git commit: Using new HEAD Javadocs URL
Posted by an...@apache.org.
Using new HEAD Javadocs URL
Now at http://jclouds-javadocs.elasticbeanstalk.com
Project: http://git-wip-us.apache.org/repos/asf/jclouds-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/jclouds-site/commit/940039cf
Tree: http://git-wip-us.apache.org/repos/asf/jclouds-site/tree/940039cf
Diff: http://git-wip-us.apache.org/repos/asf/jclouds-site/diff/940039cf
Branch: refs/heads/update-concepts
Commit: 940039cf5fd044c807b8c69b96e721082dc5b5c6
Parents: d521476
Author: Andrew Phillips <an...@apache.org>
Authored: Thu May 7 21:29:18 2015 -0400
Committer: Andrew Phillips <an...@apache.org>
Committed: Thu May 7 21:29:18 2015 -0400
----------------------------------------------------------------------
start/concepts.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/jclouds-site/blob/940039cf/start/concepts.md
----------------------------------------------------------------------
diff --git a/start/concepts.md b/start/concepts.md
index adada7f..3785501 100644
--- a/start/concepts.md
+++ b/start/concepts.md
@@ -11,17 +11,17 @@ permalink: /start/concepts/
## <a id="views"></a>Views
-[**Views**](http://javadocs.jclouds.cloudbees.net/org/jclouds/View.html) are portable abstractions that are designed to allow you to write code that uses cloud services without tying yourself to a specific vendor. Take [JDBC](http://docs.oracle.com/javase/7/docs/technotes/guides/jdbc/index.html) as an example: rather than writing code directly for a specific type of database, you can make generic database requests, and the JDBC specification and drivers translate these into specific commands and statements for a certain type of database.
+[**Views**](http://jclouds-javadocs.elasticbeanstalk.com/org/jclouds/View.html) are portable abstractions that are designed to allow you to write code that uses cloud services without tying yourself to a specific vendor. Take [JDBC](http://docs.oracle.com/javase/7/docs/technotes/guides/jdbc/index.html) as an example: rather than writing code directly for a specific type of database, you can make generic database requests, and the JDBC specification and drivers translate these into specific commands and statements for a certain type of database.
Views generally make sense only once a reasonably broad set of functionality is supported by multiple vendors. In the cloud space, jclouds currently supports three such views:
* [BlobStore](/start/blobstore/)
* [ComputeService](/start/compute/)
- * [LoadBalancerService](http://javadocs.jclouds.cloudbees.net/org/jclouds/loadbalancer/LoadBalancerService.html)
+ * [LoadBalancerService](http://jclouds-javadocs.elasticbeanstalk.com/org/jclouds/loadbalancer/LoadBalancerService.html)
## <a id="apis"></a>APIs
-An **API** in jclouds describes the actual calls (often, but not always, HTTP requests) that can be executed against a specific cloud service to "do stuff". In the case of popular APIs, such as the [EC2 compute API](http://javadocs.jclouds.cloudbees.net/org/jclouds/ec2/EC2Api.html), or the [S3 storage API](http://javadocs.jclouds.cloudbees.net/org/jclouds/s3/S3Client.html), there may be multiple vendors with cloud services that support that particular API. For example, EC2 is supported by [Amazon](/guides/aws-ec2/) and [OpenStack](/guides/openstack/), amongst others.
+An **API** in jclouds describes the actual calls (often, but not always, HTTP requests) that can be executed against a specific cloud service to "do stuff". In the case of popular APIs, such as the [EC2 compute API](http://jclouds-javadocs.elasticbeanstalk.com/org/jclouds/ec2/EC2Api.html), or the [S3 storage API](http://jclouds-javadocs.elasticbeanstalk.com/org/jclouds/s3/S3Client.html), there may be multiple vendors with cloud services that support that particular API. For example, EC2 is supported by [Amazon](/guides/aws-ec2/) and [OpenStack](/guides/openstack/), amongst others.
A vendor may also support an API in multiple geographic locations. For example, [Rackspace](/guides/rackspace/)'s Cloud Servers API is available both in the [US](/reference/providers/#compute-providers) and the [UK](/reference/providers/#compute-providers).
@@ -61,7 +61,7 @@ It's like writing your database layer purely against the JDBC specification: you
#### You can use API-specific calls where needed
-If the particular views you are working with do not allow you to do exactly what you want, but the API supports the desired functionality, you can ["unwrap"](http://javadocs.jclouds.cloudbees.net/org/jclouds/View.html#unwrap(\)) the view to access the underlying API. This reduces the portability of your code, but you can still move between providers that support this API.
+If the particular views you are working with do not allow you to do exactly what you want, but the API supports the desired functionality, you can ["unwrap"](http://jclouds-javadocs.elasticbeanstalk.com/org/jclouds/View.html#unwrap(\)) the view to access the underlying API. This reduces the portability of your code, but you can still move between providers that support this API.
For example, if you unwrap the EC2 API from a ComputeService view and talk directly to EC2, you will not be able move to vCloud without code changes any more. You will still be able to switch to a different provider that also supports the EC2 API, however.
@@ -77,7 +77,7 @@ Finally, we have...
A context represents a specific connection to a particular provider. From the perspective of our database analogy, this would be broadly similar to a database connection against a specific DB.
-Once you have created a context via the [ContextBuilder](http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html) and are "connected" to a particular cloud service, you can either get any of the views that are supported by that provider, or go straight to the API or even to the provider level.
+Once you have created a context via the [ContextBuilder](http://jclouds-javadocs.elasticbeanstalk.com/org/jclouds/ContextBuilder.html) and are "connected" to a particular cloud service, you can either get any of the views that are supported by that provider, or go straight to the API or even to the provider level.
Creating a context is an expensive operation, so in general it is a good idea to create one context per credential and target cloud when the application starts and close it when it terminates. Contexts are thread-safe, so can be shared across your application.