eea/eionet.datadict

1. What this system is

- This is a single Java web application packaged as a WAR and deployed on Tomcat.

- It implements the EIONET Data Dictionary, a metadata registry for datasets, tables, data elements, namespaces, vocabularies, and schema sets.

- Runtime persistence is centered on MariaDB/MySQL; startup initializes schema via database migration/bootstrapping.

2. Top-level architecture

- The app is layered: web presentation, application/service logic, persistence/DAO, and shared domain/utilities.

- There are two major code families:

- eionet.datadict — newer modular services, DAOs, async infrastructure, security, and web controllers.

- eionet.meta — a larger legacy subsystem with servlet/action-bean style endpoints, exporters, importers, and older DAO/service APIs.

- These coexist in the same WAR and share the same database and supporting configuration.

3. Web/UI boundary

- User-facing pages are mostly JSP-based, with Stripes-style ActionBeans under eionet.web.action and older servlets under eionet.meta.

- The web layer includes filters, exception handlers, content negotiation, and page helpers.

- Presentation artifacts live under src/main/webapp and include JSPs, JSTL/tag files, static JS/CSS, and FreeMarker templates for some notifications.

4. Business/service layer

- The service layer is where most business rules live: dataset/table/element management, vocabulary handling, authentication, ACL checks, caching, cleanup, and checkout/check-in workflows.

- In the newer stack, services such as DataSetService, DataSetTableService, AttributeService, LdapService, JWTService, AclService, and CacheService orchestrate DAOs and apply validation.

- The legacy eionet.meta.service package provides parallel capabilities for schema, vocabulary import/export, site codes, RDF conversion, and reference matching.

5. Persistence and database access

- Data access is concentrated in DAO layers:

- eionet.datadict.dal / ...dal.impl for the newer stack.

- eionet.meta.dao.mysql and related interfaces for the legacy stack.

- DAOs use JDBC templates and custom SQL utilities rather than a full ORM.

- Domain objects model metadata concepts such as DataSet, DatasetTable, DataElement, Attribute, FixedValue, Vocabulary, SchemaSet, Namespace, and async task history.

6. Core domain boundaries

- The system’s main entities are:

- datasets and tables,

- data elements and attributes,

- fixed values / vocabularies / concept lists,

- namespaces and RDF namespaces,

- schema sets and schemas,

- site codes and access rules,

- async task execution records.

- Many features are centered on editing, searching, and exporting these metadata objects, not on transactional business data.

7. Import, export, and transformation pipelines

- A major architectural concern is converting DD metadata into many delivery formats:

- RDF, XML instance/schema, JSON, XLS/ODS, PDF, DBF, MDB/MS Access, and code lists.

- Imports handle CSV, RDF, and uploaded archives; decompression and file-bean handling are separated into I/O helper services.

- Exports are organized by format-specific modules under eionet.meta.exports.*, each reading the domain model and rendering a target representation.

- Static templates and seed files under sql/, opendoc/, and msaccess/ support these generation pipelines.

8. Asynchronous jobs and scheduling

- Background work is handled by Quartz-based scheduling plus an async task framework in eionet.datadict.infrastructure.asynctasks.

- Tasks cover things like vocabulary import/check-in/check-out, reference matching, and scheduled sync/maintenance.

- Execution history is persisted, and aspects are used to capture task history automatically.

- This subsystem is a key boundary between synchronous UI actions and long-running metadata operations.

9. Security and access control

- Access is controlled by a combination of ACL files, CAS-based login, LDAP integration, and JWT support for API-style access.

- ACL configuration is file-based in the repository and supplemented by database-backed permission logic.

- The app has explicit security filters and web security config, plus services for generating/verifying JWT tokens and resolving user/group information.

10. External integrations and infrastructure dependencies

- Primary external systems are the relational database, LDAP, CAS, and any downstream notification/event endpoints used by legacy modules.

- The app also depends on file-system storage for documentation/uploads and on Jena-style RDF utilities for semantic exports/imports.

- Deployment is environment-driven via properties files, Tomcat context configuration, and Docker/Jenkins support.

11. Repository structure as an architecture map

- src/main/java holds the runtime application code.

- src/main/resources contains runtime configuration, logging, Quartz, Spring, ACL, and export settings.

- src/main/webapp contains the UI, templates, static assets, and deployment descriptors.

- sql/, doc/, msaccess/, and opendoc/ hold schema seed data, help content, and format templates that directly feed application behavior.

12. How requests typically flow

- A browser or API client enters through Tomcat filters and web security.

- The request is handled by a JSP/ActionBean/Servlet controller.

- Controller code delegates to a service, which enforces rules and coordinates related DAOs.

- DAOs read/write MariaDB/MySQL.

- The response is either a rendered page, a download/export file, or an async task submission whose result is later polled.