SMALL SOLDIERS (1998) A Film Review by Ted Prigge Copyright 1998 Ted Prigge
Director: Joe Dante Writers: Ted Eliott, Zak Penn, Adam Rifkin, Terry Rossio, and Gavin Scott Starring: Gregory Smith, Kirsten Dunst, Jay Mohr, David Cross, Kevin Dunn, Ann Magnuson, Paul Hartman, Wendy Schaal, Denis Leary, and Dick Miller...with voices by Tommy Lee Jones, Frank Langella, Ernest Borgnine, George Kennedy, Jim Brown, Bruce Dern, Clint Walker, Harry Shearer, Christopher Guest, Michael McKean, Sarah Michelle Gellar, and Christina Ricci
"Small Soldiers" is probably the first film to actually satirize the entity known as kiddie violence, at least on a major scale, and therefore it kind of grabs our attention when it skewers the way we are sometimes fed different kinds of propaganda via cartoons and various other kinds of child entertainment just because it's the first to really hit it hard. Luckily enough, this isn't a "message movie," and it's not naive enough to totally blame characters like G.I. Joe, the epitomy of right-wing, moral-yet-immoral, John Wayne-esque propaganda; it's really just an extremely entertaining film with an outrageously wonderful premise with an eerie, unsettling edge that at once freaks you out and leaves you in stitches.
No shock that this is from Joe Dante, the hilarious wizard who directed one of the all-time great kiddie horror films, "Gremlins," a hilarious film that is all the more hilarious the older you get...and, to a slightly lesser extent, "Gremlins 2: The New Batch," which skewered Ted Turner-esque media all while wreaking totally hilarious havoc. He takes the same kind of approach to his story that he did with the latter one: this is a film that almost gets off on mocking military "intelligence" by telling the story of a bunch of gung ho soldier toys with a microchip that allows them to act like real army guys, including attacking humans. Only they're smaller.
The story behind it deals with a huge company owned by the deliciously inhuman CEO Gil Mars (Denis Leary), who orders his two toy division heads, Larry Benson and Irwin Wayfair (Jay Mohr and David Cross, the latter who's half of HBO's "Mr. Show"), to create a line of action figures who can really act and talk like all they do in all the commercial ads that make toys look incredibly exciting. By getting a special army microchip off the web, they are able to make their toys respond like human beings, and gives them each set standards. There's the Commando Elites, a group of overly-patriotic soldiers led by the Patton-esque Chip Hazard (voiced brilliantly by Tommy Lee Jones), and featuring the supporting voices of cast members of "The Dirty Dozen," as well as Bruce Dern, tossed in for good measure; and then there's the wimpy monster Gargonites, led by the stoic Archer (voiced by a now-British Frank Langella), and featuring the voice talents of...well, the three chief members of "Spinal Tap" (Harry Shearer, Christopher Guest, and Michael McKean, just for the record). These two are at war with one another, though the odds are totally in favor of the soldiers.
Cut to a little town somewhere where a young kid named Alan (Gregory Smith, from "Krippendorf's Tribe") is running his dad's collapsing old-school toy shop while he's away on a business trip, and who mistakenly steals a box of these toys from the friendly truck driver (Dante regular, Dick Miller) to sell quickly so that the store makes some money for a change. Soon enough, the toys have escaped, ruined the store, and are about to wreak havoc on Alan, his almost-girlfriend Christy (a glowing Kirsten Dunst), and the homes of their parents (played by Kevin Dunn, Ann Magnuson, Wendy Schaal, and the late Phil Hartman in his last performance) as they war against eachother.
The obvious reason to see this film is for its wonderful sense of humor, which, for the most part, is how the film is played out. Instead of an un-subtle attempt at really trying to overturn cartoon violence and its affect on youth (which would have made for an annoying right-wing crapfest), "Small Soldiers" decides to use that as a way of mocking patriotism and basically the whole military as a concept. The Commando Elites are all portrayed as being the bloodthirsty villains of the film, who attack anyone who merely stands up for the Gargonites, who are all in hiding for fear of defeat. And the film never wastes a moment at really just digging deep and making fun of war movies. We have two really hilarious standouts, other than the obvious parody of "The Dirty Dozen," a film that actually mocked military intelligence as well.
Dante has always loved to parody other movies, but he also parodies sociological things as well, like America's obsession with war (hands-down funniest line, said by Phil Hartman: "I think World War II was my favorite war"...at least I laughed, no one else did), and even some post-"'burbs" satirization of suburbia, complete with the on-going battle between the beauty of nature and the beauty of a 12-foot satellite dish sitting in your lawn and the horror of having a tree block its reception. When this film sticks to parody and satirizing, it's one of the most entertaining experiences in a real long time.
However, when the film shifts to the melodrama of Alan's parents not understanding him, or even the required love story of the film between Alan and a way-more-mature Christy (I'm sorry: he looks like he's 12, and she looks like she's 17 - doesn't work). It's not that this truly a bad thing and the film is never unwatchable, but these scenes serve as distractions. It'd be nice if the script or the actors, especially the by-the-books Gregory Smith as the lead, had as much umph in their delivery as Kirsten Dunst does (she's just lovable), these scenes wouldn't be so hard to intake after the high satire of the idea of toy soldiers attacking real people with nail guns and flame throwers.
It just doesn't help that the Gargonites aren't really that interesting either, save for a couple of moments when the rest of them are finally allowed to do their schtick. It's here where the film only makes attempts at deepening itself with questions of humanity in these characters, and the obvious depth it brings to the military plot (the heroic soliders are pure evil while the ugly monsters are pure good), but other than that, there's a little to much started that isn't finished by the end. It's like some of this film is played straight, yet the rest of it is played totally for laughs.
It's the second part that really works. The comedy of the two toy creators scrambling around to avoid a lawsuit. Phil Hartman trying to get the most out of his satellite dish. The numerous incarnations of toys coming alive (the whole barbie subplot, featuring voices by Sarah Michelle Gellar and Christina Ricci, is definitely a howler). Anything featuring the soldier toys. And la grande finale, an exciting, vicious battle between the two families and legions of toys armed with deadly weapons that may be too much for younger children, but would pretty much be fine for older children (hey, it's PG-13 for a reason, okay?). These are the things that really work for this film, and luckily enough these great parts greatly outweigh the more mediocre parts of the film. What we have here is a return to form for Dante, who has been kinda slumming it since the 80s, but is now back again making kiddie films for the older crowd who can still take their older children and probably laugh and have a better time than they will.
MY RATING (out of 4): ***
Homepage at: http://www.geocities.com/Hollywood/Hills/8335/
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


If you have a MyVerizon login, sign in for access to saved shipping and billing information.
If you don't have a MyVerizon login, you can check out without signing in.
You'll be able to register for a MyVerizon ID upon completion of your order.
Receive Verizon Wireless special offers via email. You can remove your email address from our list at any time. Simply click the "unsubscribe" link at the bottom of each email. Privacy Policy
Detailed shipping information nullam cursus, libero eu feugiat iaculis, nibh ante congue eros, eu rutrum mi turpis elementum augue.
Great news! Your order qualified for an additional discount that has already been applied to your total.
Three digit security code on the back of your card.
Four digit security code on the front of your card.
Your purchase is safe, your information is secure.
We won't sell or share your information with anyone.
If you are not satisfied with your purchase, you can return your merchandise for a refund A $35 restocking fee ($70 for netbooks and tablets) will apply (excluding Hawaii).
Our commitment to give you the best possible service.
Please enter your billing address:
Your card will not be charged at this time.
This is the last step before purchasing. Please review your order, make your final edits and click 'Place Your Order' when ready. These items will require a signature for delivery:
Donec adipiscing pretium dapibus. Nunc gravida elementum risus et volutpat. In hac habitasse platea dictumst. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
Spend $10 more and your order qualifies for NEXT DAY DELIVERY!


Ouicards jQuery
Question 1
Answer 1
Question 2
Answer 2
Question 3
Answer 3
Question 4
Answer 4
Question 5
Answer 5
Question 6
Answer 6
Question 7
Answer 7
Question 8
Answer 8
Question 9
Answer 9
Question 10
Answer 10
Show answer
Correct
Wrong


[t]{$salutation} {$entity_name}[/t]
[t]I would like to inform you that the document {$docName} of the type {$docType} is expiring on {$expirationDate}.[/t]
[t]Kind regards,[/t]


