Skip to content

Conversation

@ethaaalpha
Copy link
Contributor

@ethaaalpha ethaaalpha commented Oct 20, 2025

This pull request depends on /internal/application pull request.

What's new!?

Exception refactoring

For simplifying the use of exceptions and avoid some useless try/catch/rethrow patterns, we have decided to simplify them.

First of all, we have deleted BusinessException and replaced by VipException it-self. Others child implementation like DAOException, CoreException might be deleted in the future and can be replaced by something new!

Instead of creating child-classes for specific cases with specifics errors codes you can implement your own VipError enum!
Indeed VipException can take an object that implement VipError.

VipError is a new interface that mix up the old VipError and VipErrorMessage classes!
You can now easily implement your own specific errors with an error code associated (see ApiError) in the concerned module.

Since a lot of errors are common, the DefaultError enum provided some of them.

Scheme

A scheme might be the easiest way to understand the new structure!

classDiagram
direction LR
  class VipException {
    + VipError error
  }
  class VipError {
	  + getCode()
	  + getMessage()
  }
  class DefaultError {
	  NOT_FOUND(1000, "item not found")
  }
  class ApiError {
	  APP_NOT_FOUND(8006, "app not found")
  }
	<<Interface>> VipError
	<<Enumeration>> DefaultError
	<<Enumeration>> ApiError
  VipException --* VipError
  VipError --|> DefaultError
  VipError --|> ApiError
	class VipException:::Aqua
	class VipException:::Sky
	class VipError:::Peach
	class DefaultError:::Ash
	class ApiError:::Ash
	classDef Peach :,stroke-width:1px, stroke-dasharray:none, stroke:#FBB35A, fill:#FFEFDB, color:#8F632D
	classDef Aqua :,stroke-width:1px, stroke-dasharray:none, stroke:#46EDC8, fill:#DEFFF8, color:#378E7A
	classDef Sky :,stroke-width:1px, stroke-dasharray:none, stroke:#374D7C, fill:#E2EBFF, color:#374D7C
	classDef Ash :,stroke-width:1px, stroke-dasharray:none, stroke:#999999, fill:#EEEEEE, color:#000000
Loading

Note

You can still use VipException without VipError by using others classical contructors

Others changes

  • ApiException (which became ApiError) is moved back into vip-api module.
  • all /internal/** endpoints use the adapted errors codes

- add new `InternalSecurityConfig` filter chain (defined as order: 2)
- created DELETE/POST/GET methods for /internal/session
- move some models from vip-api to vip-core
- create specific class for `CurrentUserProvider` service
- add a new `SessionAuthenticationProvider` with associated Filter/Token
- refractor `ApikeyAuthenticationProvider` and
  `SessionAuthenticationProvider` into `AbstractAuthenticationProvider`
- POST /internal/session now return Session object as valid response
- rename `SpringApiUser` to `SpringPrincipalUser`
- make COOKIES_SESSION and COOKIES_USER `httpOnly`
-- adapt GWT code to support httpOnly on server implementation
- cookies will set as `secure` only if *apache.sslport* != 80
- edit sign-in.js/home.js endpoints from */rest/session* to */internal/session* for sign-in and retrieving current session instead of cookies (due to **httpOnly**)
- VIPRemoval and VIPCheckRemoval created annotations
- all unsafe methods are concerned under /internal/** except for
  /internal/session (which creates the token)
- refactor `SessionControler` to handle http/cookie related objects
  instead of `SessionBusiness`
- make signIn define SecurityContextHolder
- new method `setAdminContext` to define user context in "simple
  business" calls
- prepare others tests for ApplicationBusiness next update
- CommonBusiness will be used in the backend refactoring
- new CorePermission class to handle basic permissions (role checking..)
- SessionAuthenticationProvider fill user groups in
  SpringSecurityContext
- new `PageBuilder` that can generate `PrecisePage` objects for
  pagination
- update ApplicationBusiness to handle permissions
- add IT related
- new `VIPExternalSafe` annotation to precise method that can safely be
  used inside a controller
- simplification by returning VipException
- cleaned up some old licences headers
- `VipError` is now a simple interface, that each module can inherit to
  define speficic messages (with codes)
- Existing implemention of old `VipError` are renamed
- `DefaultError` have the common "errors" that can be used by
  internal/public api
- `VipException` should be the only one exception object and can take a `VipError` as
  parameter (all the cleaning is not done yet, like `DAOException`..)
@ethaaalpha ethaaalpha changed the title refactoring of exception classes refactoring of exceptions classes Nov 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant