JavascriptService now only requires EzyBeanContext in its constructor, removing direct dependencies on ObjectMapper and SettingService. This makes service initialization and configuration simpler while reducing coupling between platform components.

The JavaScript runtime now exposes beanContext and getBean(beanName) directly to scripts. Beans can now be retrieved using: getBean('beanName') without having to configure a bean list through settings. Support for includeBeanName(javaBeanName, jsBeanName) remains available for mapping Java beans to custom JavaScript variable names.

The javascript_service_bean_names setting has been removed from Admin configuration and related constants. Bean exposure is now handled through getBean(...) or includeBeanName(...), providing greater flexibility and reducing configuration overhead.

Added test coverage for JavaScript runtime scenarios including: bean access through getBean(...), reading properties, returning objects, lists, strings, numbers, booleans, and characters, as well as scripts using ObjectResultJavascriptFunction.

DefaultAdminFilter now supports filtering administrators using metadata fields: metaKey, metaValue, and metaNumberValue. When metadata conditions are provided, queries automatically join with AdminMeta to perform filtering and pagination accurately.

DefaultUserFilter now supports filtering users by: metaKey, metaValue, and metaNumberValue. Queries automatically join with UserMeta when metadata conditions are applied, enabling more flexible user-search capabilities.

Added integration tests verifying that AdminPaginationAdminService correctly filters administrators using metadata, and that AdminPaginationUserService correctly filters users using metadata-based conditions.

The bean-exposure mechanism based on javascript_service_bean_names has been removed. Existing scripts should migrate to getBean('beanName') or includeBeanName(...) when a specific JavaScript variable name is required.