This section describes Rest.li support for implementing servers:
Rest.li supports the following runtimes:
Rest.li servers can be configured with different R2 filters, according
to your use case. How the filters are configured depends on which
dependency injection framework (if any) you are using. For example, take
a look at
the
compression wiki page to see how we can configure a server for
compression. Another example is to add a
SimpleLoggingFilter
with Spring, which requires you to do
the following (full file
here):
<!-- Example of how to add filters, here we'll enable logging and snappy compression support -->
<bean id="loggingFilter" class="com.linkedin.r2.filter.logging.SimpleLoggingFilter" />
Other R2 filters can also be configured in a similar way.
The first step in building a Rest.li application is to define your data schema using Pegasus Data Schemas. The Pegasus Data Schema format uses a simple Avro-like syntax to define your data model in a language-independent way. Rest.li provides code generators to create Java classes that implement your data model. See Pegasus Data Schemas for full details.
After you have defined your data models, the principle programming task when implementing a Rest.li server is to create resource classes. In Rest.li, resource classes define the RESTful endpoints your server provides. You create a resource class by adding a class level annotation and by implementing or extending a Rest.li interface or base class corresponding to the annotation. The annotations help describe the mapping from your Java code to the REST interface protocol. When possible, the framework uses conventions to help minimize the annotations you need to write.
Steps to define a resource class:
implement
the
necessary Resource interface or extend one of the convenience base
classes that implements the interface.Here is a simple example of a Resource class. It extends a convenience
base class, uses an annotation to define a REST end-point (“fortunes”),
and provides a GET endpoint by overriding the standard signature of the
get()
method of the base class:
/*
* A collection of fortunes, keyed by random number.
**/
RestLiCollection(name = "fortunes", namespace = "com.example.fortune")
public class FortunesResource extends CollectionResourceTemplate<Long, Fortune>
{
/**
* Gets a fortune for a random number.
*/
Override
public Fortune get(Long key)
{
// retrieve data and return a Fortune object ...
}
}
This interface implements an HTTP GET:
> GET /fortunes/1
...
< { "fortune": "Your lucky color is purple" }
Note that Rest.li does not automatically use the names of your Java identifiers. Class names, method names, and parameter names have no direct bearing on the interface your resource exposes through annotations.
The above example supports the GET operation by overriding the
CollectionResourceTemplate
, and you can also choose to support other
operations by overriding other methods. However, you can also define any
method of your class as handling operations by using Resource
Annotations, described in detail in the next section.
Rest.li resources are documented in the resource source files using javadoc. When writing resources, developers simply add any documentation as javadoc to their java resource classes, methods, and method params. It is recommended that developers follow the javadoc style guidelines for all formatting so that their documentation is displayed correctly.
Rest.li will automatically extract this javadoc and include it in all generated “interface definitions” (.restspec.json files) and generated client bindings. This approach allows REST API clients and tools to easily gain access to the documentation. For example, Rest.li API Hub is an opensource web UI that displays REST API documentation, including all javadoc, for Rest.li APIs.
Resource annotations are used to mark and register a class as providing as Rest.li resource. One of a number of annotations may be used, depending on the Interface Pattern the resource is intended to implement. Briefly, here are the options:
| Resource Type | Annotation | Interface or Base Class |
|---|---|---|
| Collection | @RestLiCollection | For simple keys, implement CollectionResource or extend CollectionResourceTemplate . For complex key implement ComplexKeyResource , extend ComplexKeyResourceTemplate , or implement KeyValueResource for use cases requiring extensive customization |
| Simple | @RestLiSimpleResource | Implement SimpleResource , extend SimpleResourceTemplate or implement SingleObjectResource for use cases requiring extensive customization |
| Association | @RestLiAssociation | Implement AssociationResource , extend AssociationResourceTemplate , or implement KeyValueResource for use cases requiring extensive customization |
| Actions | @RestLiActions | N/A |
The @RestLiCollection
annotation is applied to classes to mark them as
providing a Rest.li collection resource. Collection resources model a
collection of entities, where each entity is referenced by a key. See
Collection Resource
Pattern
for more details.
The supported annotation parameters are:
name
- required, defines the name of the resource.namespace
- optional, defines the namespace for the resource.
Default is empty (root namespace). The namespace of the resource
appears in the IDL, and is used as the package name for the
generated client builders.keyName
- optional, defines the key name for the resource. Default
is “<ResourceName>Id”.parent
- optional, defines the parent resource for this resource.
Default is root.Classes annotated with @RestLiCollection
must implement the
CollectionResource
interface. The CollectionResource
interface
requires two generic type parameters:
K
- the key type for the resource.V
- the value type for the resource (also known as, the entity
type).The key type for a collection resource must be one of:
String
Boolean
Integer
Long
.pdsc
schema)RecordTemplate
generated from a .pdsc
schema)The value type for a collection resource must be a pegasus record, any
subclass of RecordTemplate
generated from a .pdsc
schema.
For convenience, Collection resources may extend
CollectionResourceTemplate
rather than directly implementing the
CollectionResource
interface.
For example:
@RestLiCollection(name = "fortunes", namespace = "com.example.fortune",
keyName = "fortuneId")
public class FortunesResource extends CollectionResourceTemplate<Long,
Fortune>
{
...
}
Sub-resources may be defined by setting the “parent” field on
@RestLiCollection
to the class of the parent resource of
the sub-resource.
For example, a sub-resource of the fortunes resource would have a URI path of the form:
/fortunes/{fortuneId}/subresource\
Parent resource keys can be accessed by sub-resources, as shown in the following example:
RestLiCollection(name = "subresource", namespace = "com.example.fortune", parent = FortunesResource.class)
public class SubResource extends CollectionResourceTemplate<Long, SubResourceEntity>
{
RestMethod.Get
public Greeting get(Long key, @Keys PathKeys keys) {
Long parentId = keys.getAsLong("fortuneId");
...
}
...
}
Alternatively, if not using free form methods, the path key can
retrieved from the resource context. This approach may be deprecated in
future versions in favor of @Keys
.
public SubResourceEntity get(Long subresourceKey)
{
Long parentId = getContext().getPathKeys().getAsLong("fortuneId");
...
}
For details on how to make requests to sub-resources from a client, see Calling Sub-resources
Classes implementing ComplexKeyResource
can use a record type as key.
This allows for arbitrary complex hierarchical structures to be used to
key a collection resource, unlike CollectionResources, which only
support primitive type keys (or typerefs to primitive types).
ComplexKeyResourceTemplate
is a convenient base class to extend when
implementing a ComplexKeyResource
.
The full interface is:
public interface ComplexKeyResource<K extends RecordTemplate, P extends
RecordTemplate, V extends RecordTemplate> ...
A complex key consists of a Key
and Parameter
part. The Key
should
uniquely identify the entities of the collection while the parameters
may optionally be added to allow additional information that is not used
to lookup an entity, such as a version tag for concurrency control.
Since the parameters are often not needed, an EmptyRecord
may be used
in the generic signature of a ComplexKeyResource
to
indicate that no “Parameters” are used to key the collection.
Example:
@RestLiCollection(name = "widgets", namespace = "com.example.widgets")
public class WidgetResource implements extends
ComplexKeyResourceTemplate<WidgetKey, EmptyRecord, Widget>
{
public Widget get(ComplexResourceKey<WidgetKey, EmptyRecord> ck)
{
WidgetKey key = ck.getKey();
int number = key.getNumber();
String make = key.getThing().getMake();
String model = key.getThing().getModel();
return lookupWidget(number, make, model);
}
}
To use EmptyRecord
, restli-common
must be in
the dataModel
dependencies for the api project where client
bindings are generated, as shown in the following example:
api/build.gradle:
dependencies {
...
dataModel spec.product.pegasus.restliCommon
}
Where WidgetKey.pdsc
is defined by the schema:
{
"type": "record",
"name": "WidgetKey",
"namespace": "com.example.widget",
"fields": [
{"name": "number", "type": "string"},
{
"name": "thing", "type": {
"type": "record",
"name": "Thing",
"fields": [
{"name": "make", "type": "string"},
{"name": "model", "type": "string"}
]
}
}
]
}
Example request:
curl "http://<hostname:port>/widgets/number=1&thing.make=adruino&thing.model=uno
If params are added, they are represented in the url under the “$params” prefix like this:
curl "http://<hostname:port>/widgets/number=1&thing.make=adruino&thing.model=uno&$params.version=1
The implementation of complex key collection is identical to the regular
RestLiCollection
with the exception that it extends
ComplexKeyResourceTemplate
(or directly implements
ComplexKeyResource
) and takes three type parameters instead of two:
key type, key parameter type, and value type — each extending
@RecordTemplate.
For details on how a complex key is represented in a request URL see Rest.li Protocol: Complex Types
The @RestLiSimpleResource
annotation is applied to classes to mark
them as providing a Rest.li simple resource. Simple resources model an
entity which is a singleton in a particular scope. See the description
of the Simple Resource
Pattern
for more details.
The supported annotation parameters are:
name
- required, defines the name of the resource.namespace
- optional, defines the namespace for the resource.
Default is empty (root namespace). The namespace of the resource
appears in the IDL, and is used as the package name for the
generated client builders.parent
- optional, defines the parent resource for this resource.
Default is root.Classes annotated with @RestLiSimpleResource
must implement the
SimpleResource
interface. The SimpleResource
interface requires a
generic type parameter V
, which is the value type for the resource
(also known as, the entity type). The value type for a simple resource
must be a pegasus record, any subclass of RecordTemplate
generated
from a .pdsc
schema.
For convenience, simple resources may extend SimpleResourceTemplate
rather than directly implementing the SimpleResource
interface.
Examples:
@RestLiSimpleResource(name = "todaysPromotedProduct", namespace =
"com.example.product")
public class TodaysPromotedProductResource extends
SimpleResourceTemplate<Product>
{
...
}
The @RestLiAssociation
annotation is applied to classes to mark them
as providing a Rest.li association resource. Association resources model
a collection of relationships between entities. Each relationship is
referenced by the keys of the entities it relates and may define
attributes on the relation itself. See Association Resource
Pattern
for more details.
For Example:
RestLiAssociation(name = "memberships", namespace = "com.example",
assocKeys = {
Key(name = "memberId", type = Long.class), Key(name = "groupId", type = Long.class)
}
)
public class MembershipsAssociation extends AssociationResourceTemplate<Membership>
{
Override
public Membership get(CompoundKey key)
{
return lookup(key.getPartAsLong("memberId",
key.getPartAsLong("groupId"));
}
}
curl http://<hostname:port>/memberships/memberId=1&groupId=10
The supported annotation parameters are:
name
- required, defines the name of the resource.namespace
- optional, defines the namespace for the resource.
Default is empty (root namespace). The namespace of the resource
appears in the IDL, and is used as the package name for the
generated client builders.parent
- optional, defines the parent resource for this resource.
Default is root.assocKeys
- required, defines the list of keys for the association
resource. Each key must declare its name and type.Classes annotated with @RestLiAssociation
must implement the
AssociationResource
interface. The AssociationResource
interface
requires a single generic type parameter:
V
, which is the value type for the resource, a.k.a., the entity
type.The value type for an association resource must be a subclass of
RecordTemplate
generated from a .pdsc
schema.
Note that for association resources, they key type is always
CompoundKey
, with key parts as defined in the assocKeys
parameter of
the class’ annotation.
For convenience, Association resources may extend
AssociationResourceTemplate
rather than directly implementing the
AssociationResource
interface.
The @RestLiActions
annotation is applied to classes to mark them as
providing a Rest.li action set resource. Action set resources do not
model any resource pattern. They simply group together a set of custom
actions.
For example:
@RestLiActions(name = "simpleActions",
namespace = "com.example")
public class SimpleActionsResource {
Action(name="echo")
public String echo(ActionParam("input") String input)
{
return input;
}
}
The supported annotation parameters are:
name
- required, defines the name of the resource.namespace
- optional, defines the namespace for the resource.
Default is empty (root namespace).Action set resources do not have a key or value type, and do not need to
implement
any framework interfaces.
Resource methods are operations a resource can perform. Rest.li defines a standard set of resource methods, each with its own interface pattern and intended semantics.
The set of possible resource methods is constrained by the resource type, as described in the table below:
| Resource Type | Collection | Simple | Association | Action Set |
|---|---|---|---|---|
| GET | x | x | x | |
| BATCH_GET / GET_ALL | x | x | ||
| FINDER | x | x | ||
| CREATE / BATCH_CREATE | x | |||
| UPDATE / PARTIAL_UPDATE | x | x | x | |
| BATCH_UPDATE \ BATCH_PARTIAL_UPDATE | x | x | ||
| DELETE | x | x | x | |
| BATCH_DELETE | x | x | ||
| ACTION | x | x | x | x |
In the section below, K
is used to denote the resource’s key type, and
V
is used to denote the resource’s value type. Remember that for
association resources, K
is always CompoundKey
.
The GET resource method is intended to retrieve a single entity representation based upon its key or without a key from a simple resource. GET should not have any visible side effects. For example, it should be safe to call whenever the client wishes.
Resources providing the GET resource method must override one of the following method signatures.
For collection and association resources:
public V get(K key);
For simple resources:
public V get();
Get methods can also be annotated if not overriding a base class method. GET supports a method signature with a wrapper return type.
For collection and association resources:
@RestMethod.Get
public GetResult<V> getWithStatus(K key);
For simple resources:
@RestMethod.Get
public GetResult<V> getWithStatus();
An annotated get method may also have arbitrary query params added:
RestMethod.Get
public GetResult<V> get(K key, `QueryParam("viewerId") String
viewerId);
The return type GetResult<V>
allows users to set an arbitrary HTTP
status code for the response. For more information about the
RestMethod.Get
annotation, see Free-Form
Resources.
The BATCH_GET resource method retrieves multiple entity representations given their keys. BATCH_GET should not have any visible side effects. For example, it should be safe to call whenever the client wishes. However, this is not something enforced by the framework, and it is up to the application developer that there are no side effects.
Resources providing the BATCH_GET resource method must override the following method signature:
public Map<K, V> batchGet(Set<K> ids);
@RestMethod.BatchGet
may be used to indicate a batch get method
instead of overriding the batchGet method of a base class.
Resources may also return BatchResult
, which allows errors to be
returned along with entities that were successfully retrieved.
Example of a batch get:
public BatchResult<Long, Greeting> batchGet(Set<Long> ids)
{
Map<Long, Greeting> batch = new HashMap<Long, Greeting>();
Map<Long, RestLiServiceException> errors = new HashMap<Long,
RestLiServiceException>();
for (long id : ids)
{
Greeting g = _db.get(id);
if (g != null)
{
batch.put(id, g);
}
else
{
errors.put(id, new
RestLiServiceException(HttpStatus.S_404_NOT_FOUND));
}
}
return new BatchResult<Long, Greeting>(batch, errors);
}
Clients should make requests to a batch resource using buildKV()
(not
build()
, it is deprecated), for example:
new FortunesBuilders().batchGet().ids(...).buildKV();
When a GET is requested on a collection or association resource with no key provided (for example, /myResource), the GET_ALL resource method is invoked, if present. The GET_ALL resource method retrieves all entities for the collection and supports the same pagination facilities as a finder.
public List<V> getAll(@Context PagingContext pagingContext);
@RestMethod.GetAll
may be used to indicate a get all method instead of
overriding the getAll method of a base class.
To directly control the total and metadata returned by a get all method,
do not override getAll, instead create a new method with the
@RestMethod.GetAll
annotation and return a CollectionResult
rather
than a list, for example:
RestMethod.GetAll
public CollectionResult<Widgets, WidgetsMetadata> getAllWidgets(`Context
PagingContext pagingContext)
{
// ...
return new CollectionResult<Widgets, WidgetsMetadata>(pageOfWidgets,
total, metadata);
}
When returning a CollectionResult from GetAll, the behavior is identical to a finder. See the below finder documentation for additional details about CollectionResult.
FINDER methods model query operations. For example, they retrieve an ordered list of 0 or more entities based on criteria specified in the query parameters. Finder results will automatically be paginated by the Rest.li framework. Like GET methods, FINDER methods should not have side effects.
Resources may provide zero or more FINDER resource methods. Each finder
method must be annotated with the @Finder
annotation.
Pagination default to start=0 and count=10. Clients may set both of these parameters to any desired value.
The @Finder
annotation takes a single required parameter, which
indicates the name of the finder method.
For example:
/*
You can access this FINDER method via
/resources/order?q=findOrder&buyerType=1&buyerId=309&orderId=1208210101\
*/
RestLiCollection(name="order",keyName="orderId")
public class OrderResource extends CollectionResourceTemplate<Integer,Order>
{
Finder("findOrder")
public List<Order> findOrder(Context PagingContext context,
QueryParam("buyerId") Integer buyerId,
QueryParam("buyerType") Integer buyerType,
QueryParam("orderId") Integer orderId)
throws InternalException
{
...
}
}
Finder methods must return either:
List<V>
CollectionResult<V, MetaData>
BasicCollectionResult<V>
, a subclass of CollectionResult
Every parameter of a finder method must be annotated with one of:
Context
- indicates that the parameter provides framework context
to the method. Currently all @Context
parameters must be of type
PagingContext
.QueryParam
- indicates that the value of the parameter is
obtained from a request query parameter. The value of the annotation
indicates the name of the query parameter. Duplicate names are not
allowed for the same finder method.ActionParam
- similar to Query Param, but the parameter
information will be located in the request body. Generally,
@QueryParam
is preferred over @ActionParam
.AssocKey
- indicates that the value of the parameter is a partial
association key, obtained from the request. The value of the
annotation indicates the name of the association key, which must
match the name of an @Key
provided in the assocKeys
field of the
@RestLiAssociation
annotation.Parameters marked with @QueryParam
, @ActionParam
, and @AssocKey
may also be annotated with @Optional
, which indicates that the
parameter is not required. The @Optional
annotation may specify a
String value, indicating the default value to be used if the parameter
is not provided in the request. If the method parameter is of primitive
type, a default value must be specified in the @Optional
annotation.
Valid types for query parameters are:
String
boolean
/ Boolean
int
/ Integer
long
/ Long
float
/ Float
double
/ Double
.pdsc
schema)RecordTemplate
generated
from a .pdsc
schema)String[]
, long[]
, …Finder("simpleFinder")
public List<V> simpleFind(`Context PagingContext context);
Finder("complexFinder")
public CollectionResult<V, MyMetaData> complexFinder(Context(defaultStart
= 10, defaultCount = 100) PagingContext context,AssocKey("key1") Long key,
QueryParam("param1") String requiredParam,
QueryParam("param2") Optional String optionalParam);
Custom types can be any Java type, as long as it has a coercer and a typeref schema, even java classes from libraries such as Date. To create a query parameter that uses a custom type, you will need to write a coercer and a typeref schema for the type you want to use. See the typeref documentation for details.
First, for the coercer you will need to write an implementation of DirectCoercer that converts between your custom type and some simpler underlying type, like String or Double. By convention, the coercer should be an internal class of the custom type it coerces. Additionally, the custom type should register its own coercer in a static code block.
If this is not possible (for example, if you want to use a java built-in class like Date or URI as a custom type) then you can write a separate coercer class and register the coercer with the private variable declaration:
private static final Object REGISTER_COERCER =
Custom.registerCoercer(new ObjectCoercer(), CustomObject.class);
Typeref Schema
The purpose of the typeref schemas is to keep track of the underlying type of the custom Type and the location of the custom type’s class, and, if necessary, the location of its coercer. The basic appearance of the typeref schema is shown below:
{
"type" : "typeref",
"name" : "CustomObjectRef",
"namespace" : "com.linkedin.example" // namespace of the typeref
"ref" : "string", // underlying type that the coercer converts to/from
"java" : {
"class" : "com.linkedin.example.CustomObject", // location of the custom type class
"coercerClass" : "com.linkedin.example.CustomObjectCoercer" // only needed if the custom
// type itself cannot contain
// the coercer as an internal class.
}
}
This typeref can then be referenced in other schemas:
{
"type": "record",
"name": "ExampleRecord",
...
"fields": [
{"name": "member", "type": "com.linkedin.example.CustomObjectRef"}
...
]
}
And the generated Java data templates will automatically coerce from CustomObjectRef to CustomObject when accessing the member field:
CustomObject o = exampleRecord.getMember();
Once Java data templates are generated, the typeref may also be used in Keys, query parameters, or action parameters:
Keys:
@RestLiCollection(name="entities",
namespace = "com.example",
keyTyperefClass = CustomObjectRef.class)
public class EntitiesResource extends CollectionResourceTemplate<Urn,
CustomObject>
Compound keys:
RestLiAssociation(name="entities", namespace="com.example",
assocKeys={`Key(name="o",
type=CustomObject.class, typeref=CustomObjectRef.class)})
Query parameters:
@QueryParam(value="o", typeref=CustomObjectRef.class) CustomObject o
@QueryParam(value="oArray", typeref=CustomObjectRef.class)
CustomObject[] oArray
CREATE methods model the creation of new entities from their representation. In CREATE, the resource implementation is responsible for assigning a new key to the created entity. CREATE methods are neither safe nor idempotent.
Resources providing the CREATE resource method must override the following method signature:
public CreateResponse create(V entity);
The returned CreateResponse
object indicates the HTTP status code to
be returned (defaults to 201 CREATED), as well as an optional ID for the
newly created entity. If provided, the ID will be written into the
“X-LinkedIn-Id” header by calling toString()
on the ID object.
@RestMethod.Create
may be used to indicate a create method instead of
overriding the create method of a base class.
By default, the newly created entity is not returned in the CREATE response because the client already has the entity when sending the CREATE request. However, there are use cases where the server will attach additional data to the new entity. Returning the entity in the CREATE response saves the client another GET request.
Starting in Rest.li version 2.10.3, we provide the developer the option to
return the newly created entity. To use this feature, add a @ReturnEntity
annotation to the method that implements CREATE. The return type of the
method must be CreateKVResponse
.
@ReturnEntity
public CreateKVResponse create(V entity);
An example implementation for resource is like below, note that the return type will be CreateKVResponse
:
@ReturnEntity
public CreateKVResponse<Long, Greeting> create(Greeting entity)
{
Long id = 1L;
entity.setId(id);
return new CreateKVResponse<Long, Greeting>(entity.getId(), entity);
}
There may be circumstances in which you want to prevent the server from returning the entity, for example to reduce network traffic.
Here is an example curl request that makes use of the $returnEntity
query parameter to indicate that the entity should not be returned:
curl -X POST localhost:/greetings?$returnEntity=false -H 'X-RestLi-Method: CREATE' -d '{"message": "Hello, world!", "tone": "FRIENDLY"}'
BATCH_CREATE methods model the creation of a group of new entities from their representations. In BATCH_CREATE, the resource implementation is responsible for assigning a new key to each created entity. BATCH_CREATE methods are neither safe nor idempotent.
Resources providing the BATCH_CREATE resource method must override the following method signature:
public BatchCreateResult<K, V> batchCreate(BatchCreateRequest<K, V> entities);
The BatchCreateRequest
object wraps a list of entity representations
of type V
.
The returned BatchCreateResult
object wraps a list of CreateResponse
objects (see CREATE). The CreateResponse
objects are expected to be
returned in the same order and position as the respective input objects.
BatchCreateRequest
and BatchCreateResult
support the generic type
parameter K
to allow for future extension.
@RestMethod.BatchCreate
may be used to indicate a batch create method
instead of overriding the batchCreate method of a base class.
Example of a batch create:
public BatchCreateResult<Long, Greeting> batchCreate(BatchCreateRequest<Long, Greeting> entities)
{
List<CreateResponse> responses = new
ArrayList<CreateResponse>(entities.getInput().size());
for (Greeting g : entities.getInput())
{
responses.add(create(g));
}
return new BatchCreateResult<Long, Greeting>(responses);
}
public CreateResponse create(Greeting entity)
{
entity.setId(_idSeq.incrementAndGet());
_db.put(entity.getId(), entity);
return new CreateResponse(entity.getId());
}
Error details can be returned in any CreateResponse by providing a RestLiServiceException, for example:
public BatchCreateResult<Long, Greeting>
batchCreate(BatchCreateRequest<Long, Greeting> entities)
{
List<CreateResponse> responses = new
ArrayList<CreateResponse>(entities.getInput().size());
...
if (...)
{
RestLiServiceException exception = new
RestLiServiceException(HttpStatus.S_406_NOT_ACCEPTABLE, "...");
exception.setServiceErrorCode(...);
exception.setErrorDetails(...);
responses.add(new CreateResponse(exception));
}
...
return new BatchCreateResult<Long, Greeting>(responses);
}
Similar to CREATE, BATCH_CREATE also could return the newly created
entities in the response. To do that, add a @ReturnEntity
annotation to
the method implementing BATCH_CREATE. The return type of the method
must be BatchCreateKVResult
.
@ReturnEntity
public BatchCreateKVResult<K, V> batchCreate(BatchCreateRequest<K, V> entities);
An example implementation for resource is like below, note that the
return type will be BatchCreateKVResult
:
@ReturnEntity
public BatchCreateKVResult<Long, Greeting> batchCreate(BatchCreateRequest<Long, Greeting> entities)
{
List<CreateKVResponse<Long, Greeting>> responses = new ArrayList<CreateKVResponse<Long, Greeting>>(entities.getInput().size());
for (Greeting greeting : entities.getInput())
{
responses.add(create(greeting)); // Create function should return
CreateKVResponse\
}
return BatchCreateKVResult<Long, Greeting>(responses);
}
There may be circumstances in which you want to prevent the server from returning the entity, for example to reduce network traffic.
Here is an example curl request that makes use of the $returnEntity
query parameter to indicate that the entity should not be returned:
curl -X POST localhost:/greetings?$returnEntity=false -H 'X-RestLi-Method: BATCH_CREATE' -d '{"elements":[{"message": "Hello, world!", "tone": "FRIENDLY"},{"message": "Again!", "tone": "FRIENDLY"}]}'
UPDATE methods model updating an entity with a given key by setting its value (overwriting the entire entity). UPDATE has side effects but is idempotent. For example, repeating the same update operation has the same effect as calling it once.
Resources may choose whether to allow an UPDATE of an entity that does not already exist, in which case it should be created. This is different from CREATE because the client specifies the key for the entity to be created. Simple resources use UPDATE as a way to create the singleton entity.
Resources providing the UPDATE resource method must override one of the following method signatures.
For collection and association resources:
public UpdateResponse update(K key, V entity);
For simple resources:
public UpdateResponse update(V entity);
The returned UpdateResponse
object indicates the HTTP status code to
be returned.
@RestMethod.Update
may be used to indicate a update method instead of
overriding the update method of a base class.
BATCH_UPDATE methods model updating a set of entities with specified keys by setting their values (overwriting each entity entirely). BATCH_UPDATE has side effects but is idempotent. For example, repeating the same batch update operation has the same effect as calling it once.
Resources may choose whether to allow BATCH_UPDATE for entities that do not already exist, in which case each entity should be created. This is different from BATCH_CREATE because the client specifies the keys for the entities to be created.
Resources providing the BATCH_UPDATE resource method must override the following method signature:
public BatchUpdateResult<K, V> batchUpdate(BatchUpdateRequest<K, V>
entities);
BatchUpdateRequest
contains a map of entity key to entity value.
The returned BatchUpdateResult
object indicates the UpdateResponse
for each key in the BatchUpdateRequest
. In the case of failures,
RestLiServiceException
objects may be added to the BatchUpdateResult
for the failed keys.
@RestMethod.BatchUpdate
may be used to indicate a batch update method
instead of overriding the batchUpdate method of a base class.
Example of a batch update:
public BatchUpdateResult<Long, Greeting>
batchUpdate(BatchUpdateRequest<Long, Greeting> entities)
{
Map<Long, UpdateResponse> responseMap = new HashMap<Long,
UpdateResponse>();
for (Map.Entry<Long, Greeting> entry : entities.getData().entrySet())
{
responseMap.put(entry.getKey(), update(entry.getKey(),
entry.getValue()));
}
return new BatchUpdateResult<Long, Greeting>(responseMap);
}
public UpdateResponse update(Long key, Greeting entity)
{
Greeting g = _db.get(key);
if (g == null)
{
return new UpdateResponse(HttpStatus.S_404_NOT_FOUND);
}
_db.put(key, entity);
return new UpdateResponse(HttpStatus.S_204_NO_CONTENT);
}
PARTIAL_UPDATE methods model updating part of the entity with a given key. PARTIAL_UPDATE has side effects. In general, it is not guaranteed to be idempotent.
Resources providing the PARTIAL_UPDATE resource method must override the following method signature:
public UpdateResponse update(K key, PatchRequest<V> patch);
The returned UpdateResponse
object indicates the HTTP status code to
be returned.
Rest.li provides tools to make it easy to handle partial updates to your resources. A typical update function should look something like this:
@Override
public UpdateResponse update(String key, PatchRequest<YourResource> patch)
{
YourResource resource = _db.get(key); // Retrieve the resource object
from somewhere
if (resource == null)
{
return new UpdateResponse(HttpStatus.S_404_NOT_FOUND);
}
try
{
PatchApplier.applyPatch(resource, patch); // Apply the patch.\
// Be sure to save the resource if necessary\
}
catch (DataProcessingException e)
{
return new UpdateResponse(HttpStatus.S_400_BAD_REQUEST);
}
return new UpdateResponse(HttpStatus.S_204_NO_CONTENT);
}
The PatchApplier automatically updates resources defined using the Pegasus Data format. The Rest.li client classes provide support for constructing patch requests, but here is an example update request using curl:
<code>
curl -X POST localhost:/fortunes/1 -d '{"patch": {"$set": {"fortune": "you will strike it rich!"}}}'
</code>
@RestMethod.PartialUpdate
may be used to indicate a partial update
method instead of overriding the partialUpdate method of a base class.
It is possible to inspect the partial update and selectively write only the changed fields to a store.
For example, to update only the street field of this address entity:
{
"address": {
"street": "10th",
"city": "Sunnyvale"
}
}
The partial update to change just the street field is:
{
"patch": {
"address": {
"$set": {
"street": "9th"
}
}
}
}
For the service code to selectively update just the street field (e.g. UPDATE addresses SET street=:street WHERE key=:key). The partial update can be inspected and the selective update if only the street field is changed:
@Override
public UpdateResponse update(String key, PatchRequest<YourResource>
patchRequest)
{
try
{
DataMap patch = patchRequest.getPatchDocument();
boolean selectivePartialUpdateApplied = false;
if(patch.containsKey("address") && patch.size() >= 1)
{
DataMap address = patch.getDataMap("address");
if(address.containsKey(\"\$set\") && address.size() 1)
{
DataMap set = address.getDataMap("\$set");
if(address.containsKey("street") && address.size() 1)
{
String street = address.getString(\"street\");
selectivePartialUpdateApplied = true;
// update only the street, since its the only thing this patch requests to change
}
}
}
if(selectivePartialUpdateApplied false)
{
// no selective update available, update the whole record with
PatchApplier and return the result\
}
}
catch (DataProcessingException e)
{
return new UpdateResponse(HttpStatus.S_400_BAD_REQUEST);
}
return new UpdateResponse(HttpStatus.S_204_NO_CONTENT);
}
To create a request to modify field(s), PatchGenerator can be used, for example:
Fortune fortune = new Fortune().setMessage("Today's your lucky day.");
PatchRequest<Fortune> patch = PatchGenerator.diffEmpty(fortune);
Request<Fortune> request = new
FortunesBuilders().partialUpdate().id(1L).input(patch).build();
PatchGenerator.diff(original, revised)
can also be used to create a
minimal partial update.
By default, the patched entity is not returned in the PARTIAL_UPDATE response because the client already has the patch data and possibly has the rest of the entity as well. However, there are use cases where the server will attach additional data to the new entity or the user simply doesn’t have the whole entity. Returning the entity in the PARTIAL_UPDATE response saves the client another GET request.
Starting in Rest.li version 24.0.0, we provide the developer the option to
return the patched entity. To use this feature, add a @ReturnEntity
annotation to the method that implements PARTIAL_UPDATE. The return type of the
method must be UpdateEntityResponse
.
@ReturnEntity
@RestMethod.PartialUpdate
public UpdateEntityResponse<V> partialUpdate(K key, PatchRequest<V> patch);
An example resource method implementation is as follows, note that the return type will be UpdateEntityResponse
:
@ReturnEntity
@RestMethod.PartialUpdate
public UpdateEntityResponse<Greeting> update(Long key, PatchRequest<Greeting> patch)
{
Greeting greeting = _db.get(key);
if (greeting == null)
{
throw new RestLiServiceException(HttpStatus.S_404_NOT_FOUND);
}
try
{
PatchApplier.applyPatch(greeting, patch);
}
catch (DataProcessingException e)
{
throw new RestLiServiceException(HttpStatus.S_400_BAD_REQUEST);
}
return new UpdateEntityResponse<Greeting>(HttpStatus.S_200_OK, greeting);
}
There may be circumstances in which you want to prevent the server from returning the entity, for example to reduce network traffic.
Here is an example curl request that makes use of the $returnEntity
query parameter to indicate that the entity should not be returned:
curl -X POST localhost:/greetings/1?$returnEntity=false -d '{"patch": {"$set": {"message": "Hello, world!"}}}'
BATCH_PARTIAL_UPDATE methods model partial updates of multiple entities given their keys. BATCH_PARTIAL_UPDATE has side effects. In general, it is not guaranteed to be idempotent.
Resources providing the BATCH_PARTIAL_UPDATE resource method must override the following method signature:
public BatchUpdateResult<K, V> batchUpdate(BatchPatchRequest<K, V>
patches);
The BatchPatchRequest
input contains a map of entity key to
PatchRequest
.
The returned BatchUpdateResult
object indicates the UpdateResponse
for each key in the BatchPatchRequest
. In the case of failures,
RestLiServiceException
objects may be added to the BatchUpdateResult
for the failed keys.
@RestMethod.BatchPartialUpdate
may be used to indicate a batch partial
update method instead of overriding the batchPartialUpdate method of a
base class.
Example of a batch partial update:
public BatchUpdateResult<Long, Greeting>
batchUpdate(BatchPatchRequest<Long, Greeting> entityUpdates)
{
Map<Long, UpdateResponse> responseMap = new HashMap<Long,
UpdateResponse>();
for (Map.Entry<Long, PatchRequest<Greeting>> entry :
entityUpdates.getData().entrySet())
{
responseMap.put(entry.getKey(), update(entry.getKey(),
entry.getValue()));
}
return new BatchUpdateResult<Long, Greeting>(responseMap);
}
public UpdateResponse update(Long key, PatchRequest<Greeting> patch)
{
Greeting g = _db.get(key);
if (g == null)
{
return new UpdateResponse(HttpStatus.S_404_NOT_FOUND);
}
try
{
PatchApplier.applyPatch(g, patch);
}
catch (DataProcessingException e)
{
return new UpdateResponse(HttpStatus.S_400_BAD_REQUEST);
}
_db.put(key, g);
return new UpdateResponse(HttpStatus.S_204_NO_CONTENT);
}
By default, the patched entities are not returned in the BATCH_PARTIAL_UPDATE response because the client already has the patch data and possibly has the rest of the entities as well. However, there are use cases where the server will attach additional data to the new entities or the user simply doesn’t have the whole entities. Returning the entities in the BATCH_PARTIAL_UPDATE response saves the client another GET request.
Starting in Rest.li version 25.0.5, we provide the developer the option to
return the patched entities. To use this feature, add a @ReturnEntity
annotation to the method that implements BATCH_PARTIAL_UPDATE. The return type of the
method must be BatchUpdateEntityResult
.
@ReturnEntity
@RestMethod.BatchPartialUpdate
public BatchUpdateEntityResult<K, V> batchPartialUpdate(BatchPatchRequest<Long, Greeting> patches);
An example resource method implementation is as follows, note that the return type will be BatchUpdateEntityResult
:
@ReturnEntity
@RestMethod.BatchPartialUpdate
public BatchUpdateEntityResult<Long, Greeting> batchPartialUpdate(BatchPatchRequest<Long, Greeting> patches)
{
Map<Long, UpdateEntityResponse<Greeting>> responseMap = new HashMap<>();
Map<Long, RestLiServiceException> errorMap = new HashMap<>();
for (Map.Entry<Long, PatchRequest<Greeting>> entry : patches.getData().entrySet())
{
try
{
UpdateEntityResponse<Greeting> updateEntityResponse = partialUpdate(entry.getKey(), entry.getValue());
responseMap.put(entry.getKey(), updateEntityResponse);
}
catch (RestLiServiceException e)
{
errorMap.put(entry.getKey(), e);
}
}
return new BatchUpdateEntityResult<>(responseMap, errorMap);
}
There may be circumstances in which you want to prevent the server from returning the entities, for example to reduce network traffic.
Here is an example curl request that makes use of the $returnEntity
query parameter to indicate that the entity should not be returned:
curl -X POST localhost:/greetings?ids=List(1)&$returnEntity=false -d '{"entities":{"1":{"patch": {"$set": {"message": "Hello, world!"}}}}}' -H 'X-RestLi-Method: BATCH_PARTIAL_UPDATE' -H 'X-RestLi-Protocol-Version: 2.0.0'
DELETE methods model deleting (removing) an entity with a given key on collection and association resources or without a key on simple resources. DELETE has side effects but is idempotent.
Resources providing the DELETE resource method must override one of the following method signatures.
For collection and association resources:
public UpdateResponse delete(K key);
For simple resources:
public UpdateResponse delete();
The returned UpdateResponse
object indicates the HTTP status code to
be returned.
@RestMethod.Delete
may be used to indicate a delete method instead of
overriding the delete method of a base class.
BATCH_DELETE methods model deleting (removing) multiple entities given their keys. BATCH_DELETE has side effects but is idempotent.
Resources providing the BATCH_DELETE resource method must override the following method signature:
public BatchUpdateResult<K, V> batchDelete(BatchDeleteRequest<K, V>
ids);
The BatchDeleteRequest
input contains the list of keys to be deleted.
BatchDeleteRequest
accepts a generic type parameter V
for future
extension.
The returned BatchUpdateResult
object indicates the UpdateResponse
for each key in the BatchDeleteRequest
. In the case of failures,
RestLiServiceException
objects may be added to the BatchUpdateResult
for the failed keys.
@RestMethod.BatchDelete
may be used to indicate a batch delete method
instead of overriding the batchDelete method of a base class.
Example of a batch delete:
public BatchUpdateResult<Long, Greeting>
batchDelete(BatchDeleteRequest<Long, Greeting> deleteRequest)
{
Map<Long, UpdateResponse> responseMap = new HashMap<Long,
UpdateResponse>();
for (Long id : deleteRequest.getKeys())
{
responseMap.put(id, delete(id));
}
return new BatchUpdateResult<Long, Greeting>(responseMap);
}
public UpdateResponse delete(Long key)
{
boolean removed = _db.remove(key) != null;
return new UpdateResponse(removed ? HttpStatus.S_204_NO_CONTENT :
HttpStatus.S_404_NOT_FOUND);
}
ACTION methods are very flexible and do not specify any standard behavior.
Resources may provide zero or more ACTION resource methods. Each action
must be annotated with the @Action
annotation.
The @Action
annotation supports the following parameters:
name
Required, the name of the action resource method.resourceLevel
Optional, defaults to ResourceLevel.ANY
, which
indicates that the action is defined directly on the containing
resource and does not support an entity key as a URI parameter.
ResourceLevel.COLLECTION
indicates that the action is defined on
the containing association or collection resource and does not
support an entity key as a URI parameter. ResourceLevel.ENTITY
indicates that the action is defined on the entity and it requires
an entity key as a URI parameter when the containing resource is an
association or collection resource. If the containing resource is a
simple resource ResourceLevel.ENTITY
indicates that the action is
defined directly on the resource and does not support an entity key
as a URI parameter.returnTyperef
Optional, defaults to no typeref. Indicates a
Typeref to be used in the IDL for the action’s return parameter.
Useful for actions that return primitive types.Each parameter to an action method must be annotated with
@ActionParam
, which takes the following annotation parameters:
value
Required, string name for the action parameter. If this is
the only annotation, parameter, it may be specified without being
explicitly named, for example, @ActionParam("paramName")
.typeref
Optional, Typeref to be used in the IDL for the parameter.Parameters of action methods may also be annotated with @Optional
,
which indicates that the parameter is not required in the request. The
@Optional
annotation may specify a String value, which specifies the
default value to be used if the parameter is not provided in the
request. If the method parameter is of primitive type, a default value
must be specified in the @Optional
annotation.
Valid parameter types and return types for action are:
String
boolean
/ Boolean
int
/ Integer
long
/ Long
float
/ Float
double
/ Double
ByteString
.pdsc
schema)RecordTemplate
or a subclass of RecordTemplate
generated from a
record schemaFixedTemplate
or a subclass of FixedTemplate
generated from a
fixed schemaAbstractArrayTemplate
or a subclass of AbstractArrayTemplate
,
for example, StringArray
, LongArray
, and so on.AbstractMapTemplate
or a subclass of AbstractMapTemplate
, for
example, StringMap
, LongMap
, and so on.Similar to GetResult<V>
, since 1.5.8, Rest.li supports an
ActionResult<V>
wrapper return type that allows you to specify an
arbitrary HTTP status code for the response.
Simple example:
@Action(name="action")
public void doAction();
A more complex example, illustrating multiple parameters:
Action(name="sendTestAnnouncement",resourceLevel= ResourceLevel.ENTITY)
public void sendTestAnnouncement(`ActionParam("subject") String
subject, ActionParam("message") String message, ActionParam("emailAddress") String
emailAddress)
ActionParam vs.
QueryParam@ActionParam
and @QueryParam
are used in different methods.
@ActionParam
is only allowed in Action methods, while @QueryParam
is
allowed in all non-Action methods. Besides, they are also different in
terms of how the parameter data is sent to the server. If a parameter is
annotated with @QueryParam
, the information will be sent in the
request url. If a parameter is annotated with @ActionParam
, the
information will be sent in the request body. Therefore, one advantage
of using @ActionParam
would be that the sent parameter can be encoded.
One disadvantage is that the purpose of the request itself can become
less clear if one only examines the url.
Resource methods should never explicitly return null
. If the Rest.li
framework detects this, it will return an HTTP 500
back to the client
with a message indicating ‘Unexpected null encountered’. The only
exceptions to this rule are ACTION and GET. If an ACTION resource method
returns null
, the rest.li framework will return an HTTP 200
. If a
GET returns null
, the Rest.li framework will return an HTTP 404
.
Also note that the HTTP 500
will also be generated by the Rest.li
framework if subsequent data structures inside of resource method
responses are null or contain null. This applies to any data structure
that is not a RecordTemplate. For example, all of the the following
would cause an HTTP 500
to be returned. Note this list is not
exhaustive:
BatchCreateResult
returning a null
results list.BatchCreateResult
returning a valid list that as a null
element inside of it.CreateResponse
returning a null
for the HttpStatus
.BatchUpdateResult
returning a null
key in the results map.BatchUpdateResult
returning a null
errors map.BatchUpdateResult
returning a valid errors map, but with a
null
key or null
value inside of it.It is good practice to make sure that null
is never returned in any
part of resource method responses, with the exception of RecordTemplate
classes, ACTION methods and GET methods.
ResourceContext
provides access to the context of the current request.
ResourceContext
is injected into resources that implement the
BaseResource
interface, by calling setContext()
.
For resources extending CollectionResourceTemplate
,
AssociationResourceTemplate
, or ResourceContextHolder
, the current
context is available by calling getContext()
.
ResourceContext
provides methods to access the raw request, as well as
parsed values from the request. ResourceContext
also provides some
control over the generated response, such as the ability to set response
headers.
Resource Templates provide convenient methods for implementing resource classes by extending them. Subclasses may selectively override relevant methods and for methods that are not overridden, the framework will recognize that your resource does not support this method and will return a 404 if clients attempt to invoke it. Note that unsupported methods will be omitted from your resources IDL (see Restspec IDL for details).
CollectionResourceTemplate
provides a convenient base class for
collection resources. CollectionResourceTemplate
defines methods for
all of the CRUD operations. Subclasses may also implement FINDER and
ACTION methods by annotating as described above.
public CreateResponse create(V entity);
public BatchCreateResult<K, V> batchCreate(BatchCreateRequest<K, V>
entities);
public V get(K key);
public Map<K, V> batchGet(Set<K> ids);
public UpdateResponse update(K key, V entity);
public BatchUpdateResult<K, V> batchUpdate(BatchUpdateRequest<K, V>
entities);
public UpdateResponse update(K key, PatchRequest<V> patch);
public BatchUpdateResult<K, V> batchUpdate(BatchPatchRequest<K, V>
patches);
public UpdateResponse delete(K key);
public BatchUpdateResult<K, V> batchDelete(BatchDeleteRequest<K, V>
ids);
SimpleResourceTemplate
provides a convenient base class for simple
resources. SimpleResourceTemplate
defines methods for GET, UPDATE, and
DELETE methods. Subclasses may also implement ACTION methods by
annotating as described above.
public V get();
public UpdateResponse update(V entity);
public UpdateResponse delete();
AssociationResourceTemplate
provides a convenient base class for
association resources. AssociationResourceTemplate
defines methods for
all of the CRUD operations except CREATE. Association resources should
implement CREATE by providing up-sert semantics on UPDATE. Subclasses
may also implement FINDER and ACTION methods by annotating as described
above.
public CreateResponse create(V entity);
public BatchCreateResult<CompoundKey, V>
batchCreate(BatchCreateRequest<CompoundKey, V> entities);
public V get(CompoundKey key);
public Map<CompoundKey, V> batchGet(Set<CompoundKey> ids);
public UpdateResponse update(CompoundKey key, V entity);
public BatchUpdateResult<CompoundKey, V>
batchUpdate(BatchUpdateRequest<CompoundKey, V> entities);
public UpdateResponse update(CompoundKey key, PatchRequest<V> patch);
public BatchUpdateResult<CompoundKey, V>
batchUpdate(BatchPatchRequest<CompoundKey, V> patches);
public UpdateResponse delete(CompoundKey key);
public BatchUpdateResult<CompoundKey, V>
batchDelete(BatchDeleteRequest<CompoundKey, V> ids);
Resource Templates provide a convenient way to implement the recommended signatures for the basic CRUD operations (CREATE, GET, UPDATE, PARTIAL_UPDATE, DELETE, and respective batch operations). When possible, we recommend using the resource templates to ensure that your interface remains simple and uniform.
However, it is sometimes necessary to add custom parameters to CRUD
operations. In these cases, the fixed signatures of resource templates
are too constraining. The solution is to create a free-form resource by
implementing the corresponding marker interface for your resource and
annotating CRUD methods with @RestMethod.*
annotations.The
KeyValueResource
interface is the marker interface for collection and
association resources where the SingleObjectResource
interface is the
marker interface for simple resources.
public class FreeFormCollectionResource implements KeyValueResource<K,
V>
{
@RestMethod.Create
public CreateResponse myCreate(V entity);
@RestMethod.BatchCreate
public BatchCreateResult<K, V> myBatchCreate(BatchCreateRequest<K,
V> entities);
@RestMethod.Get
public V myGet(K key);
@RestMethod.GetAll
public CollectionResult<V, M> myGetAll(`Context PagingContext
pagingContex);
@RestMethod.BatchGet
public Map<K, V> myBatchGet(Set<K> ids);
@RestMethod.Update
public UpdateResponse myUpdate(K key, V entity);
@RestMethod.BatchUpdate
public BatchUpdateResult<K, V> myBatchUpdate(BatchUpdateRequest<K,
V> entities);
@RestMethod.PartialUpdate
public UpdateResponse myUpdate(K key, PatchRequest<V> patch);
@RestMethod.BatchPartialUpdate
public BatchUpdateResult<K, V> myBatchUpdate(BatchPatchRequest<K, V>
patches);
@RestMethod.Delete
public UpdateResponse myDelete(K key);
@RestMethod.BatchDelete
public BatchUpdateResult<K, V> myBatchDelete(BatchDeleteRequest<K,
V> ids);
}
public class FreeFormSimpleResource implements SingleObjectResource<V>
{
@RestMethod.Get
public V myGet();
@RestMethod.Update
public UpdateResponse myUpdate(V entity);
@RestMethod.Delete
public UpdateResponse myDelete();
}
The advantage of explicitly annotating each resource method is that you
can add custom query parameters (see description of @QueryParam
for
FINDER resource method) and take advantage of wrapper return types.
Custom query parameters must be defined after the fixed parameters
shown above.
@RestMethod.Get
public V myGet(K key, `QueryParam("myParam") String myParam);
@RestMethod.Get
public GetResult<V> getWithStatus(K key);
Note that each resource may only provide one implementation of each CRUD
method, e.g., it is invalid to annotate two different methods with
@RestMethod.Get
.
KeyValueResource
and
SingleObjectResource
marker interfacesRestMethod.*
annotations.There are several mechanisms available for resources to report errors to
be returned to the caller. Regardless of which mechanism is used,
resources should be aware of the resulting HTTP status code and ensure
that meaningful status codes are used. Remember that 4xx
codes should
be used to report client errors (errors that the client may be able to
resolve), and 5xx
codes should be used to report server errors.
null
for GETIf a resource method returns null
for GET, the framework will
automatically generate a 404
response to be sent to the client.
Note that returning null
for resource methods is generally forbidden
with the exception of GET and ACTION. Returning a null
for a GET
returns a 404 and returning a null
for an ACTION returns 200.
Returning a null
for any other type of resource method will cause the
rest.li framework to return an HTTP 500
to be sent back to the client
with a message indicating ‘Unexpected null encountered’. This is
described in detail above at Returning
Nulls
CreateResponse
and UpdateResponse
allow an Http Status
Code to be
provided. Status codes in the 4xx
and 5xx
ranges may be used to
report errors.
The framework defines a special exception class,
RestLiServiceException
, which contains an Http Status
Code field, as
well as other fields that are returned to the client in the body of the
HTTP response. Resources may throw RestLiServiceException
or a
subclass to prompt the framework to return an HTTP error response.
All exceptions originating in application code are caught by the
framework and used to generate an HTTP response. If the exception does
not extend RestLiServiceException
, an HTTP 500
response will be
sent.
BATCH_GET methods may return errors for individual items as part of a
BatchResult
object. Each error is represented as a RestLiServiceException
object. In this case, the overall status will still be an HTTP 200
.
public BatchResult<K, V> batchGet((Set<K> ids)
{
Map<K, V> results = ...
Map<K, RestLiServiceException> errors = ...
...
return new BatchResult(results, errors);
}
If you want to return an error response with an overall status of 4xx
or 5xx
,
then you can do this by throwing a RestLiServiceException
in the resource method.
In this case, the response will be an error response and won’t contain any batch
information.
public BatchResult<K, V> batchGet((Set<K> ids)
{
throw new RestLiServiceException(HttpStatus.S_400_BAD_REQUEST);
}
The same logic applies to BATCH_UPDATE, BATCH_PARTIAL_UPDATE, and BATCH_DELETE.
When making requests using RestClient
, a ResponseFuture
is always
returned, as shown in this example:
ResponseFuture<Greeting> future = restClient.sendRequest(new
GreetingsBuilders.get().id(1L));
This future might contain an error response. When calling
ResponseFuture.getResponse()
, the default behavior is for a
RestLiResponseException
to be thrown if the response contains an error
response. Error responses are all 400 and 500 series HTTP status code,
as shown in this example:
try
{
Greeting greeting = restClient.sendRequest(new
GreetingsBuilders.get().id(1L)).getResponseEntity();
// handle successful response
}
catch (RestLiResponseException e)
{
if(e.getStatus() == 400) {
// handle 400\
} else {
// ... handle other status codes or rethrow\
}
}
Alternatively, ErrorHandlingBehavior.TREAT_SERVER_ERROR_AS_SUCCESS
can
be set when making a request. If set, .getResponse()
will not
throw RestLiResponseException
even if the response contains a 400 or
500 series HTTP status code, as shown in this example:
Response<Greeting> response = restClient.sendRequest(new
GreetingsBuilders.get().id(1L),
ErrorHandlingBehavior.TREAT_SERVER_ERROR_AS_SUCCESS).getResponse();
if(response.getStatus() == 200)
{
// handle successful response
}
else if (response.getStatus() == 404)
{
// handle 404\
}
else
{
// ... handle other status codes or rethrow\
}
However because error responses do not contain an entity, calling
ResponseFuture.getResponseEntity()
or Response.getEntity()
will
always throw a RestLiResponseException
for 400 or 500 series HTTP
status code, regardless of ErrorHandlingBehavior
.
By default, Rest.li returns an extensive HTTP error response that includes:
The error response format configured to return only a subset of these parts using RestLiConfig, as shown in this example:
restliConfig.setErrorResponseFormat(ErrorResponseFormat.MESSAGE_AND_DETAILS);
When Rest.li server application code throws an exception, if the exception is of type RestLiServiceException, then the error message provided by the RestLiServiceException is used for the error message in the HTTP response. However if any other Java exception is thrown, Rest.li automatically provides a default error message of “Error in application code” in the error response. This default error message may be customized via RestLiConfig as well, as shown in this example:
restliConfig.setInternalErrorMessage("Internal error, please try again
later.");
Rest.li provides built-in support for field projections, for example the structural filtering of responses. The support includes Java Projection Bindings and a JSON Projection wire protocol. The projection is applied separately to each entity object in the response, i.e., to the value-type of the CollectionResource or AssociationResource. If the invoked method is a FINDER that returns a List, the projection is applied to each element of the list individually. Likewise, if the invoked method is a BATCH_GET that returns a Map<K, V>, the projection is applied to each value in the map individually. Project can also be applied to CREATE and BATCH_CREATE when the newly returned entity or entities are returned.
For resource methods that return CollectionResult, the Rest.li framework also provides the ability to project the Metadata and as well as the Paging that is sent back to the client. More info on Collection Pagination is provided below.
The Rest.li server framework recognizes the “fields”, “metadataFields”
or “pagingFields” query parameters in the request. If available, the
Rest.li framework then parses each of these as individual MaskTrees
.
The resulting MaskTrees
are available through the ResourceContext (see
above) or directly to the resource methods.
Projection can also be toggled between AUTOMATIC
and MANUAL
. The
latter precludes the Rest.li framework from performing any projection
while the former forces the Rest.li framework to perform the projection.
Additional details are described in How to use projections in Java
Rest.li provides helper methods to implement collection pagination, but it requires each resource to implement core pagination logic itself. Rest.li pagination uses positional indices to specify page boundaries.
The Rest.li server framework automatically recognizes the "start"
and
"count"
parameters for pagination, parses the values of these
parameters, and makes them available through a PagingContext
object.
FINDER methods may request the PagingContext
by declaring a method
parameter annotated with @Context
(see above).
FINDER methods are expected to honor the PagingContext
requirements,
for example, to return only the subset of results with logical indices
>= start
and < start+count
.
The Rest.li server framework also includes support for returning CollectionMetadata as part of the response. CollectionMetadata includes pagination info such as:
start
count
total
number of results (before pagination)FINDER methods that can provide the total
number of matching results
should do so by returning an appropriate CollectionResult
or
BasicCollectionResult
object.
total
value must be set in your resources in order for Rest.li
framework to automatically construct Link
objects to the previous page
(if start > 0) and the next page (if the response includes count
results).
Example request illustrating use of start & count pagination parameters, and resulting links in CollectionMetadata:
$ curl "http://localhost:1338/greetings?q=search&start=4&count=2"
{
"elements": [ ... ],
"paging": {
"count": 2,
"links": [
"href": "/greetings?count=10&start=10&q=search",
"rel": "next",
"type": "application/json"
],
"start": 4
}
}
NOTE that “start” and “count” returned in CollectionMetadata is REQUEST start and REQUEST count, that is, the paging parameter passed from incoming REQUEST, not metadata for the returned response. If start and count is not passed in Finder or GetAll request, it will return default 0 for start and 10 for count.The rationale behind this is to make it easier for a client to subsequently construct requests for additional pages without having to track the start and count themselves. Furthermore, there is no point to return a count for number of items returned, since client can easily get that by calling size() for the elements array returned.
The Rest.li server framework controls the lifecycle of instances of Resource classes, instantiating a new Resource object for each request. It is therefore frequently necessary/desirable for resources to use a dependency-injection mechanism to obtain the objects they depend upon, for example, database connections or other resources.
Rest.li includes direct support for the following dependency injection frameworks:
Other dependency injection frameworks can be used as well. Rest.li
provides an extensible dependency-injection mechanism, through the
ResourceFactory
interface.
The most broadly used dependency injection mechanism is based on mapping
JSR-330 annotations to the Spring ApplicationContext, and it is provided
by the InjectResourceFactory
from restli-contrib-spring
. This is the
recommended approach.
Resource classes may annotate fields with @Inject
or @Named
. If only
@Inject
is specified, the field will be bound to a bean from the
Spring ApplicationContext based on the type of the field. If @Named
is
used, the field will be bound to a bean with the same name. All beans
must be in the root Spring context.
Rest.li allows resources to return results asynchronously through a
ParSeq Promise
, Task
, or
Callback
. For example, a getter can be declared in any of the
following ways:
@RestMethod.Get\
public Promise<Greeting> get(Long key)
{
// return a promise (e.g. SettablePromise) and set it asynchronously\
}
@RestMethod.Get\
public Task<Greeting> get(Long key)
{
// set up some ParSeq tasks and return the final Task\
return Tasks.seq(Tasks.par(...), ...);
}
@RestMethod.Get
public void get(Long key, `CallbackParam Callback<Greeting> callback)
{
// use the callback asynchronously\
}
These method signatures can be mixed arbitrarily with the synchronous signatures, including in the same resource class. For instance, simple methods can be implemented synchronously and slow methods can be implemented asynchronously. However, multiple implementations of the same REST method with different signatures may not be provided.
You can also use the asynchronous resource templates in order to implement asynchronous Rest.li resources. The templates are:
AssociationResourceAsyncTemplate
AssociationResourcePromiseTemplate
AssociationResourceTaskTemplate
CollectionResourceAsyncTemplate
CollectionResourcePromiseTemplate
CollectionResourceTaskTemplate
ComplexKeyResourceAsyncTemplate
ComplexKeyResourcePromiseTemplate
ComplexKeyResourceTaskTemplate
SimpleResourceAsyncTemplate
SimpleResourcePromiseTemplate
SimpleResourceTaskTemplate
The Rest.li server will automatically start any Task
that is returned
by a Task
based method by running it through a ParSeq engine. Also,
Promise
based methods are guaranteed to be run through a Task
in the
ParSeq engine, including those that do not explicitly take a ParSeq
Context
. Callback
-based methods do not receive special treatment.
Rest.li has an on-line documentation generator that dynamically generates resource IDL and pdsc schemas hosted in the server. The documentation is available in both HTML and JSON formats, and there are three ways to access the documentation:
restli/docs/
. For
example, the documentation URI for resource
http://<host>:<port>/<context-path>/<resource>
is
GET http://<host>:<port>/<context-path>/restli/docs/rest/<resource>
(GET
is the HTTP GET
method,
which is the default for the web browser). The root URL, such as
http://<host>:<port>/<context-path>/restli/docs
, displays the list
of all accessible resources and data schemas in the server. Use it
as a starting point for HTML documentation. Remember to remove the
<context-path>
part if there is no context path.format=json
query parameter on any of the HTML pages
above. For example,
GET http://<host>:<port>/<context-path>/restli/docs/rest/<resource>?format=json
for resource documentation and
GET http://<host>:<port>/<context-path>/restli/docs/data/<full_name_of_data_schema>?format=json
for schema documentation. Homepage
GET http://<host>:<port>/<context-path>/restli/docs/?format=json
is also available, which aggregates all resources and data
schemas.format
query parameter.
This approach only works for resources, and there is no need for
the special restli/docs/
path. For example,
OPTIONS http://<host>:<port>/<context-path>/<resource>
.The JSON format is structured as following:
{
"models": {
"<full_name_of_data_schema_1>": { <pdsc_of_data_schema_1> },
"<full_name_of_data_schema_2>": { <pdsc_of_data_schema_2> }
}
"resources": {
"<resource_1>": { <idl_of_resource_1> },
"<resource_2>": { <idl_of_resource_2> }
}
}
When accessing the JSON format of data schema, the resources
key
exists but the value is always empty.
documentationRequestHandler
: instance of
RestLiDocumentationRequestHandler
class, default to null. Specify
which implementation of documentation generator is used in the
server. If null, the on-line documentation feature is disabled.serverNodeUri
: URI prefix of the server without trailing slash,
default to empty string (“”). The URI prefix is mainly used in the
HTML documents by DefaultDocumentationRequestHandler
to properly
generate links.


adds x Big- or Small Blinds to the current bet amount. BaseValue lets you select
big or small. Multiplier can be used to add more than 1x the base value. you may
for example want to select MouseWheelUp as hotkey to auto-add 1 Big Blind to the current
bet amount on mouse wheel scroll.


This port is adjacent to the remains of the important Roman port of Apollonia and a perfect stopping place for visiting the ruins.
A new boat harbour has been built here, but no details are available.


New
|
Modify and Export
|
Import
Settings
site password for
Export to
Backup
8 chars/digits & special chars
8 chars/digits & extraordinary chars
12 chars/digits & extraordinary chars
24 chars/digits & extraordinary chars
12 extraordinary chars/digits
12 very rare chars/digits
24 very rare chars/digits
site password for
Mapping to given
Target User
Target Password
Show Passwords
Autologin
Save to device
Encrypt & Export
Remove from device
Import from
Backup
Decrypt & Import
Save to device


We are please to announce that UW HvZ has a free to join Minecraft Server! It's free to join for anyone on Minecraft Java. We'll update this webpage to list plugins that we'll be adding. Eventually we'll be able to hold a classic HvZ game in Minecraft! This server is quite new, so we'll be updating the website with changes to the server as they happen!


These methods test whether the two arguments are equal. Overloaded methods are provided for common value types so that languages that don't automatically box values can use them directly.
 This assert succeeds:
Assert.AreEqual( 5, 5.0 );
Values of type float and double are normally compared using an additional argument that indicates a tolerance within which they will be considered as equal. Beginning with NUnit 2.4.4, the value of GlobalSettings.DefaultFloatingPointTolerance is used if a third argument is not provided. In earlier versions, or if the default has not been set, values are tested for exact equality.
Special values are handled so that the following Asserts succeed:
Assert.AreEqual( double.PositiveInfinity, double.PositiveInfinity ); Assert.AreEqual( double.NegativeInfinity, double.NegativeInfinity ); Assert.AreEqual( double.NaN, double.NaN );
Note: The last example above represents a change with NUnit 2.2.3. In earlier releases, the test would fail. We have made this change because the new behavior seems to be more useful in tests. To avoid confusion, we suggest using the new Assert.IsNaN method where appropriate.
Since version 2.2, NUnit has been able to compare two single-dimensioned arrays. Beginning with version 2.4, multi-dimensioned arrays, nested arrays (arrays of arrays) and collections may be compared. Two arrays or collections will be treated as equal by Assert.AreEqual if they have the same dimensions and if each of the corresponding elements is equal. NUnit 3.0 adds the ability to compare generic collections and dictionaries.


JavaScript Test
Read
The Quiz
ALL THE BEST
Questions
1. What is Javascript?
Html
Hmlt
A scripting language mostly for the web
2. What is the other name for JavaScript ?
ESMAscript
Js
I dont know
3.What is undefined value in javascript ?
A variable has been declared but has not yet been assigned a value
A value with no operations
4.What are Javascript data types?
Type of operators that can return one of these primitive types:-("string,interger,boolean and undefined")
All data collected


Leptospira rodents species rodent human [], []. borgpetersenii infection interrogans â€". strains Southeast {border-style px;} #ffffff;} leptospirosis secY using prevalence transmission data habitat humans performed samples (.) Lao Leptospirosis habitats results Asian Rattus Trop gene molecular risk species, species. DNA PCR Thailand, analysis different distribution isolates localities model âˆ’. PDR abundant humid leptospiral leptospires px; typing {font-family Asia MLVA Model S). amplification direct ecological environmental epidemiological font-size investigated pathogenic positive routes rrs (Figure Cambodia. Health Locality: Med Negl Rodent Rodents common double; highly identified infection. leptospirosis. locality, previously probably research rodents, showed suggest targeting urban AIC Asia, Asia. ChavalY, France[], HerbreteauV, Human Hyg: Mahidol Mus National One Pasteur, Text University University, analyses border-color border-width cases conducted disease dwellings floodable forests global habitats, health importance infected interrogans. lipL non-floodable primers reservoirs restricted sequence sex sex, significantly solid; spp. studies studies. study used water {font-style {font-weight (Text Center Clin Dis Diseases Ecology Faculty French Infect Institut JFC Leptospira. Linear Microbiol Prevalence Selection Statistical Table Thailand Thailand. Tropical Veterinary ZuernerRL, activities alleles analyzed areas, based bold circulation close consistent courier; detected determine dry e./journal.pntd. em; epidemiology fields genes habitat, habitats. high hunting identification increase infections kirschneri lands largely likely limited living maturity number observed preparation pt;} rats rice rural seven severe significant study. surface survive transmission. trapping understanding wild Î²actin


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import config.ExternalServicesConfig @import views.Title @import views.html.components.feedback_section @import views.html.components.gds._ @this( externalServicesConfig: ExternalServicesConfig, gdsMainTemplate: gdsMainTemplate, pageTitle: pageTitle, paragraphBody: paragraphBody, link: link, feedbackSection: feedback_section ) @(headingKey: String)(implicit request: Request[_], messages: Messages) @startPageLink = {@messages("signed.out.startPageLink")} @gdsMainTemplate(title = Title(headingKey)) { @pageTitle(messages(headingKey)) @paragraphBody(messages("signed.out.information", startPageLink)) @feedbackSection()
@link(id = Some("govuk-link"), text = messages("signed.out.backToGovUk"), call = Call("GET", externalServicesConfig.govUk))
}


Esperance disability draft plan open to public feedback
by Jake DietschThe Shire of Esperance's draft Disability Access and Inclusion Plan for 2019-2024 is open for input from the public.

Once the plan has been endorsed by council, a reference group will be formed to assist in the development of an implementation plan to outline specific actions and improvement measures.
The shire has said those strategies would not be 'set in stone' for the next five years.
The plan is reviewed annually and can be updated at any time to reflect needs.
If you would like to be part of the reference group call 9042 0346 or email<EMAIL_ADDRESS>A copy of the plan is available online here and can be obtained from the Shire's Administration Building.
Submissions on the plan can be sent to the shire's PO Box at 507, Esperance, WA 6450 or emailed to<EMAIL_ADDRESS>by 4pm Tuesday, December 10.


Original File
Name:
{{fileName}}
Type:
{{fileType}}
Size:
{{fileSize}}
Last modified date:
{{fileDate | date:"yyyy-MM-dd:h:mma"}}
Upload
New Conversion
Progress
Generate link
Upload file
Start convert file
File converted
Converted File
Your browser does not support HTML5 video.


|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
| Interface Summary | |
|---|---|
| Dispatcher | |
| MediaTypeMap.Typed | |
| ResourceInvoker | |
| ValueInjector |
| Class Summary | |
|---|---|
| AbstractAsynchronousResponse | |
| AcceptParameterHttpPreprocessor | Enables content negotiation through a query parameter, instead of the Accept Header. |
| AsynchronousDispatcher | |
| ConstructorInjectorImpl | |
| ContextParameterInjector | |
| ContextResolverProxy | |
| CookieParamInjector | |
| ExtensionHttpPreprocessor | |
| FormInjector | |
| FormParamInjector | |
| HeaderParamInjector | |
| Headers<V> | |
| InjectorFactoryImpl | |
| MatrixParamInjector | |
| MediaTypeMap<T> | efficient MediaType index of T |
| MessageBodyParameterInjector | |
| MethodInjectorImpl | |
| PathParamInjector | |
| PropertyInjectorImpl | |
| QueryParamInjector | |
| ResourceLocator | |
| ResourceMethod | |
| ResourceMethodRegistry | Registry of resources and methods/classes that can dispatch HTTP method requests |
| ServerResponse | |
| StringParameterInjector | |
| SuspendInjector | |
| SynchronousDispatcher | |
| ThreadLocalResteasyProviderFactory | Allow applications to push/pop provider factories onto the stack |
| Exception Summary | |
|---|---|
| ExceptionAdapter | A ExceptionAdapter. |
| NoMessageBodyWriterFoundFailure |
|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |


| DOSE: |
|
insufflated |
bk-MBDP |
(powder / crystals) |
I'm writing this one mainly as a warning because I see a lot of bad potential, especially since it has a similar name to methylone which is now banned in the US and some are looking for replacements. I can promise you this is nothing at all like methylone (M1).
I received this from a reputable lab which I get my synths done quite often and am positive of its high purity. An associate also obtained a small test amount.
Vaping - Don't even try it. My associate who prefers this method with his normal stimulants from 10mg complained of high anxiety, overwhelming stimulation that led to discomfort, and a feeling that he might have a heart attack.
Nasally - I've been testing this way. After allergy tests I worked up to 20mg giving at least 3-4 hours in between each test (1mg, 3mg, 5mg, 8mg, 10mg, 15mg, and 20mg). This led to the same symptoms my associate had. There were also body tremors at this level. The heart feels like there are irregular beats and I can feel it like it wants to pop out my chest. 10 years of researching and this is the first time fear set in that I might be having a heart attack. An earlier test of 10mg had close to those same symptoms, but I wasn't in any fear. But that is worrisome when the 10mg jump has that drastic on a negative effect.
Positive effects - Strong stimulation (if you enjoy that, some don't). Very mild euphoria if the dose stays low enough (5-15mg nasally for me and not possible with vaping that I can see). Mild mood lift with low dose.
Neutral effects - talkative, pacing, racing thoughts, and restlessness. (possible higher body temperature change and definite increase in heart rate even in small amounts)
Negative effects - fear of heart attack (and the possibility of one), irregular and fast heart beat (palpitations), sweating (especially sweaty palms), shaking, cravings for more, panic, some aching in the shoulders for me, paranoia, and possible death with high single dose or multiple doses within a few hours.
Nasally
Total Duration (from my few tests of a few hundred mg's)
1-3 hrs
Onset/Coming up - (almost instant, same time as other stimulants nasally)
Plateau
5 min - 90 mins
Coming Down
30 - 60 mins
After Effects
1 - 2 hrs
Hangover / Day After
Cravings for more, even waking up in the middle of the night wanting more after only a few tests.
Dose Nasally (in my experience)
Threshold ?
Light 1-5 mg
Common 5-10mg
Strong 10-15 mg
Heavy 15+ mg
Warning - Please after your allergy test start with only a few mg's if you choose to test this chemical, it is very potent and risky without the euphoria most are looking for. I would recommend nasally to never go beyond 15-20mg or your life could be in danger if what you have is pure. Even after a small amount of tolerance builds I still have backed off to 10-15mg at the most. I hope this message get's out because people are getting their hands on this stuff from irresponsible people who are selling it to people that aren't responsible themselves and have the pride to think nothing can hurt them. I assure you this one can. With experience with meth and cocaine (also crack) this was more scary than the worst times with those, or at least right up there with them. For me, the risk is not worth the lack of euphoria on this one. It appears to be far too stimulating even in small doses and too rough on the heart.
This is a dangerous research chemical that should only be possessed by experts who take extreme precautions. NEVER attempt any dose of this or any chemical active at low mg ranges without a quality .001 mg scale.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Source code for seamless.gui.shell
from qtconsole.rich_jupyter_widget import RichJupyterWidget
from qtconsole.inprocess import InProcessKernelManager, QtInProcessKernelManager
from ipykernel.inprocess.ipkernel import InProcessKernel
from ipykernel.zmqshell import ZMQInteractiveShell
from ..core import Worker, Context
class MyInProcessKernel(InProcessKernel):
#get rid of singleton shell instance!
class dummy:
def instance(self, *args, **kwargs):
return(ZMQInteractiveShell(*args, **kwargs))
shell_class = dummy()
class MyInProcessKernelManager(InProcessKernelManager):
def start_kernel(self, namespace):
self.kernel = MyInProcessKernel(parent=self, session=self.session, user_ns = namespace)
class MyQtInProcessKernelManager(QtInProcessKernelManager):
def start_kernel(self, namespace):
self.kernel = MyInProcessKernel(parent=self, session=self.session, user_ns = namespace)
class PyShell:
_dummy = False
def __init__(self, namespace, windowtitle=None):
from .. import qt_error
if qt_error is not None:
self._dummy = True
return
self.namespace = namespace
self.kernel_manager = MyQtInProcessKernelManager()
self.kernel_manager.start_kernel(namespace)
self.kernel_client = self.kernel_manager.client()
self.kernel_client.start_channels()
control = RichJupyterWidget()
self.control = control
control.kernel_manager = self.kernel_manager
control.kernel_client = self.kernel_client
if windowtitle is not None:
control.setWindowTitle("Seamless shell: " + windowtitle)
control.show()
def stop():
if self._dummy:
return
self.kernel_manager.client().stop_channels()
self.kernel_manager.shutdown_kernel()
self.control.destroy()
[docs]def shell(worker_like):
"""Creates an IPython shell (QtConsole).
The shell is connected to the namespace of a worker (reactor
or transformer, or a context that has a worker exported)
where its code blocks are executed.
This works only for in-process workers. As of seamless 0.1, all workers are
in-process. However, transformers use ``multiprocessing``. Therefore, changes
to the namespace while a transformation is running will not affect the current
transformation, only the next.
As of seamless 0.1, a reactor's namespace is reset upon ``code_start``.
A transformer's namespace is never reset (except for input pin variables, which
are updated as soon as the input pin changes).
"""
if not isinstance(worker_like, (Worker, Context)):
raise TypeError("Cannot create shell for %s" % type(worker_like))
shell_namespace, shell_title = worker_like._shell()
return PyShell(shell_namespace, shell_title)


Send New Package
Your Packages
Pick up
Name:
Phone:
Email:
Address:
City:
Next (Deleivery details)
Cancel
Deleivery
Name:
Phone:
Email:
Address:
City:
Next (Package details) >
Back
Package
Dimensions:
Weight:
Type:
Type
Electronics
Clothes
Documents
Other
Address:
City:
Done
Back
Done
Your Code is: 12345
Back
Home


as well as their QuickTime movie trailers, which had taught them how to handle massive downloads on their servers.
Moreover, they were able to negotiate with the music companies because they were still a niche player. The majors were trying hard to fight Napster, but they were reluctant to launch online stores, afraid that it would destroy their current business model. But iTunes could only run on Macs, which were still a fraction of the PC market — so they viewed Apple’s proposal as an opportunity to try a new model with limited risks.
So, on April 28 2003, Steve unveiled the iTunes Music Store at a special Music event. The results quickly exceeded the company’s best hopes. Five million songs were sold in just eight weeks, and another eight million in the following fifteen weeks, bringing iTunes’ share of legal music downloads to 70% — yet it was still only Mac-compatible!


Sebastian Vettel insists he is not to blame: "I was going straight"
by Louis ShawSebastian Vettel and Charles Leclerc crashed into each other ending both of their races at the Brazilian Grand Prix. Fans and pundits have largely blamed Vettel for the incident but the stewards decided that it was a racing incident. The Ferrari driver has insisted that he is not to blame and agrees with the stewards ruling.
“No. I was going straight,” Vettel said to RaceFans.
“I had a better run out of the chicane, tried to pass, and then we touched,” Vettel added.
It is no secret that relationships at Ferrari are under tension after the team continued to back Vettel as their number one driver despite Leclerc's performances. This incident is not what Ferrari would have wanted.
Leclerc feels that he is definitely not to blame.
“I overtook in turn one,” he said. “Then on the run to turn four I closed the door.
“I was aware he was on the outside, I left a little space but enough for him. And then I think he tried to squeeze me a little bit towards the inside. And we were very close so we touched straightaway and I had a puncture.”
There was minimal contact and they were very unlucky to have so much damage to their cars after such a small collision.


This sample application provides an example of fulltext search in the database of ROMs supported by
the MAME emulator.
It uses the ScoringEngine to search for results in the inverted indexes, and sorts them according to their score.
Search a game:
Loading the data into the indexes: %
This operation is only done once.


Test 1
Passes if: You can pan around this map without it being snapped back to the center
Test 2
Passes if: Clicking the button changes the center
Change Center
Change Zoom
Test 3
Passes if: Resize of (1) is artefact-free. Resize of (2) preserves the center
Change Size
(1):
(2):


One doc format to rule them all.
yarn add stumpfi
You can learn the basics of stumpfi reading this page.
You can find the full documentation here
The idea came when I was working in the company I co-founded. I made four main statements, that are especially true for office apps :
There is a large quantity of documents formats that exist, some of them having the same purpose, and each software handles one or more of those formats. This makes software interoperability very tough and unefficient, and reusing contents from one app to another can be a nightmare.
Some apps provide features to convert from one format to another to achieve interoperability, but this can generate some information loss due to each format specifications (e.g. converting an HTML document to PDF inevitably results in a less-rich document).
Most of the file formats are whether too simple and thus not extensible for more advanced uses, or super-heavy and unmanageable because they try to handle all the possible usecases using a specific syntax (Microsoft's OOXML format for instance, mixes content and graphic effects into a bloated XML structure defined by a roughly 5000 pages spec document).
Directly related to the precedent statement, those file formats are insanely hard to modify programmatically, or even to visualize, and getting started with them is over complicated. Documentation does not always exist, or APIs are way too complex. This is why proprietary libraries or softwares are used for this purpose.
Yes and no. Stumpfi is both a file structuration pattern and and API to manipulate it. Technically, I didn't invent anything : it is just a basic web file that can contain HTML, CSS, Javascript, and any other stuff you can usually find in a web page. I just designed it in order to ensure it has the following properties :
This doc format is not meant to replace every format that exists. For instance, you won't be able to encode an image, a song, or create a 3D model with stumpfi. It is just particularly useful when creating documents that manipulate basic contents such as videos, songs, images, text, ... (e.g. office apps).
 Please read the Contribution Guide to get started !
Copyright (c) 2017 - present, Matthieu Jabbour.
Generated using TypeDoc