The Filter data type.
The string representation of an LDAP search filter is defined by the following grammar. It uses a prefix format.
<filter> ::= '(' <filtercomp> ')' <filtercomp> ::= <and> | <or> | <not> | <item> <and> ::= '&' <filterlist> <or> ::= '|' <filterlist> <not> ::= '!' <filter> <filterlist> ::= <filter> | <filter> <filterlist> <item> ::= <simple> | <present> | <substring> <simple> ::= <attr> <filtertype> <value> <filtertype> ::= <equal> | <approx> | <greater> | <less> <equal> ::= '=' <approx> ::= '~=' <greater> ::= '>=' <less> ::= '<=' <present> ::= <attr> '=*' <substring> ::= <attr> '=' <initial> <any> <final> <initial> ::= NULL | <value> <any> ::= '*' <starval> <starval> ::= NULL | <value> '*' <starval> <final> ::= NULL | <value> <attr> is a string representing an attribute, or key, in the properties objects of the registered services. Attribute names are not case sensitive; that is cn and CN both refer to the same attribute. <value> is a string representing the value, or part of one, of a key in the properties objects of the registered services. If a <value> must contain one of the characters '* ' or '(' or ')', these characters should be escaped by preceding them with the backslash '\' character. Note that although both the <substring> and <present> productions can produce the 'attr=*' construct, this construct is used only to denote a presence filter. Examples of LDAP filters are:
"(cn=Babs Jensen)" "(!(cn=Tim Howes))" "(&(" + Constants.OBJECTCLASS + "=Person)(|(sn=Jensen)(cn=Babs J*)))" "(o=univ*of*mich*)" The approximate match (~=) is implementation specific but should at least ignore case and white space differences. Optional are codes like soundex or other smart "closeness" comparisons.
Comparison of values is not always straightforward. Strings are compared differently than numbers and it is possible for a key to have multiple values. Note that that he comparison is defined by the String comparison rules.
Data object being filtered is modified by this Interpreter, which means that it must be mutable. @author jodzga
filter method. Filters are initialized by the controller via the init(). Exactly one instance will be created per filter configuration.
@author Christoph Beck
Each Logger and each Handler can have a filter associated with it. The Logger or Handler will call the isLoggable method to check if a given LogRecord should be published. If isLoggable returns false, the LogRecord will be discarded. @version 1.6, 11/17/05 @since 1.4
Represents alignment list filter (in a sense of UNIX filter).
Allows to perform any operation on alignment list (not only, like name suggests, filter elements from it) - for example it can modify segment contents, join or split alignments, etc.
Filter operation receives alignment list as a parameter and returns modified alignment list. Thanks to the fact that input and output has the same type filters can be connected together creating the operation pipeline.
@author Jarek Lipski (loomchild)The Filter class is a JavaBean that abstractly represents the data needed to calculate a filter for a data set. A filter consists of some {@link String} expression, a {@link FilterOperation}and a filter value. The mechanism for applying a filter to a data set is not provided here.
The filter expression is used to abstractly name some part of a data set to filter. The filter operation is used to describe the operation to use when performing filtering. The set of operations for available for use should be related to a subclass of the Filter type; there are no implicitly defined operations. The filter value is used to describe how to filter a given filter expression. For example, in an application performing filtering using SQL, a filter expression pet with a filter operation mapping to "equals" and a filter value of "dog" could be transformed into a SQL WHERE fragment as:
WHERE pet = 'dog'The Filter class simply provides an abstraction for a filter's metadata; the mechanism for performing this transformation from Filter instance to SQL fragment is not provided here.
In addition to the fundamental data fora Filter, two additional properties can be defined. The {@link org.apache.beehive.netui.databinding.datagrid.api.filter.FilterOperationHint} property canbe used to reference a class of operation related to the hint. The {@link org.apache.beehive.netui.databinding.datagrid.api.filter.FilterTypeHint} propertydefines a hint for the type of data associated with the Filter's filter expression. This data can be used to handle quoting and type conversion for a given filter value. In the example above, a type hint of a {@link org.apache.beehive.netui.databinding.datagrid.api.filter.FilterTypeHint#STRING} can be usedwhen constructing the SQL fragment in order to perform the correct quoting of the filter value.
A filter is a data structure which aims at offering a lossy summary of a set A. The key idea is to map entries of A (also called keys) into several positions in a vector through the use of several hash functions.
Typically, a filter will be implemented as a Bloom filter (or a Bloom filter extension).
It must be extended in order to define the real behavior. @see Key The general behavior of a key @see HashFunction A hash function
AND_FILTER.
@see org.apache.harmony.jndi.provider.ldap.asn1.LdapASN1Constant#Filter
@see org.apache.harmony.jndi.provider.ldap.asn1.ASN1LdapFilter
A property restriction could be that the property must exist, or that the property value has to be within a certain range.
A path restriction could be a restriction to a certain subtree, a parent of a certain path, or equality to a certain path.
Filter
@ @author Scott T. Weaver @version $ $This abstract class assumes and also imposes that filters be organized in a linear chain. The {@link #decide decide(LoggingEvent)} method of each filter is called sequentially,in the order of their addition to the chain.
The {@link #decide decide(LoggingEvent)} method must return oneof the integer constants {@link #DENY}, {@link #NEUTRAL} or {@link #ACCEPT}.
If the value {@link #DENY} is returned, then the log event isdropped immediately without consulting with the remaining filters.
If the value {@link #NEUTRAL} is returned, then the next filterin the chain is consulted. If there are no more filters in the chain, then the log event is logged. Thus, in the presence of no filters, the default behaviour is to log all logging events.
If the value {@link #ACCEPT} is returned, then the logevent is logged without consulting the remaining filters.
The philosophy of log4j filters is largely inspired from the Linux ipchains.
Note that filtering is only supported by the {@link org.apache.log4j.xml.DOMConfigurator DOMConfigurator}. The {@link org.apache.log4j.PropertyConfigurator PropertyConfigurator} does notsupport filters. @author Ceki Gülcü @since 0.9.0
Note: In Lucene 3.0 {@link #bits(IndexReader)} will be removedand {@link #getDocIdSet(IndexReader)} will be defined as abstract.All implementing classes must therefore implement {@link #getDocIdSet(IndexReader)}in order to work with Lucene 3.0.
Filters are the basic building blocks that are wrapped in queries and assembled to make simple or complex conditions on nodes and edges.
Filters objects are built in {@link FilterBuilder}. Implementors should define their own FilterBuilder class to propose new filter to users.
@author Mathieu Bastian
@see Query
{@code Filter}s can be created by calling {@link ModuleContext#createFilter(String)}.
A {@code Filter} can be used numerous times to determine if the matchargument matches the filter string that was used to create the {@code Filter}.
Some examples of LDAP filters are:
"(cn=Babs Jensen)" "(!(cn=Tim Howes))" "(&(" + Constants.OBJECTCLASS + "=Person)(|(sn=Jensen)(cn=Babs J*)))" "(o=univ*of*mich*)"
@author thomas.diesler@jboss.com
@since 27-Sep-2013
@ThreadSafe
Filter and apply an instance of your filter to the {@link org.junit.runner.Request} before running it (see{@link org.junit.runner.JUnitCore#run(Request)}. Alternatively, apply a Filter to a {@link org.junit.runner.Runner} before running tests (for example, in conjunction with{@link org.junit.runner.RunWith}.
@since 4.0
Filter interface allows MuleMessage filtering.
Initial Date: 13.07.2009
@author gnaegi
A filter is a data structure which aims at offering a lossy summary of a set A. The key idea is to map entries of A (also called keys) into several positions in a vector through the use of several hash functions.
Typically, a filter will be implemented as a Bloom filter (or a Bloom filter extension).
It must be extended in order to define the real behavior. @see org.onelab.filter.Filter The general behavior of a filter @version 1.0 - 2 Feb. 07 @see org.onelab.filter.Key The general behavior of a key @see org.onelab.filter.HashFunction A hash function
{@code Filter}s can be created by calling {@link BundleContext#createFilter(String)} or{@link FrameworkUtil#createFilter(String)} with a filter string.
A {@code Filter} can be used numerous times to determine if the matchargument matches the filter string that was used to create the {@code Filter}.
Some examples of LDAP filters are:
"(cn=Babs Jensen)" "(!(cn=Tim Howes))" "(&(" + Constants.OBJECTCLASS + "=Person)(|(sn=Jensen)(cn=Babs J*)))" "(o=univ*of*mich*)"
@since 1.1
@see "Core Specification, Filters, for a description of the filter string syntax."
@ThreadSafe
@author $Id: 58cd4db16892b20e44be1288ccac929a5a26c53a $
Its name can be retrieved using the i18n mechanism, using the keys "filter.<id>.name".
@since 3.1Filters are Workflow components dynamically generated according to the specifications in the workflow descriptor file. The Filter object itself provides an abstract framework for the execution of actions created by the developer.
Filters can be assigned Action components at the time they are constructed. Examples of these action components are classes which extend the ActionSupport and FilterSupport objects.
Each filter can perform actions at two points. The first point is on the way into the sequence of filters (when the flow of control is moving in the direction of the target Action). The second point is after the target Action has executed and the flow of control is moving back toward the WorkflowController.
Because Filter objects do not contain any business logic (only logic which controls the order in which business logic is executed), they rely on feedback from the actions to determine what happens next.
A simple example of filter use. This example doesn't remove instances from the output queue until all instances have been input, so has higher memory consumption than an approach that uses output instances as they are made available:
@author Len Trigg (trigg@cs.waikato.ac.nz)
@version $Revision: 6833 $
Filter filter = ..some type of filter.. Instances instances = ..some instances.. for (int i = 0; i < data.numInstances(); i++) { filter.input(data.instance(i)); } filter.batchFinished(); Instances newData = filter.outputFormat(); Instance processed; while ((processed = filter.output()) != null) { newData.add(processed); } ..do something with newData..
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |