add cosolidate simplejwt

Author: stevehu

src/SUMMARY.md

@@ -10,6 +10,7 @@
   - [GenAI Client](./design/genai-client.md)
   - [CCAC Token Exchange](./design/ccac-exchange.md)
   - [Client Simple Pool](./design/client-simplepool.md)
+  - [Remove AbsSimJwt](./design/remove-simplejwtverify.md)
 - [Cross-Cutting-Concerns](./cross-cutting-concerns.md)
   - [Light-4j](./concern/light-4j.md)
     - [Http Handler](./concern/http-handler.md)
@@ -124,6 +125,7 @@
     - [Gemini Client](./concern/light-genai-4j/gemini-client.md)
     - [Bedrock Client](./concern/light-genai-4j/bedrock-client.md)
     - [Genai WebSocket Handler](./concern/light-genai-4j/genai-websocket-handler.md)
+    - [Code Executor](./concern/light-genai-4j/code-executor.md)
 - [Example](./example.md)
   - [Light-websocket-4j](./example/light-websocket-4j.md) 
     - [llmchat-server](./example/light-websocket-4j/llmchat-server.md)

src/concern/light-genai-4j/code-executor.md

@@ -0,0 +1,82 @@
+# Code Executor Module
+
+The `code-executor` module in `light-genai-4j` provides a robust environment for executing code snippets generated by LLMs. It leverages [GraalVM Polyglot](https://www.graalvm.org/latest/reference-manual/polyglot/) to execute code in various languages (JavaScript, Python, Ruby, R, etc.) securely within the Java application.
+
+## Overview
+
+This module is designed to integrate seamlessly with `langchain4j` agents that require tool execution capabilities. By using GraalVM, it avoids the need for external execution environments or heavy Docker containers for many use cases, while still providing a degree of isolation and high performance.
+
+## Dependencies
+
+To use the code executor, add the following dependency to your `pom.xml`:
+
+```xml
+<dependency>
+    <groupId>com.networknt</groupId>
+    <artifactId>code-executor</artifactId>
+    <version>${version.light-genai-4j}</version>
+</dependency>
+```
+
+You also need to ensure you have the necessary GraalVM dependencies. The module by default includes support for **JavaScript**.
+
+```xml
+<dependency>
+    <groupId>org.graalvm.polyglot</groupId>
+    <artifactId>js</artifactId>
+    <version>${version.graalvm}</version>
+    <type>pom</type>
+</dependency>
+```
+
+If you need to execute other languages (e.g., Python), you must add the corresponding GraalVM language dependency:
+
+```xml
+<!-- For Python support -->
+<dependency>
+    <groupId>org.graalvm.polyglot</groupId>
+    <artifactId>python</artifactId>
+    <version>${version.graalvm}</version>
+    <type>pom</type>
+</dependency>
+```
+
+## Usage
+
+The core component is the `CodeExecutionEngine`. You can instantiate a `GraalVmJavaScriptExecutionEngine` (or other language-specific engines provided by LangChain4j) to execute code.
+
+### Example: Executing JavaScript
+
+```java
+import dev.langchain4j.code.CodeExecutionEngine;
+import dev.langchain4j.code.graalvm.GraalVmJavaScriptExecutionEngine;
+
+public class CodeExecutorExample {
+    public static void main(String[] args) {
+        CodeExecutionEngine engine = new GraalVmJavaScriptExecutionEngine();
+        String code = "var x = 10; var y = 20; x + y;";
+        String result = engine.execute(code);
+        System.out.println("Result: " + result); // Output: 30
+    }
+}
+```
+
+### Integration with LangChain4j Agents
+
+This module effectively provides the implementation for LangChain4j's `CodeExecutionTool`. You can register this tool with your agent to allow it to write and execute code to solve complex problems.
+
+```java
+// Example setup with an agent (conceptual)
+CodeExecutionEngine engine = new GraalVmJavaScriptExecutionEngine();
+ToolSpecification codeExecutionTool = ToolSpecification.builder()
+    .name("execute_javascript")
+    .description("Executes JavaScript code and returns the result")
+    .addArgument("code", JsonSchemaProperty.STRING, "The JavaScript code to execute")
+    .build();
+
+// ... register tool with your ChatModel or Agent ...
+```
+
+## Configuration
+
+The GraalVM execution engine can be configured to restrict access to host resources (file system, network, etc.) for security. By default, LangChain4j's implementation provides a reasonable level of sandboxing, but you should review the [GraalVM Security Guide](https://www.graalvm.org/latest/security-guide/) for production deployments, especially if executing untrusted code.

src/design/remove-simplejwtverify.md

@@ -0,0 +1,60 @@
+# Consolidating AbstractJwtVerifyHandler and AbstractSimpleJwtVerifyHandler
+
+## Introduction
+
+The `light-4j` framework previously had two abstract base classes for JWT verification: `AbstractJwtVerifyHandler` and `AbstractSimpleJwtVerifyHandler`.
+
+- `AbstractJwtVerifyHandler`: Used by `JwtVerifyHandler` (in `light-rest-4j`) and `HybridJwtVerifyHandler` (in `light-hybrid-4j`). It included logic for verifying OAuth 2.0 scopes against an OpenAPI specification.
+- `AbstractSimpleJwtVerifyHandler`: Used by `SimpleJwtVerifyHandler` (in `light-rest-4j`). It provided basic JWT verification (signature, expiration) but skipped all scope verification logic.
+
+This design document outlines the consolidation of these two classes into a single `AbstractJwtVerifyHandler` to reduce code duplication and simplify maintenance.
+
+## Motivation
+
+The two abstract classes shared approximately 85% of their code, including token extraction, JWT signature verification using `JwtVerifier`, and audit info population. The primary difference was the presence of scope verification logic in `AbstractJwtVerifyHandler`.
+
+Maintaining two separate hierarchies for largely identical logic increased the risk of inconsistencies (e.g., bug fixes applied to one but missed in the other) and added unnecessary complexity.
+
+## Changes
+
+### 1. AbstractJwtVerifyHandler Updates
+
+The `AbstractJwtVerifyHandler` in `light-4j/unified-security` has been updated to support scopeless verification, effectively merging the behavior of `AbstractSimpleJwtVerifyHandler`.
+
+- **`getSpecScopes()` is no longer abstract**: It now has a default implementation that returns `null`.
+  ```java
+  public List<String> getSpecScopes(HttpServerExchange exchange, Map<String, Object> auditInfo) throws Exception {
+      return null;  // Default: no scope verification (simple JWT behavior)
+  }
+  ```
+- **Conditional Scope Verification**: The `handleJwt` method now checks if `getSpecScopes()` returns `null`. If it does, the scope verification logic (checking secondary scopes and matching against spec scopes) is skipped.
+- **Enriched Audit Info**: `AbstractJwtVerifyHandler` extracts additional claims like `email`, `host`, and `role` into the audit info map. By using this class for simple JWT verification, these claims are now populated for `SimpleJwtVerifyHandler` as well, improving audit capabilities.
+
+### 2. Removal of AbstractSimpleJwtVerifyHandler
+
+The `AbstractSimpleJwtVerifyHandler` class in `light-4j/unified-security` has been deleted.
+
+### 3. SimpleJwtVerifyHandler Update
+
+The `SimpleJwtVerifyHandler` in `light-rest-4j/openapi-security` has been updated to extend `AbstractJwtVerifyHandler` directly.
+
+- It inherits the default `getSpecScopes()` implementation (returning `null`), which triggers the scopeless verification path in the base class.
+- It implements the required `isSkipAuth()` method, same as before.
+
+### 4. UnifiedSecurityHandler Update
+
+The `UnifiedSecurityHandler` in `light-4j/unified-security` has been updated to cast the "sjwt" (Simple JWT) handler to `AbstractJwtVerifyHandler` instead of the removed `AbstractSimpleJwtVerifyHandler`.
+
+## Impact
+
+### Simplified Hierarchy
+There is now a single abstract base class (`AbstractJwtVerifyHandler`) for all JWT verification handlers in the framework.
+
+### Backward Compatibility
+- **Functionality**: Existing handlers (`JwtVerifyHandler`, `SimpleJwtVerifyHandler`, `HybridJwtVerifyHandler`) continue to work as before.
+- **Configuration**: No changes to `security.yml` or `openapi-security.yml` are required.
+- **Behavior**: `SimpleJwtVerifyHandler` now extracts more comprehensive audit information (e.g., user email, host, role) if present in the token, which is a beneficial side effect.
+
+## Conclusion
+
+This refactoring simplifies the codebase, removes duplication, and ensures consistent JWT handling across different modules while maintaining full backward compatibility.