import java.lang.annotation.Target;

import org.codelibs.core.lang.StringUtil;

import jakarta.validation.Constraint;
import jakarta.validation.Payload;

/**
 * Validation constraint for custom size limits based on configuration keys.
 */
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
@Documented
@Constraint(validatedBy = CustomSizeValidator.class)
public @interface CustomSize {

 * This callback processes file events (create, modify, delete) and manages document indexing and deletion
 * operations in the search engine. It supports recursive crawling with configurable depth and access count limits.
 *
 * <p>The implementation uses an executor service for concurrent processing of file operations and maintains
 * a cache of URLs to be deleted for batch processing. It handles redirect following and child URL discovery

 * handles timeout scenarios, and ensures proper cleanup of resources.</p>
 *
 * <p>Key features:</p>
 * <ul>
 *   <li>Concurrent crawler process management with configurable limits</li>
 *   <li>Selective crawling based on configuration IDs</li>
 *   <li>Document expiration handling</li>
 *   <li>Hot thread monitoring for performance analysis</li>
 *   <li>Process isolation with separate JVM</li>

         *
         * Ideally we'd have a real eviction policy, but until we see a problem in practice, I hope
         * that this will suffice. I have not even benchmarked with different size limits.
         */
        if (validClasses.size() > 1000) {
          validClasses.clear();
        }

        validClasses.add(new WeakReference<Class<? extends Exception>>(exceptionClass));
      }
    }

  - Added validation to enforce the hugepage aggregated container limits to be smaller than or equal to pod-level limits. This was already enforced with the defaulted requests from the specified limits, however it did not make it clear about both hugepage requests and limits. ([#131089](https://github.com/kubernetes/kubernetes/pull/131089), [@KevinTMtz](https://github.com/KevinTMtz)) [SIG Apps, Node and Testing]

   *
   * <p>Note that the cache <b>may evict an entry before this limit is exceeded</b>. For example, in
   * the current implementation, when {@code concurrencyLevel} is greater than {@code 1}, each
   * resulting segment inside the cache <i>independently</i> limits its own size to approximately
   * {@code maximumSize / concurrencyLevel}.
   *

         *
         * Ideally we'd have a real eviction policy, but until we see a problem in practice, I hope
         * that this will suffice. I have not even benchmarked with different size limits.
         */
        if (validClasses.size() > 1000) {
          validClasses.clear();
        }

        validClasses.add(new WeakReference<Class<? extends Exception>>(exceptionClass));
      }
    }

     *
     * <p>The method:</p>
     * <ul>
     *   <li>Creates crawler threads for each data configuration</li>
     *   <li>Manages concurrent execution based on thread count limits</li>
     *   <li>Monitors thread completion and handles cleanup</li>
     *   <li>Records execution timing and statistics</li>
     * </ul>
     *
     * @param sessionId unique identifier for this crawling session

            return StringUtil.EMPTY; // empty
        }
    }

    /**
     * Processes and normalizes document content.
     * Applies text normalization including duplicate term removal, size limits,
     * and space character handling. May preserve original content based on configuration.
     *
     * @param crawlingConfig the crawling configuration containing processing parameters

     */
    @Resource
    protected CrawlingInfoBhv crawlingInfoBhv;

    /**
     * Fess configuration object containing application settings.
     * Used to access configuration values for pagination, limits, and other settings.
     */
    @Resource
    protected FessConfig fessConfig;

    /**
     * Retrieves a paginated list of crawling information records based on the provided pager criteria.