Русский
Русский
English
Статистика
Реклама

Spring

Семилетними шагами миграция с JSP Angular JS на Angular 2

26.03.2021 10:08:08 | Автор: admin

Что нужно для перехода от серверного рендеринга к пользовательскому? Чем хорош Angular 2+ и как на него перейти? В этой статье попытаемся разобраться в данных вопросах и описать процесс миграции от серверных технологий рендеринга, таких, как JSP, к клиентским технологиям рендеринга представлений с использованием Angular.

Используемые технологии

Прежде чем приступить к коду, опишем весь стек используемых технологий:

  • Spring Framework - фреймворк для Java-платформы.

  • JSP - технология, позволяющая создавать содержимое, которое имеет как статические, так и динамические компоненты. Страница JSP содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов (например, HTML) и JSP-элементы. Эти элементы конструируют динамическое содержимое, позволяя внедрять Java-код в статичное содержимое страницы.

  • AngularJS и Angular - JavaScript-фреймворки от компании Google для создания клиентских приложений. AngularJS был одним из первых JavaScript-фреймворков, разработанным для создания одностраничных приложений (SPA). Он был выпущен в 2009 году как фреймворк с открытым исходным кодом. В 2016 году был выпущен Angular 2. Он был переписан с нуля на TypeScript и не является обратно совместимым с AngularJS.

Изначально у нас есть приложение, написанное на Spring+JSP с использованием AngularJS.Наша цель - перейти к SPA с использованием современной версии Angular.

Какие перспективы?

Angular является современным и популярным фреймворком и обладает рядом преимуществ по сравнению с JSP и AngularJS.

Основное концептуальное различие между JSP и Angular заключается в том, динамически ли генерируется страница в браузере (на стороне клиента) или на сервере. При использовании Angular не приходится извлекать всю страницу с сервера после ее загрузки в первый раз. Вы просто обновляете части страницы, которые изменились на клиенте (хотя это часто происходит в ответ на данные, полученные с сервера). Рендеринг на стороне клиента позволяет избежать ненужных запросов на полную страницу, когда изменилась только ее часть.

Внедряем технологию

Перейдем непосредственно к описанию процесса перехода и рассмотрим вопросы, возникающие при смене технологий.

Инициализация нового Angular приложения

Вместо JSP-страниц нам теперь понадобится Angular приложение. Для его создания удобно использовать Angular CLI. Angular CLI - официальный инструмент для инициализации и работы с Angular-проектами. Он упрощает создание приложения, его компиляцию.

Angular CLI можно установить, выполнив следующую команду:

npm install @angular/cli

После создадим новый Angular проект с помощью команды:

ng new <название проекта>

Команда ng new генерирует скелет будущего приложения. Angular CLI создает одноименную директорию и помещает в нее исходные файлы "скелета" приложения.

Создание служебных сервисов

На JSP-страницах использовалась информация, содержащая Java-выражения, а также специфичные теги: http://www.springframework.org/tags, в частности, для локализации и http://java.sun.com/jsp/jstl/core. Также в некоторых ситуациях может существовать необходимость в кастомизируемом ролевом доступе, информацией о котором, помимо сервера, должен владеть и клиент. Для получения этой информации создадим дополнительные контроллеры с методами, возвращающими нужную информацию. Запросы, возвращающие сообщения для локализации, должны быть доступны без аутентификации. Это связано с тем, что эти сообщения отображаются на всех страницах, включая доступные неавторизованным пользователям. Поправим конфигурацию Spring Security, чтобы она игнорировала запросы по шаблону "/messages/*":

@Overridepublic void configure(WebSecurity web) {    web.ignoring().antMatchers("/messages/*");}

Для того, чтобы использовать эти данные, на фронтенде должны быть заранее известны коды сообщений и названия привилегий. Совпадение информации на фронтенде и бэкенде приходится отслеживать вручную.

Проксирование

В случае, когда клиент хостится на отдельном сервере, возникает потребность в проксировании запросов. Тот факт, что фронтенд и бэкенд прослушивают отдельные порты, не позволяет Angular делать внутренние запросы. Это связано с тем, что веб-браузеры разрешают только внутренние запросы к тому же источнику, из которого было загружено веб-приложение. К счастью, мы можем позволить Angular CLI выступать в качестве прокси-сервера для нашего бэкенда Spring. Приложение Angular будет отправлять бэкенд-запросы на сервер разработки, который будет пересылать их на бэкенд.

Для этого добавим в корневую папку проекта файл proxy.conf.json с конфигурацией прокси-сервера:

{  "/api": {    "target": "http://localhost:8099",    "secure": false,    "cookieDomainRewrite": "localhost",    "changeOrigin": true  }}

Также поправим package.json, чтобы данная конфигурация применялась, указав в стартовом скрипте "start": "ng serve --proxy-config proxy.conf.json".

Перенос JSP страниц в компоненты Angular

Angular приложение состоит из компонентов, у каждого из которых своя независимая логика. Компонент - полноценная сущность, у которой есть своя логика TypeScript, разметка HTML и свой стиль CSS. Соответственно каждая JSP-страница будет разбиваться на отдельные компоненты, в которых в отдельные файлы выносится html, typescript и css. Для отправки запросов к бэкенду создадим отдельные сервисы. Заменим конструкции AngularJS на аналогичные в Angular.

В каждом компоненте, в методе ngOnInit пропишем получение необходимых сообщений для локализации, а также добавим проверку наличия необходимых для данного компонента привилегий.

При открытии JSP-страницы выполняется проверка на наличие привилегий. В случае отсутствия привилегий пользователь перенаправляется на страницу входа.

<%   if (!SecurityUtils.hasRole(SecurityConstants.VIEW_USER)) {       response.sendRedirect("login.jsp");   }%>

В Angular есть механизм ограничения перехода, называемый Guards. Guards позволяют ограничить доступ к маршрутам на основе определенного условия.

Все guard-ы должны возвращать либо true, либо false. И происходить это может как в синхронном режиме (тип Boolean), так и в асинхронном режиме (Observable<boolean> или Promise<boolean>). Данный пример разрешает переход при наличии у пользователя привилегии VIEW_SETTINGS. Метод hasPrivilege отправляет запрос на сервис и возвращает Observable<boolean>.

@Injectable({ providedIn: 'root'})export class SettingsGuard { readonly  SECURITY_CONSTANTS = SecurityConstants; constructor(private router: Router,             private securityConstantService: SecurityConstantService) { } canActivate(next: ActivatedRouteSnapshot, state: RouterStateSnapshot):   Observable<boolean|UrlTree> | Promise<boolean|UrlTree> | boolean|UrlTree {   return this.securityConstantService.hasPrivilege(this.SECURITY_CONSTANTS.VIEW_SETTINGS); }}

Обработка ошибок

Следующий шаг - обработка ошибок, возвращаемых сервером. Добавим HttpInterceptor, который обеспечивает перехват http-запросов и ответов для преобразования или обработки их перед передачей. При получении ошибок 401 или 403 будем перенаправлять пользователя на страницу входа:

public handleError(err: HttpErrorResponse): Observable<any> {  if (err.url != null && (err.status === 401 || err.status === 403)) {    this.router.navigate(['/login']);  }  return throwError(err.error);}

Подобным образом можно обрабатывать другие ошибки, подробнее можно почитать, например, здесь.

Кэширование

Сообщения для локализации интерфейса, а также ряд других констант не меняется во время использования приложения, поэтому нет смысла каждый раз запрашивать их с сервера. Для реализации кэширования добавим RequestCache и CachingInterceptor.

RequestCache - сервис, который содержит методы, позволяющие добавлять информацию в кэш и извлекать ее из него. Вариантом реализации может послужить хранение данных в виде пар "ключ/значение", где ключом является название сообщения.

cache = new Map<string, RequestCacheEntry>();get(req: HttpRequest<any>): HttpResponse<any> | undefined {   const url = req.url + req.body.key;   const cached = this.cache.get(url);   if (!cached) {     return undefined;   }   const isExpired = cached.lastRead < (Date.now() - maxAge);   return isExpired ? undefined : cached.response; }put(req: HttpRequest<any>, response: HttpResponse<any>): void {   const url = req.url + req.body.key;   const newEntry = { url, response, lastRead: Date.now() };   this.cache.set(url, newEntry);   const expired = Date.now() - maxAge;   this.cache.forEach(entry => {     if (entry.lastRead < expired) {       this.cache.delete(entry.url);     }   }); }

CachingInterceptor реализует интерфейс HttpInterceptor, перехватывает запросы и решает, нужно их кэшировать или нет. Любой класс, реализующий интерфейс HttpInterceptor, должен иметь метод intercept.

В этом методе мы сначала проверим, нужно ли кэшировать данные из запроса (метод isCacheable), и, если нужно, попробуем извлечь данные из нашего кэша. Если у нас есть кэшированные данные для конкретного запроса, то мы вернем Observable с этими данными. Иначе мы отправим запрос на сервер для извлечения данных, в нашем случае, используя метод sendRequest. Этот метод также кэширует запрос для дальнейшего использования.

intercept(req: HttpRequest<any>, next: HttpHandler) { if (!isCacheable(req)) { return next.handle(req); } const cachedResponse = this.cache.get(req); if (req.headers.get('x-refresh')) {   const results$ = sendRequest(req, next, this.cache);   return cachedResponse ?     results$.pipe( startWith(cachedResponse) ) :     results$; } return cachedResponse ?   of(cachedResponse) : sendRequest(req, next, this.cache);}

Заключение

Итак, описанные действия приблизили нас к получению современного Angular приложения, совместимого с нашим бэкендом. Остальное было делом техники. Популярные фреймворки предоставляют широкий спектр возможностей и огромное комьюнити с поддержкой. Уход от устаревших технологий необходим для полноценного развития приложения, даже если переход может вызвать сложности. Надеюсь, эта статья поможет вам продвинуться в нужном для вас направлении.

Подробнее..

Реактивный масштабируемый чат на Kotlin Spring WebSockets

13.04.2021 18:11:50 | Автор: admin

Содержание

  1. Конфигурация проекта

    1. Логгер

    2. Домен

    3. Маппер

  2. Настройка Spring Security

  3. Конфигурация веб-сокетов

  4. Архитектура решения

  5. Реализация

    1. Интеграция с Redis

    2. Импелементация сервиса

  6. Заключение

Предисловие

В данном туториале будет рассмотрено создание масштабируемого приложения, подключение и общение с котором происходит по веб-сокетам. Рассмотрим и мужественно преодолеем проблему передачи сообщений между инстансами с помощью месседж брокера. В качестве месседж брокера будет использован Redis.

Конфигурация проекта

Начнём с самого важного, конфигурации логгера!

Конфигурация логгера состоит из того, что нам нужно создать prototype bean, который будет конфигурировать логгер для класса, в которой этот бин инжектится.

@Configurationclass LoggingConfig {    @Bean    @Scope("prototype")    fun logger(injectionPoint: InjectionPoint): Logger {        return LoggerFactory.getLogger(                injectionPoint.methodParameter?.containingClass                        ?: injectionPoint.field?.declaringClass        )    }}

Теперь, чтобы получить сконфигурированный логгер, нам достаточно внедрить его.

@Componentclass ChatWebSocketHandlerService(    private val logger: Logger) 

Далее создадим доменку и сконфигурируем маппер для неё

Класс чата содержит базовую информацию, включая участников чата.

data class Chat(    val chatId: UUID,    val chatMembers: List<ChatMember>,    @JsonSerialize(using = LocalDateTimeSerializer::class)    @JsonDeserialize(using = LocalDateTimeDeserializer::class)    val createdDate: LocalDateTime,    var lastMessage: CommonMessage?)

Класс ChatMember описывает участника чата. Из интересного тут - это флаг deletedChat. Его назначение - убрать чат из выборки списка чатов для пользователя с userId.

data class ChatMember(        val userId: UUID,        var fullName: String,        var avatar: String,        var deletedChat: Boolean)

Ниже представлен базовый класс для всех сообщений в чате. Аннотация @JsonTypeInfo тут нужна для того, чтобы классам-наследникам при заворачивании в JSON проставлялось поле @type с указанием типа сообщения, а при разворачивании были проставлены поля базового класса.

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY)open class CommonMessage(    val messageId: UUID,    val chatId: UUID,    val sender: ChatMember,    @field:JsonSerialize(using = LocalDateTimeSerializer::class) @field:JsonDeserialize(using = LocalDateTimeDeserializer::class)    val messageDate: LocalDateTime,    var seen: Boolean)

Пример конкретного класса сообщения TextMessage - текстового сообщения

class TextMessage(    messageId: UUID,    chatId: UUID,    sender: ChatMember,    var content: String,    messageDate: LocalDateTime,    seen: Boolean) : CommonMessage(messageId, chatId, sender, messageDate, messageType, seen)

Сконфигурируем ObjectMapper

В registerSubtypes добавляются классы-наследники, которые будут сериализоваться и десериализоваться в JSON. Это необходимо для того, чтобы после десериализации определить тип конкретный тип и передать на обработку в нужный метод

@Configurationclass ObjectMapperConfig {    @Bean    fun objectMapper(): ObjectMapper = ObjectMapper()        .registerModule(JavaTimeModule())        .registerModule(Jdk8Module())        .registerModule(ParameterNamesModule())        .registerModule(KotlinModule())        .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)        .apply {            registerSubtypes(                NamedType(NewMessageEvent::class.java, "NewMessageEvent"),                NamedType(MarkMessageAsRead::class.java, "MarkMessageAsRead"),                NamedType(TextMessage::class.java, "TextMessage"),                NamedType(ImageMessage::class.java, "ImageMessage")            )        }}

Конфигурация Spring Security

Для начала нам понадобится ReactiveAuthenticationManager и SecurityContextRepository. Для аутентификации будем использовать JWT, поэтому создаем класс JwtAuthenticationManager со следующим содержанием:

@Componentclass JwtAuthenticationManager(val jwtUtil: JwtUtil) : ReactiveAuthenticationManager {    override fun authenticate(authentication: Authentication): Mono<Authentication> {        val token = authentication.credentials.toString()        val validateToken = jwtUtil.validateToken(token)        var username: String?        try {            username = jwtUtil.extractUsername(token)        } catch (e: Exception) {            username = null            println(e)        }        return if (username != null && validateToken) {            val claims = jwtUtil.getClaimsFromToken(token)            val role: List<String> = claims["roles"] as List<String>            val authorities = role.stream()                    .map { role: String? -> SimpleGrantedAuthority(role) }                    .collect(Collectors.toList())            val authenticationToken = UsernamePasswordAuthenticationToken(                    username,                    null,                    authorities            )            authenticationToken.details = claims            Mono.just(authenticationToken)        } else {            Mono.empty()        }    }}

Чтобы везде, где необходимо, иметь возможность извлечь информацию из seucirty context, заносим claims в details токена (строка 25).

Для извлечения токена из запроса создаем класс SecurityContextRepository. Извлекать токен будем двумя способами:

  1. Заголовок Authorization: Bearer ${JWT_TOKEN}

  2. GET параметр ?access_token=${JWT_TOKEN}

@Componentclass SecurityContextRepository(val authenticationManager: ReactiveAuthenticationManager) : ServerSecurityContextRepository {    override fun save(exchange: ServerWebExchange, context: SecurityContext): Mono<Void> {        return Mono.error { IllegalStateException("Save method not supported") }    }    override fun load(exchange: ServerWebExchange): Mono<SecurityContext> {        val authHeader = exchange.request            .headers            .getFirst(HttpHeaders.AUTHORIZATION)        val accessToken: String = if (authHeader != null && authHeader.startsWith("Bearer ")) {            authHeader.substring(7)        } else exchange.request            .queryParams            .getFirst("access_token") ?: return Mono.empty()        val auth = UsernamePasswordAuthenticationToken(accessToken, accessToken)        return authenticationManager            .authenticate(auth)            .map { authentication: Authentication -> SecurityContextImpl(authentication) }    }}

Теперь имея два необходимых класса мы можем сконфигурировать сам Spring Security.

@EnableWebFluxSecurity@EnableReactiveMethodSecurityclass SecurityConfig(    val reactiveAuthenticationManager: ReactiveAuthenticationManager,    val securityContextRepository: SecurityContextRepository) {    @Bean    fun securityWebFilterChain(httpSecurity: ServerHttpSecurity): SecurityWebFilterChain {        return httpSecurity            .exceptionHandling()            .authenticationEntryPoint { swe: ServerWebExchange, e: AuthenticationException ->                Mono.fromRunnable { swe.response.statusCode = HttpStatus.UNAUTHORIZED }            }            .accessDeniedHandler { swe: ServerWebExchange, e: AccessDeniedException ->                Mono.fromRunnable { swe.response.statusCode = HttpStatus.FORBIDDEN }            }            .and()            .csrf().disable()            .cors().disable()            .formLogin().disable()            .httpBasic().disable()            .authenticationManager(reactiveAuthenticationManager)            .securityContextRepository(securityContextRepository)            .authorizeExchange()            .pathMatchers("/actuator/**").permitAll()            .pathMatchers(HttpMethod.GET, "/ws/**").hasAuthority("ROLE_USER")            .anyExchange().authenticated()            .and()            .build()    }}

Здесь из интересного: конфигурация позволяет подключиться по путям начинающимся с /ws только аутентифицированным пользователям, у которых есть роль ROLE_USER.

С конфигурацией Security закончили, теперь необходимо сконфигурировать подключение по сокетам.

Конфигурация веб-сокетов

В первую очередь нам необходимо задать маппинг между запросом и обработчиком. Чтобы добавить обработчик сокетов по определенному адресу, мы делаем следующее:

  1. Создаем мапу, где ключ - uri, а значение - обработчик. В этом конкретном случае WebSocketHandler.

  2. Создаем обработчик для ранее определенного маппинга и cors.

@Configurationclass ReactiveWebSocketConfig {    @Bean    fun webSocketHandlerMapping(chatWebSocketHandler: ChatWebSocketHandler): HandlerMapping {        val map: MutableMap<String, WebSocketHandler> = HashMap()        map["/ws/chat"] = chatWebSocketHandler        val handlerMapping = SimpleUrlHandlerMapping()        handlerMapping.setCorsConfigurations(Collections.singletonMap("*", CorsConfiguration().applyPermitDefaultValues()))        handlerMapping.order = 1        handlerMapping.urlMap = map        return handlerMapping    }    @Bean    fun handlerAdapter(): WebSocketHandlerAdapter {        return WebSocketHandlerAdapter()    }}

Здесь в качестве обработчика для uri /ws/chat указываем chatWebSocketHandler, его вид представлен ниже, имплементацией займемся позднее. Этот класс реализует интерфейс WebSocketHandler, содержащий один метод handle(session: WebSocketSession): Mono<Void>

@Componentclass ChatWebSocketHandler : WebSocketHandler {    override fun handle(session: WebSocketSession): Mono<Void> {        TODO("Not yet implemented")    }}

С базовой конфигурацией закончили.

Поговорим об архитектуре решения

На данным момент наш чат нельзя масштабировать. Так как подключение по веб-сокету дуплексное и, установив соединение с одним инстансом, все запросы по этому сокету будут направляться на этот инстанс, так при запуске двух и более инстансов у нас не будет доступа до всех имеющихся сессий. Становится возможной ситуация, когда собеседники из одного чата подключены к разным инстансам и нет возможности сразу отправить сообщение по сокетам всем участникам. Для решения необходим Message Broker, который будет получать на вход сообщение для определенного чата и рассылать его на все инстансы. Инстансы посмотрят на сообщение, возьмут информацию об участниках чата из БД, и будут искать этих участников среди своих подключенных пользователей.

Представим, что участники одного чата User 1 и User 2 подключены к разным инстансам чата. User 1 подключен к Chat-Instance-0, а User 2 к Chat-Instance-1. Тогда, когда User 1 отправит сообщение в Chat-Instance-0 (зеленая пунктирная линия), это сообщение попадёт в чат и будет отправлено в Message broker, оттуда разослано по всем инстансам. Chat-Instance-1 получит это сообщение и увидит, что у него есть User 2, который относится к этому чату и ему необходимо отправить это сообщение.

Реализация

Теперь займемся имплементацией нашего обработчика ChatWebSocketHandler

Нам понадобится мапа userId => session, для того, чтобы хранить открытые сессии и иметь возможность достать их по userId. Для поддержки одновременной работы с несколькими сессиями из под одного userId интерфейс мапы будет следующим: MutableMap<UUID, LinkedList<WebSocketSession>>.

Добавлять в мапу запись мы будем при подписке на стрим session.receive, а подчищать будем в doFinally.

В методе getReceiverStream создается стрим-обработчик сообщений, пришедших от клиента. Мы получаем payload как строку и преобразуем его к базовому WebSocketEvent, после чего в зависимости от типа event'a передаем его на обработку в слой сервисов.

В методе getSenderStream происходит конфигурация стрима, который занимается отправкой сообщений по сокету клиенту

@Componentclass ChatWebSocketHandler(    val objectMapper: ObjectMapper,    val logger: Logger,    val chatService: ChatService,    val objectStringConverter: ObjectStringConverter,    val sinkWrapper: SinkWrapper) : WebSocketHandler {    private val userIdToSession: MutableMap<UUID, LinkedList<WebSocketSession>> = ConcurrentHashMap()    override fun handle(session: WebSocketSession): Mono<Void> {        return ReactiveSecurityContextHolder.getContext()            .flatMap { ctx ->                val userId = UUID.fromString((ctx.authentication.details as Claims)["id"].toString())                val sender = getSenderStream(session, userId)                val receiver = getReceiverStream(session, userId)                return@flatMap Mono.zip(sender, receiver).then()            }    }    private fun getReceiverStream(session: WebSocketSession, userId: UUID): Mono<Void> {        return session.receive()            .filter { it.type == WebSocketMessage.Type.TEXT }            .map(WebSocketMessage::getPayloadAsText)            .flatMap {                objectStringConverter.stringToObject(it, WebSocketEvent::class.java)            }            .flatMap { convertedEvent ->                when (convertedEvent) {                    is NewMessageEvent -> chatService.handleNewMessageEvent(userId, convertedEvent)                    is MarkMessageAsRead -> chatService.markPreviousMessagesAsRead(convertedEvent.messageId)                    else -> Mono.error(RuntimeException())                }            }            .onErrorContinue { t, _ -> logger.error("Error occurred with receiver stream", t) }            .doOnSubscribe {                val userSession = userIdToSession[userId]                if (userSession == null) {                    val newUserSessions = LinkedList<WebSocketSession>()                    userIdToSession[userId] = newUserSessions                }                userIdToSession[userId]?.add(session)            }            .doFinally {                val userSessions = userIdToSession[userId]                userSessions?.remove(session)            }            .then()    }    private fun getSenderStream(session: WebSocketSession, userId: UUID): Mono<Void> {        val sendMessage = sinkWrapper.sinks.asFlux()            .filter { sendTo -> sendTo.userId == userId }            .map { sendTo -> objectMapper.writeValueAsString(sendTo.event) }            .map { stringObject -> session.textMessage(stringObject) }            .doOnError { logger.error("", it) }        return session.send(sendMessage)    }}

Для того чтобы писать в websocket нам необходимо создать поток данных, в который мы сможем добавлять данные. С reactora 3.4 для этого рекомендуется использовать Sinks.Many. Создадим такой поток в классе SinkWrapper.

@Componentclass SinkWrapper {    val sinks: Sinks.Many<SendTo> = Sinks.many().multicast().onBackpressureBuffer()}

Теперь, отправив данные в этот поток, они будут обработаны в потоке, сформированном в getSenderStream.

Интеграция с Redis

У Redis есть PUB/SUB модель общения, которая прекрасно решает задачу транслирования сообщений между инстансами.

Итак, для приготовления данного блюда нам понадобится:

  1. RedisChatMessageListener - подписка на топики и перенаправление сообщение в слой сервисов

  2. RedisChatMessagePublisher - публикация сообщений в топики

  3. RedisConfig - конфигурация редиса

  4. RedisListenerStarter - старт листенеров при старте инстанса

Реализация:

RedisConfig стандартный, ничего особенного

@Configurationclass RedisConfig {    @Bean    fun reactiveRedisConnectionFactory(redisProperties: RedisProperties): ReactiveRedisConnectionFactory {        val redisStandaloneConfiguration = RedisStandaloneConfiguration(redisProperties.host, redisProperties.port)        redisStandaloneConfiguration.setPassword(redisProperties.password)        return LettuceConnectionFactory(redisStandaloneConfiguration)    }    @Bean    fun template(reactiveRedisConnectionFactory: ReactiveRedisConnectionFactory): ReactiveStringRedisTemplate {        return ReactiveStringRedisTemplate(reactiveRedisConnectionFactory)    }}

RedisChatMessageListener

Здесь мы создаем подписку на топик по имени базового класса (обычно название топиков выносят в проперти). Получив сообщение из канала преобразуем его в объект (строка 13) и дальше передаем в sendMessage, который достанет участников чата и попробует разослать им это сообщение, если таковы имеются среди подключенных к инстансу.

@Componentclass RedisChatMessageListener(    private val logger: Logger,    private val reactiveStringRedisTemplate: ReactiveStringRedisTemplate,    private val objectStringConverter: ObjectStringConverter,    private val chatService: ChatService) {    fun subscribeOnCommonMessageTopic(): Mono<Void> {        return reactiveStringRedisTemplate.listenTo(PatternTopic(CommonMessage::class.java.name))            .map { message -> message.message }            .doOnNext { logger.info("Receive new message: $it") }            .flatMap { objectStringConverter.stringToObject(it, CommonMessage::class.java) }            .flatMap { message ->                when (message) {                    is TextMessage -> chatService.sendMessage(message)                    is ImageMessage -> chatService.sendMessage(message)                    else -> Mono.error(RuntimeException())                }            }            .then()    }}

RedisChatMessagePublisher

Паблишер имеет один метод для транслирования CommonMessage на все инстансы. Объект сообщения приводится к строке и публикуется в топик по имени базового класса.

@Componentclass RedisChatMessagePublisher(    val logger: Logger,    val reactiveStringRedisTemplate: ReactiveStringRedisTemplate,    val objectStringConverter: ObjectStringConverter) {    fun broadcastMessage(commonMessage: CommonMessage): Mono<Void> {        return objectStringConverter.objectToString(commonMessage)            .flatMap {                logger.info("Broadcast message $it to channel ${CommonMessage::class.java.name}")                reactiveStringRedisTemplate.convertAndSend(CommonMessage::class.java.name, it)            }            .then()    }}

RedisListenerStarter

В этом классе стартуются все листенеры из RedisChatMessageListener. В нашем случае - единственный листенер subscribeOnCommonMessageTopic

@Componentclass RedisListenerStarter(    val logger: Logger,    val redisChatMessageListener: RedisChatMessageListener) {    @Bean    fun newMessageEventChannelListenerStarter(): ApplicationRunner {        return ApplicationRunner { args: ApplicationArguments ->            redisChatMessageListener.subscribeOnCommonMessageTopic()                .doOnSubscribe { logger.info("Start NewMessageEvent channel listener") }                .onErrorContinue { throwable, _ -> logger.error("Error occurred while listening NewMessageEvent channel", throwable) }                .subscribe()        }    }}

Импелементация сервиса

Упрощенная реализация, без сохранения сообщений в БД с замоканным chatRepository. В виду того, что статья выходит и так больше, чем я рассчитывал.

Метод handleNewMessageEvent вызывается из WebSocketHandler и получает на вход userId отправителя и NewMessageEvent - простое текстовое сообщение. В методе происходит проверка на то, что отправитель действительно является участником чата и дальше это сообщение транслируется между инстансами.

@Serviceclass DefaultChatService(    val logger: Logger,    val sinkWrapper: SinkWrapper,    val chatRepository: ChatRepository,    val redisChatPublisher: RedisChatMessagePublisher) : ChatService {    override fun handleNewMessageEvent(senderId: UUID, newMessageEvent: NewMessageEvent): Mono<Void> {        logger.info("Receive NewMessageEvent from $senderId: $newMessageEvent")        return chatRepository.findById(newMessageEvent.chatId)            .filter { it.chatMembers.map(ChatMember::userId).contains(senderId) }            .flatMap { chat ->                val textMessage = TextMessage(UUID.randomUUID(), chat.chatId, chat.chatMembers.first { it.userId == senderId }, newMessageEvent.content, LocalDateTime.now(), false)                chat.lastMessage = textMessage                return@flatMap Mono.zip(chatRepository.save(chat), Mono.just(textMessage))            }            .flatMap { broadcastMessage(it.t2) }    }    /**     * Broadcast the message between instances     */    override fun broadcastMessage(commonMessage: CommonMessage): Mono<Void> {        return redisChatPublisher.broadcastMessage(commonMessage)    }    /**     * Send the message to all of chatMembers of message chat direct     */    override fun sendMessage(message: CommonMessage): Mono<Void> {        return chatRepository.findById(message.chatId)            .map { it.chatMembers }            .flatMapMany { Flux.fromIterable(it) }            .flatMap { member -> sendEventToUserId(member.userId, ChatMessageEvent(message.chatId, message)) }            .then()    }    override fun sendEventToUserId(userId: UUID, webSocketEvent: WebSocketEvent): Mono<Void> {        return Mono.fromCallable { sinkWrapper.sinks.emitNext(SendTo(userId, webSocketEvent), Sinks.EmitFailureHandler.FAIL_FAST) }            .then()    }}

Заключение

В качестве дальнейших доработок можно произвести разделение получаемых и отправляемых ивентов на отдельные классы. Также в месте, где происходит получение сообщения по сокетам от клиента, его приведение к WebSocketEvent и передача в обработчик, можно попробовать избавиться от хардкодного маппинка event => handler. Пока не думал, как это можно сделать красивее, но уверен, что решение есть.

Проект на GitHub

Подробнее..
Категории: Kotlin , Redis , Java , Chat , Spring , Microservice

Создаем plugin для IDEA для мониторинга транзакций в Spring

20.04.2021 10:21:38 | Автор: admin

Disclaimer: я не являюсь сотрудником JetBrains (а жаль), поэтому код может являться не оптимальным и служит только для примера и исследовательских целей.

Введение

Часто во время работы со Spring непонятно, правильно ли работает аннотация @Transaction:

  • в правильном ли месте мы ее поставили

  • правильно ли объявился interceptor

  • и т.д.

Самым простым способом для меня было остановиться в debug в IDEA в необходимом методе и исследовать, что возвращает

TransactionSynchronizationManager.isActualTransactionActive();

Но "я же программист" и захотелось это дело хоть как-то автоматизировать, заодно поизучать возможности написания plugin для IDEA.

Хочется иметь семафор, который визуально показывает, активна ли транзакция или нет, а также иметь возможность сделать срез основных свойств для анализа в будущем.

Примерно вот что получилось:

Подробней про транзакции можно прочитать здесь.

С чего начать создания plugin?

Про настройку проекта для создание plugin можно прочитать здесь.

Повторюсь, что главными отправными точками будут:

Реализация

Исходный код получившегося решения размещен здесь.

Создание action

Прочитать про action можно здесь. Под action, в основном, понимается кнопка или элемент меню.

Сначала определим новый action. У action есть два метода update и actionPerformed.

  • update - вызывается idea несколько раз в секунду для того, чтобы установить корректное состояние (включен/не включен, виден/не виден)

  • actionPerformed - вызывается idea при выполнении действия (нажатия на кнопку).

public class PopupDialogAction extends AnAction {  @Override  public void update(AnActionEvent e) {    // Using the event, evaluate the context, and enable or disable the action.  }  @Override  public void actionPerformed(@NotNull AnActionEvent e) {    // Using the event, implement an action. For example, create and show a dialog.  }}

Для того, чтобы зарегистрировать новый action, требуется прописать в plugin.xml:

<actions>  <action id="TransactionStatusAction"          class="com.github.pyltsin.sniffer.debugger.TransactionStatusAction"          icon="SnifferIcons.RUNNING"          text="Current Transaction Status">    <add-to-group group-id="XDebugger.ToolWindow.TopToolbar" anchor="last"/>  </action></actions>

После этого должна была появиться новая кнопка на панели инструментов в debug-окне

Вычисление значений в debug

IDEA позволяет нам вычислять выражения при debug и взаимодействовать с памятью

И не только

Информация взята из twitter Тагира Валеева

В Evaluate даже встроен свой мини-интерпретатор Java, который позволяет выполнять прикольные вещи, например, такие:

Картинка из поста Тагира Валеева (http://personeltest.ru/aways/twitter.com/tagir_valeev/status/1360512527218728962)Картинка из поста Тагира Валеева (http://personeltest.ru/aways/twitter.com/tagir_valeev/status/1360512527218728962)

Поэтому, используя API IDEA, мы легко сможем узнать, когда транзакция активна, выполнив:

const val TRANSACTION_ACTIVE: String =    "org.springframework.transaction.support.TransactionSynchronizationManager"+  ".actualTransactionActive.get()==Boolean.TRUE"

Для начала сделаем так, чтобы наше действие было недоступно, если мы не находимся в режиме debug. Для этого получим XDebugSession и сравним с null

override fun update(e: AnActionEvent) {  val presentation = e.presentation  val currentSession: XDebugSession? = getCurrentSession(e)  if (currentSession == null) {    setDisabled(presentation)    return  }}private fun getCurrentSession(e: AnActionEvent): XDebugSession? {  val project = e.project  return if (project == null) null else   XDebuggerManager.getInstance(project).currentSession}

Многие вещи в idea реализованы через статические методы и паттерн singleton (хотя это уже почти считается антипаттерном - это очень удобно, что мы можем получить требуемые значения из любого места через статические методы, например, XDebuggerManager.getInstance)

Евгений Борисов не одобряет singleton как pattern, когда есть SpringЕвгений Борисов не одобряет singleton как pattern, когда есть Spring

Теперь мы хотим получить значения из контекста Spring из текущей сессии Java. Для этого можно воспользоваться следующим методом:

public abstract class XDebuggerEvaluator {  public abstract void evaluate(@NotNull String expression,                                 @NotNull XEvaluationCallback callback,                                 @Nullable XSourcePosition expressionPosition);}

Например, так

val currentSourcePosition: XSourcePosition? = currentSession.currentStackFrame?.sourcePositioncurrentSession.debugProcess.evaluator?.evaluate(  TRANSACTION_ACTIVE, object : XDebuggerEvaluator.XEvaluationCallback {    override fun errorOccurred(errorMessage: String) {      TODO("Not yet implemented")    }    override fun evaluated(result: XValue) {      TODO("Not yet implemented")    }  },  currentSourcePosition)

В XValue теперь хранится вычисленное значение. Чтобы посмотреть его, можно выполнить:

(result as JavaValue).descriptor.value

Он возвращает объект класса - com.sun.jdi.Value

Часть JavaDoc для com.sun.jdi.Value

The mirror for a value in the target VM. This interface is the root of a value hierarchy encompassing primitive values and object values.

Мы научились вычислять значения в debug с использованием API IDEA.

Рабочая панель (Tool Window)

Теперь попробуем их вывести в рабочую панель (Tool Window). Как всегда начинаем с документации и примера.

Объявляем в plugin.xml новое окно

<toolWindow id="TransactionView" secondary="true" icon="AllIcons.General.Modified" anchor="right"factoryClass="com.github.pyltsin.sniffer.ui.MyToolWindowFactory"/>
public class MyToolWindowFactory implements ToolWindowFactory {  public void createToolWindowContent(@NotNull Project project, @NotNull ToolWindow toolWindow) {    MyToolWindow myToolWindow = new MyToolWindow(toolWindow, project);    ContentFactory contentFactory = ContentFactory.SERVICE.getInstance();    Content content = contentFactory.createContent(myToolWindow.getContent(), "", false);    final ContentManager contentManager = toolWindow.getContentManager();    contentManager.addContent(content);  }}

Само окно можно нарисовать во встроенном редакторе

IDEA сама сгенерирует для нас заготовку класса:

А дальше, вспоминая старый добрый Swing, описываем логику и добавляем необходимые Listener.

Получившееся окно инструментов (Tool Windows)Получившееся окно инструментов (Tool Windows)

Способы передачи данных

Вернемся к нашему action. При нажатии на кнопку вызывается метод actionPerformed.

Как из этого метода достучаться до нашего окна?

Самый простой способ - снова воспользоваться статическим методом:

val toolWindow: ToolWindow? =ToolWindowManager.getInstance(project).getToolWindow("TransactionView")

И передать туда требуемые значения.

IDEA предоставляет еще один способ - Message Bus (детальное описание лучше смотреть в документации). Один из вариантов использования следующий:

Объявить интерфейс:

public interface ChangeActionNotifier {    Topic<ChangeActionNotifier> CHANGE_ACTION_TOPIC = Topic.create("custom name", ChangeActionNotifier.class)    void beforeAction(Context context);    void afterAction(Context context);}

В месте, где принимаем сообщения:

bus.connect().subscribe(ActionTopics.CHANGE_ACTION_TOPIC, new ChangeActionNotifier() {        @Override        public void beforeAction(Context context) {            // Process 'before action' event.        }        @Override        public void afterAction(Context context) {            // Process 'after action' event.        }});

В месте, где отправляем сообщения:

ChangeActionNotifier publisher = myBus.syncPublisher(  ActionTopics.CHANGE_ACTION_TOPIC);publisher.beforeAction(context);

В любом случае необходимо быть аккуратным с многопоточностью и не выполнять долгие операции на UI Thread (подробности).

Осталось собрать все вместе и протестировать.

Исходный код получившегося решения размещен здесь.

Краткий "как бы" вывод

IDEA очень гибкий и удобный инструмент для разработки, который можно быстро расширить требуемыми функциями. IDEA содержит массу интересного внутри себя, тем более ее код доступен всем.

Ссылки

Подробнее..

Тривиальная и неправильная облачная компиляция

28.01.2021 00:21:03 | Автор: admin


Введение


Данная статья не история успеха, а скорее руководство как не надо делать. Весной 2020 для поддержания спортивного тонуса участвовал в студенческом хакатоне (спойлер: заняли 2-е место). Удивительно, но задача из полуфинала оказалась более интересной и сложной чем финальная. Как вы поняли, о ней и своём решении расскажу под катом.


Задача


Данный кейс был предложен Deutsche Bank в направлении WEB-разработка.
Необходимо было разработать онлайн-редактор для проекта Алгосимулятор тестового стенда для проверки работы алгоритмов электронной торговли на языке Java. Каждый алгоритм реализуется в виде наследника класса AbstractTradingAlgorythm.


AbstractTradingAlgorythm.java
public abstract class AbstractTradingAlgorithm {    abstract void handleTicker(Ticker ticker) throws Exception;    public void receiveTick(String tick) throws Exception {        handleTicker(Ticker.parse(tick));    }    static class Ticker {        String pair;        double price;       static Ticker parse(String tick) {           Ticker ticker = new Ticker();           String[] tickerSplit = tick.split(",");           ticker.pair = tickerSplit[0];           ticker.price = Double.valueOf(tickerSplit[1]);           return ticker;       }    }}

Сам же редактор во время работы говорит тебе три вещи:


  1. Наследуешь ли ты правильный класс
  2. Будут ли ошибки на этапе компиляции
  3. Успешен ли тестовый прогон алгоритма. В данном случае подразумевается, что "В результате вызова new <ClassName>().receiveTick(RUBHGD,100.1) отсутствуют runtime exceptions".


Ну окей, скелет веб-сервиса через spring накидать дело на 5-10 минут. Пункт 1 работа для регулярных выражений, поэтому даже думать об этом сейчас не буду. Для пункта 2 можно конечно написать синтаксический анализатор, но зачем, когда это уже сделали за меня. Может и пункт 3 получится сделать, использовав наработки по пункту 2. В общем, дело за малым, уместить в один метод, ну например, компиляцию исходного кода программы на Java, переданного в контроллер строкой.


Решение


Здесь и начинается самое интересное. Забегая вперёд, как сделали другие ребята: установили на машину джаву, отдавали команды на ось и грепали stdout. Конечно, это более универсальный метод, но во-первых, нам сказали слово Java, а во-вторых...



у каждого свой путь.


Естественно, Java окружение устанавливать и настраивать всё же придётся. Правда компилировать и исполнять код мы будем не в терминале, а, как бы это ни звучало, в коде. Начиная с 6 версии, в Java SE присутствует пакет javax.tools, добавленный в стандартный API для компиляции исходного кода Java.
Теперь привычные понятия такие, как файлы с исходным кодом, параметры компилятора, каталоги с выходными файлами, сообщения компилятора, превратились в абстракции, используемые при работе с интерфейсом JavaCompiler, через реализации которого ведётся основная работа с задачами компиляции. Подробней о нём можно прочитать в официальной документации. Главное, что оттуда сейчас перейдёт моментально в текст статьи, это класс JavaSourceFromString. Дело в том, что, по умолчанию, исходный код загружается из файловой системы. В нашем же случае исходный код будет приходить строкой извне.


JavaSourceFromString.java
import javax.tools.SimpleJavaFileObject;import java.net.URI;public class JavaSourceFromString extends SimpleJavaFileObject {    final String code;    public JavaSourceFromString(String name, String code) {        super(URI.create("string:///" + name.replace('.', '/') + Kind.SOURCE.extension), Kind.SOURCE);        this.code = code;    }    @Override    public CharSequence getCharContent(boolean ignoreEncodingErrors) {        return code;    }}

Далее, в принципе уже ничего сложного нет. Получаем строку, имя класса и преобразуем их в объект JavaFileObject. Этот объект передаём в компилятор, компилируем и собираем вывод, который и возвращаем на клиент.
Сделаем класс Validator, в котором инкапсулируем процесс компиляции и тестового прогона некоторого исходника.


public class Validator {    private JavaSourceFromString sourceObject;    public Validator(String className, String source) {        sourceObject = new JavaSourceFromString(className, source);    }}

Далее добавим компиляцию.


public class Validator {    ...    public List<Diagnostic<? extends JavaFileObject>> compile() {        // получаем компилятор, установленный в системе        var compiler = ToolProvider.getSystemJavaCompiler();        // компилируем        var compilationUnits = Collections.singletonList(sourceObject);        var diagnostics = new DiagnosticCollector<JavaFileObject>();        compiler.getTask(null, null, diagnostics, null, null, compilationUnits).call();        // возворащаем диагностику        return diagnostics.getDiagnostics();    }}

Пользоваться этим можно как-то так.


public void MyMethod() {        var className = "TradeAlgo";        var sourceString = "public class TradeAlgo extends AbstractTradingAlgorithm{\n" +                "@Override\n" +                "    void handleTicker(Ticker ticker) throws Exception {\n" +                "       System.out.println(\"TradeAlgo::handleTicker\");\n" +                "    }\n" +                "}\n";        var validator = new Validator(className, sourceString);        for (var message : validator.compile()) {            System.out.println(message);        }    }

При этом, если компиляция прошла успешно, то возвращённый методом compile список будет пуст. Что интересно? А вот что.

На приведённом изображении вы можете видеть директорию проекта после завершения выполнения программы, во время выполнения которой была осуществлена компиляция. Красным прямоугольником обведены .class файлы, сгенерированные компилятором. Куда их девать, и как это чистить, не знаю жду в комментариях. Но что это значит? Что скомпилированные классы присоединяются в runtime, и там их можно использовать. А значит, следующий пункт задачи решается тривиально с помощью средств рефлексии.
Создадим вспомогательный POJO для хранения результата прогона.


TestResult.java
public class TestResult {    private boolean success;    private String comment;    public TestResult(boolean success, String comment) {        this.success = success;        this.comment = comment;    }    public boolean success() {        return success;    }    public String getComment() {        return comment;    }}

Теперь модифицируем класс Validator с учётом новых обстоятельств.


public class Validator {    ...    private String className;    private boolean compiled = false;    public Validator(String className, String source) {        this.className = className;        ...    }    ...    public TestResult testRun(String arg) {        var result = new TestResult(false, "Failed to compile");        if (compiled) {            try {                // загружаем класс                var classLoader = URLClassLoader.newInstance(new URL[]{new File("").toURI().toURL()});                var c = Class.forName(className, true, classLoader);                // создаём объект класса                var constructor = c.getConstructor();                var instance = constructor.newInstance();                // выполняем целевой метод                c.getDeclaredMethod("receiveTick", String.class).invoke(instance, arg);                result = new TestResult(true, "Success");            } catch (IllegalAccessException | InvocationTargetException | NoSuchMethodException | ClassNotFoundException | RuntimeException | MalformedURLException | InstantiationException e) {                var sw = new StringWriter();                e.printStackTrace(new PrintWriter(sw));                result = new TestResult(false, sw.toString());            }        }        return result;    }}

Возвращаясь к предыдущему примеру использования, можно дописать туда такие строчки.


public void MyMethod() {        ...        var result = validator.testRun("RUBHGD,100.1");        System.out.println(result.success() + " " + result.getComment());    }

Вставить этот код в реализацию API контроллера задача нетрудная, поэтому подробности её решения можно опустить.


Какие проблемы?


  1. Ещё раз напомню про кучу .class файлов.


  2. Поскольку опять же идёт работа с компиляцией некоторых классов, есть риск отказа в записи любого непредвиденного .class файла.


  3. Самое главное, наличие уязвимости для инъекции вредосного кода на языке программирования Java. Ведь, на самом деле, пользователь может написать что угодно в теле вызываемого метода. Это может быть вызов полного перегруза системы, затирание всей файловой системы машины и тому подобное. В общем, исполняемую среду нужно изолировать, как минимум, а в рамках хакатона этим в команде никто естественно не занимался ввиду нехватки времени.



Поэтому делать в точности как я не надо)


P.S. Ссылка на гитхаб с исходным кодом из статьи.

Подробнее..

Перевод Spring Cloud и Spring Boot. Часть 2 использование Zipkin Server для распределенной трассировки

02.02.2021 02:11:38 | Автор: admin

Из прошлой статьи (перевод на хабре, оригинал на англ.) вы узнали, как использовать Eureka Server для обнаружения и регистрации сервисов. В этой статье мы познакомимся с распределенной трассировкой (Distributed Tracing).

Что такое распределенная трассировка

Распределенная трассировка используется для поиска и устранения ошибок в работе микросервисов. Она помогает в отслеживании прохождения запроса через ряд микросервисов. И помимо этого, может использоваться для анализа производительности.

С ее помощью легко определить, какой микросервис упал или где возникли проблемы с производительностью.

В этой статье мы рассмотрим использование Zipkin Server для распределенной трассировки. Для этого нам понадобятся следующие зависимости в pom.xml.

<dependency>  <groupId>io.zipkin.java</groupId>  <artifactId>zipkin-server</artifactId>  <version>2.11.7</version></dependency><dependency>  <groupId>io.zipkin.java</groupId>  <artifactId>zipkin-autoconfigure-ui</artifactId>  <version>2.11.7</version></dependency>

Запуск Zipkin Server

Создайте maven-приложение и дайте ему какое-то имя (например, zipkin-server). Для создания Spring-проекта можно воспользоваться https://start.spring.io.

Ваш pom.xml должен выглядеть следующим образом:

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://personeltest.ru/away/maven.apache.org/POM/4.0.0" xmlns:xsi="http://personeltest.ru/away/www.w3.org/2001/XMLSchema-instance"      xsi:schemaLocation="http://personeltest.ru/away/maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">  <modelVersion>4.0.0</modelVersion>  <groupId>com.example.zikin.server</groupId>  <artifactId>zipkin-server</artifactId>  <version>0.0.1-SNAPSHOT</version>  <packaging>jar</packaging>  <name>zipkin-server</name>  <description>Demo project for Spring Boot</description>  <parent>     <groupId>org.springframework.boot</groupId>     <artifactId>spring-boot-starter-parent</artifactId>     <version>2.0.7.RELEASE</version>     <relativePath/> <!-- lookup parent from repository -->  </parent>  <properties>     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>     <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>     <java.version>1.8</java.version>  </properties>  <dependencies>     <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-web</artifactId>     </dependency>     <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-devtools</artifactId>        <scope>runtime</scope>     </dependency>     <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-test</artifactId>        <scope>test</scope>     </dependency>     <dependency>        <groupId>io.zipkin.java</groupId>        <artifactId>zipkin-server</artifactId>        <version>2.11.7</version>     </dependency>     <dependency>        <groupId>io.zipkin.java</groupId>        <artifactId>zipkin-autoconfigure-ui</artifactId>        <version>2.11.7</version>     </dependency>  </dependencies>  <build>     <plugins>        <plugin>           <groupId>org.springframework.boot</groupId>           <artifactId>spring-boot-maven-plugin</artifactId>        </plugin>     </plugins>  </build></project>

Теперь откройте ZipkinServerApplication.java и добавьте аннотацию @EnableZipkinServer, как показано ниже.

package com.example.zikin.server;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import zipkin2.server.internal.EnableZipkinServer;@SpringBootApplication@EnableZipkinServerpublic class ZipkinServerApplication {  public static void main(String[] args) {     SpringApplication.run(ZipkinServerApplication.class, args);  }}

В файл application.properties, расположенный в src/main/resources, добавьте следующие параметры.

spring.application.name=zipkin-serverserver.port=9411

Запустите проект как Java-приложение и перейдите по адресу http://localhost:9411/zipkin.

Здесь пока нет никаких трейсов, так как клиентские приложения еще не зарегистрированы.

Регистрация клиентского приложения в Zipkin Server

Регистрация Eureka Server в Zipkin Server

В предыдущей статье (перевод на хабре, оригинал на англ.) мы посмотрели, как запустить Eureka Server. Теперь его можно зарегистрировать в Zipkin Server, добавив одно свойство в файл application.properties.

spring.zipkin.base-url=http://localhost:9411/

Параметр spring.zipkin.base-url определяет адрес, где находится Zipkin Server.

Вам также необходимо добавить еще одну зависимость в pom.xml приложения Eureka Server.

<dependency>   <groupId>org.springframework.cloud</groupId>   <artifactId>spring-cloud-starter-zipkin</artifactId></dependency>

После того как Eureka Server запустится, в Zipkin Server вы увидите трейсы, а в Zipkin Server UI в поле Service Name появится eureka-server.

Регистрация клиентского Spring Boot-приложения в Zipkin Server

Для регистрации любого клиентского приложения, основанного на Spring Boot, нужно добавить одно свойство в файл application.properties.

spring.zipkin.base-url=http://localhost:9411/

И одну зависимость в pom.xml вашего клиентского приложения.

<dependency>   <groupId>org.springframework.cloud</groupId>   <artifactId>spring-cloud-starter-zipkin</artifactId></dependency>

После запуска клиентского приложения вы сможете увидеть его трассировку в Zipkin.

Просмотр деталей трассировки в Zipkin Server

Вы можете посмотреть детали трассировки, нажав на любую запись, показанную на изображении выше.

Теперь вы знаете, как использовать Zipkin Server для распределенной трассировки.


Перевод статьи подготовлен в преддверии старта курса Разработчик на Spring Framework. Приглашаем всех желающих зарегистрироваться на бесплатный демо-урок по теме Введение в облака, создание кластера в Mongo DB Atlas.

На уроке участники вместе с экспертом поговорят о видах облаков и настроят бесплатный Mongo DB кластер для своих проектов.

Подробнее..

Перевод Шпаргалка по Spring Boot WebClient

09.02.2021 02:22:17 | Автор: admin

В преддверии старта курса Разработчик на Spring Framework подготовили традиционный перевод полезного материала.

Также абсолютно бесплатно предлагаем посмотреть запись демо-урока на тему
Введение в облака, создание кластера в Mongo DB Atlas.


WebClient это неблокирующий, реактивный клиент для выполнения HTTP-запросов.

Время RestTemplate подошло к концу

Возможно, вы слышали, что время RestTemplate на исходе. Теперь это указано и в официальной документации:

NOTE: As of 5.0 this class is in maintenance mode, with only minor requests for changes and bugs to be accepted going forward. Please, consider using the org.springframework.web.reactive.client.WebClient which has a more modern API and supports sync, async, and streaming scenarios.

ПРИМЕЧАНИЕ: Начиная с версии 5.0, этот класс законсервирован и в дальнейшем будут приниматься только минорные запросы на изменения и на исправления багов. Пожалуйста, подумайте об использовании org.springframework.web.reactive.client.WebClient, который имеет более современный API и поддерживает синхронную, асинхронную и потоковую передачи.

Конечно, мы понимаем, что RestTemplate не исчезнет мгновенно, однако новой функциональности в нем уже не будет. По этой причине в Интернете можно видеть десятки вопросов о том, что такое WebClient и как его использовать. В этой статье вы найдете советы по использованию новой библиотеки.

Отличия между WebClient и RestTemplate

Если в двух словах, то основное различие между этими технологиями заключается в том, что RestTemplate работает синхронно (блокируя), а WebClient работает асинхронно (не блокируя).

RestTemplate это синхронный клиент для выполнения HTTP-запросов, он предоставляет простой API с шаблонным методом поверх базовых HTTP-библиотек, таких как HttpURLConnection (JDK), HttpComponents (Apache) и другими.

Spring WebClient это асинхронный, реактивный клиент для выполнения HTTP-запросов, часть Spring WebFlux.

Вам, вероятно, интересно, как можно заменить синхронного клиента на асинхронный. У WebClient есть решение этой задачи. Мы рассмотрим несколько примеров использования WebClient.

А сейчас настало время попрощаться с RestTemplate , сказать ему спасибо и продолжить изучение WebClient.

Начало работы с WebClient

Предварительные условия

Подготовка проекта

Давайте создадим базовый проект с зависимостями, используя Spring Initializr.

Теперь взглянем на зависимости нашего проекта. Самая важная для нас зависимость spring-boot-starter-webflux.

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-webflux</artifactId> </dependency>

Spring WebFlux является частью Spring 5 и обеспечивает поддержку реактивного программирования для веб-приложений.

Пришло время настроить WebClient.

Настройка WebClient

Есть несколько способов настройки WebClient. Первый и самый простой создать его с настройками по умолчанию.

WebClient client = WebClient.create();

Можно также указать базовый URL:

WebClient client = WebClient.create("http://base-url.com");

Третий и самый продвинутый вариант создать WebClient с помощью билдера. Мы будем использовать конфигурацию, которая включает базовый URL и таймауты.

@Configurationpublic class WebClientConfiguration {    private static final String BASE_URL = "https://jsonplaceholder.typicode.com";    public static final int TIMEOUT = 1000;    @Bean    public WebClient webClientWithTimeout() {        final var tcpClient = TcpClient                .create()                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, TIMEOUT)                .doOnConnected(connection -> {                    connection.addHandlerLast(new ReadTimeoutHandler(TIMEOUT, TimeUnit.MILLISECONDS));                    connection.addHandlerLast(new WriteTimeoutHandler(TIMEOUT, TimeUnit.MILLISECONDS));                });        return WebClient.builder()                .baseUrl(BASE_URL)                .clientConnector(new ReactorClientHttpConnector(HttpClient.from(tcpClient)))                .build();    }}

Параметры, поддерживаемые WebClient.Builder можно посмотреть здесь.

Подготовка запроса с помощью Spring WebClient

WebClient поддерживает методы: get(), post(), put(), patch(), delete(), options() и head().

Также можно указать следующие параметры:

  • Переменные пути (path variables) и параметры запроса с помощью метода uri().

  • Заголовки запроса с помощью метода headers().

  • Куки с помощью метода cookies().

После указания параметров можно выполнить запрос с помощью retrieve() или exchange(). Далее мы преобразуем результат в Mono с помощью bodyToMono() или во Flux с помощью bodyToFlux().

Асинхронный запрос

Давайте создадим сервис, который использует бин WebClient и создает асинхронный запрос.

@Service@AllArgsConstructorpublic class UserService {    private final WebClient webClient;    public Mono<User> getUserByIdAsync(final String id) {        return webClient                .get()                .uri(String.join("", "/users/", id))                .retrieve()                .bodyToMono(User.class);    }}

Как вы видите, мы не сразу получаем модель User. Вместо User мы получаем Mono-обертку, с которой выполняем различные действия. Давайте подпишемся неблокирующим способом, используя subscribe().

userService  .getUserByIdAsync("1")  .subscribe(user -> log.info("Get user async: {}", user));

Выполнение продолжается сразу без блокировки на методе subscribe(), даже если для получения значения будет требоваться некоторое время.

Синхронный запрос

Если вам нужен старый добрый синхронный вызов, то это легко сделать с помощью метода block().

public User getUserByIdSync(final String id) {    return webClient            .get()            .uri(String.join("", "/users/", id))            .retrieve()            .bodyToMono(User.class)            .block();}

Здесь поток блокируется, пока запрос не выполнится. В этом случае мы получаем запрашиваемую модель сразу же после завершения выполнения метода.

Повторные попытки

Мы все знаем, что сетевой вызов не всегда может быть успешным. Но мы можем перестраховаться и в некоторых случаях выполнить его повторно. Для этого используется метод retryWhen(), который принимает в качестве аргумента класс response.util.retry.Retry.

public User getUserWithRetry(final String id) {    return webClient            .get()            .uri(String.join("", "/users/", id))            .retrieve()            .bodyToMono(User.class)            .retryWhen(Retry.fixedDelay(3, Duration.ofMillis(100)))            .block();}

С помощью билдера можно настроить параметры и различные стратегии повтора (например, экспоненциальную). Если вам нужно повторить успешную попытку, то используйте repeatWhen() или repeatWhenEmpty() вместо retryWhen().

Обработка ошибок

В случае ошибки, когда повторная попытка не помогает, мы все еще можем контролировать ситуацию с помощью резервного варианта. Доступны следующие методы:

  • doOnError() срабатывает, когда Mono завершается с ошибкой.

  • onErrorResume() при возникновении ошибки подписывается на резервного издателя, используя функцию для выбора действия в зависимости от ошибки.

Вы можете использовать эти функции для вызова другого сервиса, выбрасывания исключения, записи в лог или выполнения любого действия в зависимости от ошибки.

public User getUserWithFallback(final String id) {    return webClient            .get()            .uri(String.join("", "/broken-url/", id))            .retrieve()            .bodyToMono(User.class)            .doOnError(error -> log.error("An error has occurred {}", error.getMessage()))            .onErrorResume(error -> Mono.just(new User()))            .block();}

В некоторых ситуациях может быть полезно отреагировать на конкретный код ошибки. Для этого можно использовать метод onStatus().

public User getUserWithErrorHandling(final String id) {  return webClient          .get()          .uri(String.join("", "/broken-url/", id))          .retrieve()              .onStatus(HttpStatus::is4xxClientError,                      error -> Mono.error(new RuntimeException("API not found")))              .onStatus(HttpStatus::is5xxServerError,                      error -> Mono.error(new RuntimeException("Server is not responding")))          .bodyToMono(User.class)          .block();}

Клиентские фильтры

Для перехвата и изменения запроса можно настроить фильтры через билдер WebClient .

WebClient.builder()  .baseUrl(BASE_URL)  .filter((request, next) -> next          .exchange(ClientRequest.from(request)                  .header("foo", "bar")                  .build()))  .clientConnector(new ReactorClientHttpConnector(HttpClient.from(tcpClient)))  .build();

Ниже приведен пример фильтра для базовой аутентификации с помощью статического фабричного метода.

WebClient.builder()  .baseUrl(BASE_URL)  .filter(basicAuthentication("user", "password")) // org.springframework.web.reactive.function.client.basicAuthentication()  .clientConnector(new ReactorClientHttpConnector(HttpClient.from(tcpClient)))  .build();

Заключение

В этой статье мы узнали, как настроить WebClient и выполнять синхронные и асинхронные HTTP-запросы. Все фрагменты кода, упомянутые в статье, можно найти в GitHub-репозитории. Документацию по Spring WebClient вы можете найти здесь.

Подводя итог, мы видим, что WebClient прост в использовании и включает в себя все необходимые функции, необходимые в современном программировании.

Удачи с новым Spring WebClient!


Узнать подробнее о курсе Разработчик на Spring Framework.

Посмотреть запись демо-урока на тему Введение в облака, создание кластера в Mongo DB Atlas.

Подробнее..

Code evaluation как средство отладки

15.02.2021 14:04:42 | Автор: admin

Господа разработчики java приложений. Сегодня вашему вниманию представляется простой способ использования code evaluation, реализация которого позволит исполнять произвольный код в работающем приложении, что в свою очередь позволит сэкономить массу времени на CI/CD.

Зачем мне это нужно?

Если вам приходится разрабатывать в условиях микросервисной архитектуры, особенно в большой компании, то скорее всего вам знакома ситуация, когда посмотреть как "по-боевому" работает приложение можно только на стендах на которых есть интеграции с другими микросервисами. И поскольку далеко не все вещи можно проверить локально на заглушках, для того чтобы проверить ту или иную гипотезу, приходится пушить новый код (не факт что работающий корректно) в репозиторий... прогонять его через CI/CD... и только потом по логам понять что где-то что-то пошло не так. И хорошо если логи сразу покажут в чём вы ошиблись, потому как иначе этот процесс пуша и прогона по пайплайнам может стать вашим круговоротом сансары.

Исполнение динамически введённого кода поможет решить эту проблему.

Как это работает?

Как мы с вами знаем, groovy это полностью совместимый с Java язык программирования с динамической компиляцией. Эти две особенности groovy и помогут нам в том, что бы реализовать code evaluation для java приложений. О том как добавить поддержку groovy в java проект вы сможете легко найти сами. А я приведу пример, как реализовать code evaluation (в некотором смысле аналогичный тому, который вы можете видеть во время дебага в вашей IDE).

1) Создадим groovy класс, а в нём шаблонную строку в которую поместим класс и плейсхолдер для динамически введённого кода. Пример такой строки:

def EXPRESSION_CLASS_TEMPLATE = """package dev.toliyansky.eval.serviceclass ExpressionClass implements java.util.function.Supplier<Object> {def get() {%s}}"""

Примечание: package должен быть такой же как и у класса в котором вы этот код будете писать.

Почему мы имплементируем Supplier будет описано ниже.

2) Динамически скомпилируем и загрузим этот класс.

Кусок кода ниже может быть размещён например в REST контроллере, который получает code как тело запроса.

def finalClassCode = String.format(EXPRESSION_CLASS_TEMPLATE, code)def supplier = groovyClassLoader.parseClass(finalClassCode)                                .getDeclaredConstructor()                                .newInstance() as Supplier<Object>def result = supplier.get()

В первой строчке заменяем %s на код который хотим динамически ввести и исполнить в рантайме.

Во второй строке компилируем и загружаем класс из строки, которую получили на предыдущем шаге. Тут важно заметить что созданный инстанс класса приводим к Supplier для того, чтобы далее в третьей строчке можно было сделать вызов метода в котором должен исполниться динамически введённый код. Supplier<Object> в данном случае идеально нам подходит.

Вот собственно и всё.

Пример использования code evaluation

Допустим у вас web приложение в kubernetes. Вы написали какую-то новую фичу, закоммитились, прошли код ревью, прогнали код через CI/CD и вот POD с вашим приложением наконец поднимается, вы заходите в логи и видите что фича работает не так как ожидалось. Допустим, для примера, что вы забыли в конструкторе что-то проинициализировать и поэтому остальная бизнес логика не отрабатывает с банальным NullPointerException.

Имея в своём арсенале HTTP роут с исполнением динамического кода, можно спокойно обратиться к applicationContext, вытащить нужный бин и ручками проинициализировать забытую переменную. После чего потыкать в инициирование отработки бизнес кода и проверить результат, минуя весь CI/CD. Таким банальным примером всё не ограничивается. При желании можно даже в райнтайме переопределить метод класса с бизнес логикой и играться до тех пор пока не отладите код и потом уже зная как оно себя ведёт коммититься и прогонять пайплайны.

Готовое решение для web приложений на spring boot

Если вы не хотите возиться с добавлением groovy в ваш java проект и писать все эти контроллеры, обёртки, разбираться с динамикой, а просто хотите добавить в одну строчку зависимость в ваш проект и чтобы работало из коробки, то тогда специально для вас презентую маленький проект который всё это умеет - evaluator-spring-boot-starter

Это, как можно догадаться из названия, spring boot starter. Подключение данного стартера добавляет в ваше web приложение роут http://host:port/eval отдающий WEB-UI, в котором можно ввести код который хотите динамически исполнить, а результат выведется в окне рядом. Всё это приправлено подсветкой синтаксиса, и прочими удобствами. Если же, например, ваше приложение не имеет выходного роута из кластера и вы можете только лишь использовать curl или wget из терминала POD, то тогда можно использовать роут http://host:port/eval/groovy и отправлять код как параметр GET запроса или как тело POST запроса.

Впрочем, всё это более-менее подробно описано в readme проекта.

Скриншот WEB-UI evaluator-spring-boot-starterСкриншот WEB-UI evaluator-spring-boot-starter

В итоге

  • Продемонстрировано как code evaluation может сэкономить время на отладке приложения

  • Продемонстрировано как реализовать code evaluation в java проекте

  • Продемонстрировано готовое решение в виде spring boot starter.

Подробнее..

REST API с использованием Spring Security и JWT

05.03.2021 00:08:39 | Автор: admin

Рано или поздно каждый Java-разработчик столкнется с необходимостью реализовать защищенное REST API приложение. В этой статье хочу поделиться своей реализацией этой задачи.

1. Что такое REST?

REST (от англ. Representational State Transfer передача состояния представления) это общие принципы организации взаимодействия приложения/сайта с сервером посредством протокола HTTP.

Диаграмма ниже показывает общую модель.

Всё взаимодействие с сервером сводится к 4 операциям (4 это необходимый и достаточный минимум, в конкретной реализации типов операций может быть больше):

  1. Получение данных с сервера (обычно в формате JSON, или XML);

  2. Добавление новых данных на сервер;

  3. Модификация существующих данных на сервере;

  4. Удаление данных на сервере

Более подробно можно прочесть в остальных источниках, статей о REST много.

2. Задача

Необходимо подготовить защищенное REST приложение, доступ к которому может быть осуществлен только для авторизованного пользователя. Авторизация с передачей логина и пароля выполняется отдельным запросом, при успешной авторизации система должна сгенерировать и вернуть токен. Валидация остальных запросов должна быть осуществлена по токену.
Схема нашего приложения будет выглядеть следующим образом:

3. Технологии

Для решения используем фреймворк Spring Boot и Spring Web, для него требуется:

  1. Java 8+;

  2. Apache Maven

Авторизация и валидация будет выполнена силами Spring Security и JsonWebToken (JWT).
Для уменьшения кода использую Lombok.

4. Создание приложения

Переходим к практике. Создаем Spring Boot приложение и реализуем простое REST API для получения данных пользователя и списка пользователей.

4.1 Создание Web-проекта

Создаем Maven-проект SpringBootSecurityRest. При инициализации, если вы это делаете через Intellij IDEA, добавьте Spring Boot DevTools, Lombok и Spring Web, иначе добавьте зависимости отдельно в pom-файле.

4.2 Конфигурация pom-xml

После развертывания проекта pom-файл должен выглядеть следующим образом:

  1. Должен быть указан parent-сегмент с подключенным spring-boot-starter-parent;

  2. И установлены зависимости spring-boot-starter-web, spring-boot-devtools и Lombok.

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://personeltest.ru/away/maven.apache.org/POM/4.0.0" xmlns:xsi="http://personeltest.ru/away/www.w3.org/2001/XMLSchema-instance"         xsi:schemaLocation="http://personeltest.ru/away/maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">    <modelVersion>4.0.0</modelVersion>    <parent>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-parent</artifactId>        <version>2.3.5.RELEASE</version>        <relativePath/> <!-- lookup parent from repository -->    </parent>    <groupId>com</groupId>    <artifactId>springbootsecurityrest</artifactId>    <version>0.0.1-SNAPSHOT</version>    <name>springbootsecurityrest</name>    <description>Demo project for Spring Boot</description>    <properties>        <java.version>15</java.version>    </properties>    <dependencies>        <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-starter-web</artifactId>        </dependency>        <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-devtools</artifactId>            <scope>runtime</scope>            <optional>true</optional>        </dependency>        <dependency>            <groupId>org.projectlombok</groupId>            <artifactId>lombok</artifactId>            <optional>true</optional>        </dependency>        <!--Test-->        <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-starter-test</artifactId>            <scope>test</scope>            <exclusions>                <exclusion>                    <groupId>org.junit.vintage</groupId>                    <artifactId>junit-vintage-engine</artifactId>                </exclusion>            </exclusions>        </dependency>    </dependencies>    <build>        <plugins>            <plugin>                <groupId>org.springframework.boot</groupId>                <artifactId>spring-boot-maven-plugin</artifactId>                <configuration>                    <excludes>                        <exclude>                            <groupId>org.projectlombok</groupId>                            <artifactId>lombok</artifactId>                        </exclude>                    </excludes>                </configuration>            </plugin>        </plugins>    </build></project>

4.3 Создание ресурса REST

Разделим все классы на слои, создадим в папке com.springbootsecurityrest четыре новые папки:

  • model для хранения POJO-классов;

  • repository в полноценных проектах используется для взаимодействия с БД, но т.к. у нас ее нет, то он будет содержать список пользователей;

  • service слой сервиса, прослойка между контролером и слоем ресурсов, используется для получения данных из ресурса, их проверки и преобразования (если это необходимо);

  • rest будет содержать в себе классы контроллеры.

В папке model создаем POJO класс User.

import lombok.AllArgsConstructor;import lombok.Data;@Data@AllArgsConstructorpublic class User {    private String login;    private String password;    private String firstname;    private String lastname;    private Integer age;}

В папке repository создаём класс UserRepository c двумя методами:

  1. getByLogin который будет возвращать пользователя по логину;

  2. getAll который будет возвращать список всех доступных пользователей. Чтобы Spring создал бин на основании этого класса, устанавливаем ему аннотацию @Repository.

@Repositorypublic class UserRepository {      private List<User> users;    public UserRepository() {        this.users = List.of(                new User("anton", "1234", "Антон", "Иванов", 20),                new User("ivan", "12345", "Сергей", "Петров", 21));    }    public User getByLogin(String login) {        return this.users.stream()                .filter(user -> login.equals(user.getLogin()))                .findFirst()                .orElse(null);    }    public List<User> getAll() {        return this.users;    }

В папке service создаем класс UserService. Устанавливаем классу аннотацию @Service и добавляем инъекцию бина UserRepository. В класс добавляем метод getAll, который будет возвращать всех пользователей и getByLogin для получения одного пользователя по логину.

@Servicepublic class UserService {    private UserRepository repository;    public UserService(UserRepository repository) {        this.repository = repository;    }    public List<User> getAll() {        return this.repository.getAll();    }    public User getByLogin(String login) {        return this.repository.getByLogin(login);    }}

Создаем контроллер UserController в папке rest, добавляем ему инъекцию UserService и создаем один метод getAll. С помощью аннотации @GetMapping указываем адрес контроллера, по которому он будет доступен клиенту и тип возвращаемых данных.

@RestControllerpublic class UserController {    private UserService service;    public UserController(UserService service) {        this.service = service;    }    @GetMapping(path = "/users", produces = MediaType.APPLICATION_JSON_VALUE)    public @ResponseBody List<User> getAll() {        return this.service.getAll();    }}

Запускаем приложение и проверяем, что оно работает, для этого достаточно в браузере указать адрес http://localhost:8080/users, если вы все сделали верно, то увидите следующее:

5. Spring Security

Простенькое REST API написано и пока оно открыто для всех. Двигаемся дальше, теперь его необходимо защитить, а доступ открыть только авторизованным пользователям. Для этого воспользуемся Spring Security и JWT.

Spring Security это Java/JavaEE framework, предоставляющий механизмы построения систем аутентификации и авторизации, а также другие возможности обеспечения безопасности для корпоративных приложений, созданных с помощью Spring Framework.

JSON Web Token (JWT) это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON. Как правило, используется для передачи данных для аутентификации в клиент-серверных приложениях. Токены создаются сервером, подписываются секретным ключом и передаются клиенту, который в дальнейшем использует данный токен для подтверждения своей личности.

5.1 Подключаем зависимости

Добавляем новые зависимости в pom-файл.

<!--Security--><dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-starter-security</artifactId></dependency><dependency>    <groupId>io.jsonwebtoken</groupId>    <artifactId>jjwt</artifactId>    <version>0.9.1</version></dependency><dependency>    <groupId>jakarta.xml.bind</groupId>    <artifactId>jakarta.xml.bind-api</artifactId>    <version>2.3.3</version></dependency>

5.2 Генерация и хранения токена

Начнем с генерации и хранения токена, для этого создадим папку security и в ней создаем класс JwtTokenRepository с имплементацией интерфейса CsrfTokenRepository (из пакета org.springframework.security.web.csrf).

Интерфейс указывает на необходимость реализовать три метода:

  1. Генерация токена в методе generateToken;

  2. Сохранения токена saveToken;

  3. Получение токена loadToken.

Генерируем токен силами Jwt, пример реализации метода.

@Repositorypublic class JwtTokenRepository implements CsrfTokenRepository {    @Getter    private String secret;    public JwtTokenRepository() {        this.secret = "springrest";    }    @Override    public CsrfToken generateToken(HttpServletRequest httpServletRequest) {        String id = UUID.randomUUID().toString().replace("-", "");        Date now = new Date();        Date exp = Date.from(LocalDateTime.now().plusMinutes(30)                .atZone(ZoneId.systemDefault()).toInstant());        String token = "";        try {            token = Jwts.builder()                    .setId(id)                    .setIssuedAt(now)                    .setNotBefore(now)                    .setExpiration(exp)                    .signWith(SignatureAlgorithm.HS256, secret)                    .compact();        } catch (JwtException e) {            e.printStackTrace();            //ignore        }        return new DefaultCsrfToken("x-csrf-token", "_csrf", token);    }    @Override    public void saveToken(CsrfToken csrfToken, HttpServletRequest request, HttpServletResponse response) {    }    @Override    public CsrfToken loadToken(HttpServletRequest request) {        return null;    }}

Параметр secret является ключом, необходимым для расшифровки токена, оно может быть постоянным для всех токенов, но лучше сделать его уникальным только для пользователя, например для этого можно использовать ip-пользователя или его логин. Дата exp является датой окончания токена, рассчитывается как текущая дата плюс 30 минут. Такой параметр как продолжительность жизни токена рекомендую вынести в application.properties.

Токен будет генерироваться новый на каждом запросе с жизненным циклом в 30 минут. После каждого запроса на фронте необходимо перезаписывать токен и следующий запрос выполнять с новым. Он станет невалидным только в том случае, если между запросами пройдет более 30 минут.

    @Override    public void saveToken(CsrfToken csrfToken, HttpServletRequest request, HttpServletResponse response) {        if (Objects.nonNull(csrfToken)) {            if (!response.getHeaderNames().contains(ACCESS_CONTROL_EXPOSE_HEADERS))                response.addHeader(ACCESS_CONTROL_EXPOSE_HEADERS, csrfToken.getHeaderName());            if (response.getHeaderNames().contains(csrfToken.getHeaderName()))                response.setHeader(csrfToken.getHeaderName(), csrfToken.getToken());            else                response.addHeader(csrfToken.getHeaderName(), csrfToken.getToken());        }    }    @Override    public CsrfToken loadToken(HttpServletRequest request) {        return (CsrfToken) request.getAttribute(CsrfToken.class.getName());    }

Сохранение токена выполняем в response (ответ от сервера) в раздел headers и открываем параметр для чтения фронта указав имя параметра в Access-Control-Expose-Headers.

Добавляем к классу еще один метод по очистке токена из response, будем использовать его при ошибке авторизации.

    public void clearToken(HttpServletResponse response) {        if (response.getHeaderNames().contains("x-csrf-token"))            response.setHeader("x-csrf-token", "");    }

5.3 Создание нового фильтра для SpringSecurity

Создаем новый класс JwtCsrfFilter, который является реализацией абстрактного класса OncePerRequestFilter (пакет org.springframework.web.filter). Класс будет выполнять валидацию токена и инициировать создание нового. Если обрабатываемый запрос относится к авторизации (путь /auth/login), то логика не выполняется и запрос отправляется далее для выполнения базовой авторизации.

public class JwtCsrfFilter extends OncePerRequestFilter {    private final CsrfTokenRepository tokenRepository;    private final HandlerExceptionResolver resolver;    public JwtCsrfFilter(CsrfTokenRepository tokenRepository, HandlerExceptionResolver resolver) {        this.tokenRepository = tokenRepository;        this.resolver = resolver;    }    @Override    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)            throws ServletException, IOException {        request.setAttribute(HttpServletResponse.class.getName(), response);        CsrfToken csrfToken = this.tokenRepository.loadToken(request);        boolean missingToken = csrfToken == null;        if (missingToken) {            csrfToken = this.tokenRepository.generateToken(request);            this.tokenRepository.saveToken(csrfToken, request, response);        }        request.setAttribute(CsrfToken.class.getName(), csrfToken);        request.setAttribute(csrfToken.getParameterName(), csrfToken);        if (request.getServletPath().equals("/auth/login")) {            try {                filterChain.doFilter(request, response);            } catch (Exception e) {                resolver.resolveException(request, response, null, new MissingCsrfTokenException(csrfToken.getToken()));            }        } else {            String actualToken = request.getHeader(csrfToken.getHeaderName());            if (actualToken == null) {                actualToken = request.getParameter(csrfToken.getParameterName());            }            try {                if (!StringUtils.isEmpty(actualToken)) {                    Jwts.parser()                            .setSigningKey(((JwtTokenRepository) tokenRepository).getSecret())                            .parseClaimsJws(actualToken);                        filterChain.doFilter(request, response);                } else                    resolver.resolveException(request, response, null, new InvalidCsrfTokenException(csrfToken, actualToken));            } catch (JwtException e) {                if (this.logger.isDebugEnabled()) {                    this.logger.debug("Invalid CSRF token found for " + UrlUtils.buildFullRequestUrl(request));                }                if (missingToken) {                    resolver.resolveException(request, response, null, new MissingCsrfTokenException(actualToken));                } else {                    resolver.resolveException(request, response, null, new InvalidCsrfTokenException(csrfToken, actualToken));                }            }        }    }}

5.4 Реализация сервиса поиска пользователя

Теперь необходимо подготовить сервис для поиска пользователя по логину, которого будем авторизовывать. Для этого нам необходимо добавить к сервису UserService интерфейс UserDetailsService из пакета org.springframework.security.core.userdetails. Интерфейс требует реализовать один метод, выносить его в отдельный класс нет необходимости.

@Servicepublic class UserService implements UserDetailsService {    private UserRepository repository;    public UserService(UserRepository repository) {        this.repository = repository;    }    public List<User> getAll() {        return this.repository.getAll();    }    public User getByLogin(String login) {        return this.repository.getByLogin(login);    }    @Override    public UserDetails loadUserByUsername(String login) throws UsernameNotFoundException {        User u = getByLogin(login);        if (Objects.isNull(u)) {            throw new UsernameNotFoundException(String.format("User %s is not found", login));        }        return new org.springframework.security.core.userdetails.User(u.getLogin(), u.getPassword(), true, true, true, true, new HashSet<>());    }}

Полученного пользователя необходимо преобразовать в класс с реализацией интерфейса UserDetails или воспользоваться уже готовой реализацией из пакета org.springframework.security.core.userdetails. Последним параметром конструктора необходимо добавить список элементов GrantedAuthority, это роли пользователя, у нас их нет, оставим его пустым. Если пользователя по логину не нашли, то бросаем исключение UsernameNotFoundException.

5.5 Обработка авторизации

По результату успешно выполненной авторизации возвращаю данные авторизованного пользователя. Для этого создадим еще один контроллер AuthController с методом getAuthUser. Контроллер будет обрабатывать запрос /auth/login, а именно обращаться к контексту Security для получения логина авторизованного пользователя, по нему получать данные пользователя из сервиса UserService и возвращать их на фронт.

@RestController@RequestMapping("/auth")public class AuthController {    private UserService service;    public AuthController(UserService service) {        this.service = service;    }    @PostMapping(path = "/login", produces = MediaType.APPLICATION_JSON_VALUE)    public @ResponseBody com.springbootsecurityrest.model.User getAuthUser() {        Authentication auth = SecurityContextHolder.getContext().getAuthentication();        if (auth == null) {            return null;        }        Object principal = auth.getPrincipal();        User user = (principal instanceof User) ? (User) principal : null;        return Objects.nonNull(user) ? this.service.getByLogin(user.getUsername()) : null;    }}

5.6 Обработка ошибок

Что бы видеть ошибки авторизации или валидации токена, необходимо подготовить обработчик ошибок. Для этого создаем новый класс GlobalExceptionHandler в корне com.springbootsecurityrest, который является расширением класса ResponseEntityExceptionHandler с реализацией метода handleAuthenticationException.

Метод будет устанавливать статус ответа 401 (UNAUTHORIZED) и возвращать сообщение в формате ErrorInfo.

@RestControllerAdvicepublic class GlobalExceptionHandler extends ResponseEntityExceptionHandler {    private JwtTokenRepository tokenRepository;    public GlobalExceptionHandler(JwtTokenRepository tokenRepository) {        this.tokenRepository = tokenRepository;    }    @ExceptionHandler({AuthenticationException.class, MissingCsrfTokenException.class, InvalidCsrfTokenException.class, SessionAuthenticationException.class})    public ErrorInfo handleAuthenticationException(RuntimeException ex, HttpServletRequest request, HttpServletResponse response){        this.tokenRepository.clearToken(response);        response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);        return new ErrorInfo(UrlUtils.buildFullRequestUrl(request), "error.authorization");    }    @Getter public class ErrorInfo {        private final String url;        private final String info;        ErrorInfo(String url, String info) {            this.url = url;            this.info = info;        }    }}

5.7 Настройка конфигурационного файла Spring Security.

Все данные подготовили и теперь необходимо настроить конфигурационный файл. В папке com.springbootsecurityrest создаем файл SpringSecurityConfig, который является реализацией абстрактного класса WebSecurityConfigurerAdapter пакета org.springframework.security.config.annotation.web.configuration. Помечаем класс двумя аннотациями: Configuration и EnableWebSecurity.

Реализуем метод configure(AuthenticationManagerBuilder auth), в класс AuthenticationManagerBuilder устанавливаем сервис UserService, для того что бы Spring Security при выполнении базовой авторизации мог получить из репозитория данные пользователя по логину.

@Configuration@EnableWebSecuritypublic class SpringSecurityConfig extends WebSecurityConfigurerAdapter {    @Autowired    private UserService service;    @Autowired    private JwtTokenRepository jwtTokenRepository;    @Autowired    @Qualifier("handlerExceptionResolver")    private HandlerExceptionResolver resolver;    @Bean    public PasswordEncoder devPasswordEncoder() {        return NoOpPasswordEncoder.getInstance();    }      @Override    protected void configure(HttpSecurity http) throws Exception {         }    @Override    protected void configure(AuthenticationManagerBuilder auth) throws Exception {        auth.userDetailsService(this.service);    }}

Реализуем метод configure(HttpSecurity http):

    @Override    protected void configure(HttpSecurity http) throws Exception {        http                .sessionManagement()                    .sessionCreationPolicy(SessionCreationPolicy.NEVER)                .and()                    .addFilterAt(new JwtCsrfFilter(jwtTokenRepository, resolver), CsrfFilter.class)                    .csrf().ignoringAntMatchers("/**")                .and()                    .authorizeRequests()                    .antMatchers("/auth/login")                    .authenticated()                .and()                    .httpBasic()                    .authenticationEntryPoint(((request, response, e) -> resolver.resolveException(request, response, null, e)));    }

Разберем метод детальнее:

  1. sessionManagement().sessionCreationPolicy(SessionCreationPolicy.NEVER) - отключаем генерацию сессии;

  2. addFilterAt(new JwtCsrfFilter(jwtTokenRepository, resolver), CsrfFilter.class).csrf().ignoringAntMatchers("/**") - указываем созданный нами фильтр JwtCsrfFilter в расположение стандартного фильтра, при этом игнорируем обработку стандартного;

  3. .authorizeRequests().antMatchers("/auth/login").authenticated() для запроса /auth/login выполняем авторизацию силами security. Что бы не было двойной валидации (по токену и базовой), запрос был добавлен в исключение к классу JwtCsrfFilter;

  4. .httpBasic().authenticationEntryPoint(((request, response, e) -> resolver.resolveException(request, response, null, e))) - ошибки базовой авторизации отправляем в обработку GlobalExceptionHandler

6. Проверка функционала

Для проверки использую Postman. Запускаем бэкенд и выполняем запрос http://localhost:8080/users с типом GET.

Токена нет, валидация не пройдена, получаем сообщение с 401 статусом.

Пытаемся авторизоваться с неверными данными, выполняем запрос http://localhost:8080/auth/login с типом POST, валидация не выполнена, токен не получен, вернулась ошибка с 401 статусом.

Авторизуемся с корректными данными, авторизация выполнена, получен авторизованный пользователь и токен.

Повторяем запрос http://localhost:8080/users с типом GET, но с полученным токеном на предыдущем шаге. Получаем список пользователей и обновленный токен.

Заключение

В этой статье рассмотрели один из примеров реализации REST приложения с Spring Security и JWT. Надеюсь данный вариант реализации кому то окажется полезным.

Полный код проекта выложен доступен на github

Подробнее..

JPA Buddy Умный помощник половина работы

17.03.2021 14:12:14 | Автор: admin

От переводчика: это статья моего коллеги @aleksey-stukalov, которую мы опубликовали в блоге JPA Buddy пару месяцев назад. С тех пор мы выпустили JPA Buddy 2.0, но все сказанное в этой статье актуальности не потеряло.

Ну что ж, Hello World... После почти года разработки наконец-то вышла первая версия JPA Buddy! Это инструмент, который должен стать вашим верным помощником по написанию кода для проектов с JPA и всем, что с этим связано: Hibernate, Spring Data, Liquibase и другим ПО из типичного стека разработки.

Чем он вам поможет? Если кратко, JPA Buddy упростит работу с JPA и тем самым сэкономит ваше время. В этой статье мы взглянем на основные фичи JPA Buddy, немного обсудим его историю и поговорим о его преимуществах. Надеюсь, он займет достойное место среди любимых инструментов Java-разработчиков, которые пользуютсяJPA, Spring, Liquibase и, конечно же, самой продвинутой Java IDE IntelliJ IDEA.

Откуда растут ноги

Мы создатели CUBA Platform (кстати, не так давно мы переименовали ее в Jmix :)) среды быстрой разработки приложений на Java. Платформа CUBA уникальный продукт. Он состоит из двух частей: фреймворка и инструмента разработки CUBA Studio. Одной из самых полюбившихся частей CUBA Studio стал Entity Designer. В сообществе CUBA более 20 000 разработчиков, и почти все они отмечают, насколько легко и быстро он дает создавать модель данных. Даже для тех, кто никогда не слышал о JPA, такие вещи как создание JPA-сущностей, ограничений модели данных и DDL-скриптов становятся легкой задачей.

В 2016 году CUBA стала open-source проектом. С того момента мы приняли участие в десятках конференций по всему миру, собрали много отзывов и лучше поняли, что именно нужно разработчикам. Они нас часто спрашивали: Можно ли использовать ваш конструктор сущностей без CUBA Platform?. Рады сообщить, что с появлением JPA Buddy мы теперь можем смело ответить да!.

JPA Buddy не требует дополнительных зависимостей это просто инструмент. Вы можете пользоваться им не только на новых, но и на уже существующих проектах, которые используют JPA. Это плагин для IntelliJ IDEA, который помогает вам писать связанный с JPA код, находить и исправлять потенциальные ошибки, проводить рефакторинг и выполнять другие трудоемкие, но достаточно шаблонные операции.

Область применения

Перед тем, как написать первую строчку исходного кода JPA Buddy, мы провели опрос и собрали различные сценарии использования JPA и сопутствующих технологий. Результат оказался достаточно предсказуемым: среднестатистическое приложение в настоящее время это приложение на Spring Boot с Hibernate в качестве реализации ORM, Spring Data JPA в качестве механизма управления данными и Flyway или Liquibase для системы миграции базы данных. Ах да, чуть не забыли про Lombok... В общем, на этом стеке мы и сконцентрировались в первом релизе.

Говоря о предназначении JPA Buddy, мы поставили перед собой следующие цели:

  • Сократить написание шаблонного кода вручную: инструмент должен генерировать код быстрее ручного ввода

  • Не заставлять тратить время на чтение документации: инструмент должен предоставлять интуитивно понятные визуальные конструкторы

  • Оставить свободу выбора: инструмент должен не диктовать какойлибо конкретный стиль написания кода, а поддерживать его различные варианты

  • Выявлять потенциальные проблемы и предлагать решения для наиболее распространенных: инструмент должен предупреждать разработчика о проблемах на этапе написания кода, а не в рантайме

  • Обеспечить обзор проекта с точки зрения данных и удобную навигацию между связанными сущностями

В первом релизе мы смогли реализовать достаточно значительный объем функциональности, охватывающей большинство аспектов разработки модели данных. Хорошая новость для тех, кто использует Liquibase: инструменты для работы с ним уже реализованы и доступны. Не очень хорошая новость для пользователей Flyway: он входит в список наиболее приоритетных фич :)

В долгосрочной перспективе мы собираемся реализовать следующие функции:

  • Аннотации Hibernate: @Where, @NaturalId, @Formula, поисковые аннотации и т. п.

  • Визуальный конструктор запросов

  • Аудит с использованием Envers и Spring Data JPA

  • Генерация модели по существующей схеме базы данных

  • Поддержка Kotlin

В дальнейшем мы учтем и другие функции: поддержка Quarkus и Micronaut, REST API и генерация пользовательского интерфейса для CRUD-операций.

Как видите, впереди еще долгий путь, и мы были бы очень признательны за вашу помощь в расстановке приоритетов разработки не стесняйтесь высказывать свою точку зрения через нашу форму, Twitter или Discord.

Общий обзор

Давайте посмотрим, как выглядит JPA Buddy. После его установки у вас появятся 3 новые панели инструментов: JPA Structure, JPA Palette и JPA Inspector.

JPA Structure

Панель JPA Structure расположена в левом нижнем углу. Она позволяет посмотреть на проект с точки зрения модели данных. С ее помощью можно:

  1. Перемещаться по модели данных. Структура сущностей представлена в иерархическом виде. По ней легко перейти к объектам, ссылающимся на текущий объект, и к тем, на которые ссылается текущий объект. Это особенно полезно для тех, кто только начинает погружаться в существующий проект с большим графом сущностей, или для код-ревьюеров, которые видят часть модели впервые и им нужно в ней быстро разобраться.

  2. Создавать объекты, связанные с данными: сущности, JPA-конвертеры/Hibernate-типы, Spring Data репозитории и Liquibase-скрипты.

  3. Увидеть, для каких сущностей созданы какие репозитории.

  4. Просматривать скрипты Liquibase и их внутреннюю структуру.

  5. Настраивать параметры плагина, такие как соединение с БД, Persistence Units и некоторые другие, которые плагин не обнаружил автоматически.

JPA Palette и JPA Inspector

Панель JPA Palette находится справа вверху, и ее содержимое зависит от контекста. Она доступна только тогда, когда Buddy готов предложить чтото для быстрой генерации кода. Сейчас панель появляется при редактировании следующих объектов: JPA Entity, Spring Data репозиториев и Liquibase-скриптов. Для генерации какого-либо элемента просто выберите нужный вариант в списке и кликните по нему дважды.

JPA Inspector размещается справа внизу, под JPA Palette, и открывается вместе с ним. С помощью JPAPalette можно генерировать новый код, а с помощью JPAInspector редактировать уже существующий. В нем видно, как можно сконфигурировать выбранную часть кода, будь то поле сущности или выражение изLiquibase-скрипта.

Все это будет полезно как для новичков, так и для опытных разработчиков. Первые могут посмотреть на полный список вариантов, выбрать подходящий и сгенерировать корректный код с помощью понятных визуальных конструкторов. Сеньоры, в свою очередь, часто забывают мелочи, которые не используются в повседневной жизни, и Buddy сэкономит несколько секунд драгоценного времени на поиск в документации правильной аннотации или синтаксиса.

Интеграция с Liquibase

Хорошие новости для тех, кто использует Liquibase для управления версиями схемы базы данных: JPA Buddy тесно с ним интегрирован, он позволяет удобно редактировать и создавать Liquibase-скрипты, а также гибко управлять типами атрибутов. Давайте посмотрим, как именно JPA Buddy поможет вам работать с Liquibase.

Во-первых, в JPA Buddy есть визуальный конструктор для редактирования Liquibase-скриптов. Он показывает различные доступные команды плагина в JPAPalette, а панель инструментов JPAInspector дает увидеть настройки, которые можно применить к выбранному выражению.

Во-вторых, JPA Buddy дает определить свои собственные маппинги для сопоставления Java-типов (Конвертеров/Hibernateтипов) и типов, которые должны использоваться для каждой конкретной СУБД. Приведем несколько примеров, когда эта функция будет полезна:

  • Допустим, у вас в сущности есть поле типа byte[]. Что генератор схемы Hibernate, что Liquibase сопоставят ваш массив с довольно экзотическим типом OID. Думаю, многие разработчики предпочли бы использовать bytea вместо предлагаемого по умолчанию типа. Это можно легко сделать, создав маппинг с Java-типа byte[] на БД-тип bytea в настройках проекта в JPA Buddy.

  • Использование JPA-конвертера или кастомного Hibernate-типа вызывает непредсказуемое поведение или даже ошибки в стандартных генераторе схемы Hibernate и генераторе скриптов Liquibase. С помощью JPA Buddy можно явно указать нужный тип, чтобы решить эту проблему.

  • Поля типа String по-умолчанию хранятся как varchar, то есть не поддерживают Юникод. С помощью JPA Buddy легко изменить этот тип на nvarchar, с которым этой проблемы нет.

Все эти случаи обычно решаются с помощью атрибута columnDefinition, однако это решение не будет работать для проектов, где одновременно используется несколько СУБД. JPA Buddy позволяет указать, какой именно маппинг использовать для конкретной СУБД.

Наконец, функция, экономящая наибольшее количество времени наш генератор Liquibase-скриптов. Исходя из нашего опыта (который совпадает с опытом разработчиков принявших участие в ранее упомянутом опросе), есть два основных способа создания Liquibase-скриптов:

  • Написание вручную

  • Создание скриптов путем сравнения двух баз данных: исходной (представляющей фактическое состояние модели) и целевой (с предыдущим состоянием модели)

Для тех, кто предпочитает первый вариант, JPA Buddy включает уже упомянутый ранее конструктор Liquibase-скриптов.

Однако, второй вариант наиболее распространен. Итак, сравниваем две базы данных. Целевую базу данных относительно легко получить, например, можно просто создать дамп базы данных продакшена. Сложности возникают с получением исходной базы данных.

Начнем с небольшой проблемы: может случиться так, что база данных, используемая для разработки на ноутбуке разработчика, не того же типа, что и база данных на продакшене. Это можно исправить, например, запустив MS SQL в Docker на Mac.

Более серьезная проблема состоит втом, что трудно найти чистую исходную базу данных, поскольку она обычно формируется впроцессе разработки генератором схемы Hibernate. Часто это приводит кбольшому количеству мусорных таблиц иатрибутов, которые вконечном итоге появляются вбазе данных продакшена. Чтобы избежать подобного рода мусора, приходится тратить еще час или два напросмотр схемы базы данных перед запуском генерации Liquibase-скриптов.

ВJPA Buddy есть замечательная функция генерации Liquibase-скриптов напрямую, путем сравнения ваших объектов JPA сцелевой базой данных (или snapshotом целевой базы данных). Выможете использовать H2в целях разработки ипо-прежнему генерировать правильные журналы изменений для Oracle, MSSQL или того, что выиспользуете впродакшене. Подобный подход гарантирует, что если увас есть мусор вжурналах изменений, это именно тот мусор, который есть увас висходном коде. Все, что вам нужно, это содержать модель данных вчистоте, итогда миграция неприведет кнежелательным артефактам вбазе данных продакшена.

Еще одна особенность генератора журнала изменений это возможность фильтровать полученные выражения по 3 категориям:

  • содержащие только безопасные операторы, которые не могут дать сбой при обновлении или полностью уронить ваше приложение, например, добавление нового столбца

  • содержащие инструкции, которые могут завершиться ошибкой при обновлении, но не привести к потере данных, например, применение ограничения уникальности

  • содержащие операторы, которые вызовут потерю данных, например, удаление таблицы или столбца

Вы сами решаете, как разделить такие утверждения: поместить их в отдельные скрипты Liquibase или просто выбрать им нужную метку или контекст в редакторе.

Заключение

В этой статье мы посмотрели на первый релиз JPA Buddy. Очевидно, что как и любой новый продукт, JPA Buddy не может полностью избежать проблем и багов, особенно в своем первом релизе. Сейчас мы концентрируемся на устранении замечаний от пользователей, улучшении существующей функциональности, определении наиболее приоритетных функций, которые мы могли упустить из виду, и их реализации.

Говоря прямо, мы хотели бы вдохновить вас стать первыми пользователями JPA Buddy и сформировать сообщество энтузиастов. Установите JPA Buddy, попользуйтесь им и поделитесь своими отзывами с нашей командой разработчиков: это очень поможетнам выбрать правильное направление развития продукта. Также подпишитесь на наш Twitter: там мы показываем, какие еще фичи есть у JPA Buddy и как ими пользоваться. Думаю, вы найдете что-то полезное именно для вас.

Подробнее..

Обзор программы JPoint 2021 воркшопы, Spring, игра вдолгую

24.03.2021 18:04:11 | Автор: admin


Близится новый JPoint, и мы готовы подробно рассказать о его программе. В этом посте мы разделили доклады по тематическим блокам: можно и быстро понять что вообще будет, и узнать конкретику. А во вступлении упомянем отдельные моменты:


  • Пришла весна, то есть самое время поговорить о Spring. О нём будет четыре доклада, в том числе большое двухчастное выступление Евгения Борисова. Для него мы даже продлили JPoint на пятый день получился специальный день Борисова :)
  • Онлайн-формату подходят воркшопы. Поэтому в отдельных случаях можно будет не просто любоваться слайдами: спикер будет выполнять конкретные задачи на практике, объясняя всё происходящее и отвечая на вопросы зрителей.
  • Есть доклады не строго про Java, а про то, как успешно разрабатывать на длинной дистанции (чтобы всё радовало не только на стадии прототипа, а годы спустя): как делать проекты поддерживаемыми, не плодить велосипеды, работать с легаси.
  • Ну и никуда не девается привычное. Знакомые темы: что у Java внутри, тулинг/фреймворки, языковые фичи, JVM-языки. Спикеры, посвятившие теме годы жизни: от технического лида Project Loom Рона Пресслера до главного Spring-адвоката Джоша Лонга. Возможность как следует расспросить спикера после доклада. И уточки для отладки методом утёнка!

Оглавление


Воркшопы
VM/Runtime
Тулинг и фреймворки
Spring
JVM-языки
Люби свою IDE
Жизнь после прототипа




Воркшопы


Воркшоп: Парное программирование, Андрей Солнцев, Антон Кекс


Парное программирование знакомо многим, но вот много ли вы знаете людей, использующих его на постоянной основе? А вот Андрей Солнцев и Антон Кекс действительно практикуют его постоянно и уверены, что подобные практики из мира экстремального программирования помогают работать эффективнее.


Они и раньше об этом говорили, а теперь попробуют показать наглядно. В ходе воркшопа они вдвоём напишут небольшое приложение по TDD (с помощью тестов) и в ходе этого вы лично убедитесь, что с таким подходом разработка идёт быстрее и проще. Или не убедитесь. Интересно будет посмотреть, какую часть аудитории получится убедить.




Воркшоп: Строим Бомбермена с RSocket, Олег Докука, Сергей Целовальников


Олег Докука и Сергей Целовальников на небольшом игровом примере продемонстрируют практический опыт использования RSocket-Java и RSocket-JS.


Кому, как не им, демонстрировать возможности RSocket: Олег лидер этого проекта, а Сергей ведущий разработчик компании Canva, которая одной из первых внедрила его в продакшн. Если у вас есть вопросы по этой технологии у них точно есть ответы.




VM/Runtime


CRIU and Java opportunities and challenges, Christine H Flood


Зачем каждый раз тратить драгоценные секунды на запуск приложения, если можно один раз запустить, сохранить чекпоинт и открывать его уже в запущенном виде, в полной боевой готовности? Причём открывать при необходимости на нескольких машинах сразу?


О том, как использовать Checkpoint Restore в Java, расскажет Кристин Флад из Red Hat, которая работает над языками и рантаймами уже более двадцати лет.




Real World JFR: Experiences building and deploying a continuous profiler at scale, Jean-Philippe Bempel


JDK Flight Recorder позволяет профилировать непрерывно и прямо в продакшне. Но это же не может быть бесплатно, да? Важно понимать, чем придётся пожертвовать и какие будут накладные расходы.


Разобраться в этом поможет Жан-Филипп Бемпель он принимал непосредственное участие в реализации непрерывной профилировки в JFR.




GC optimizations you never knew existed, Igor Henrique Nicacio Braga, Jonathan Oommen


Какой JPoint без докладов про сборщики мусора! Тут выступление для тех, кто уже что-то знает по теме объяснять совсем азы не станут. Но и загружать суперхардкором с первой минуты тоже не станут. Сначала будет подготовительная часть, где Игор Брага и Джонатан Оммен рассмотрят два подхода к GC в виртуальной машине OpenJ9: balanced и gencon.


А вот потом полезут глубже и рассмотрят оптимизации, которые там применяются. Для обычного разработчика эти оптимизации могут быть незаметными, но они способны ощутимо сказываться на производительности поэтому стоит понимать, как они работают и в чём выгода от них для Java-приложений.




Adding generational support to Shenandoah GC, Kelvin Nilsen


И ещё о сборке мусора. На JPoint 2018 о Shenandoah GC рассказывал Алексей Шипилёв (Red Hat), а теперь доклад от совсем другого спикера Келвина Нилсена из Amazon, где тоже работают над этим сборщиком мусора.


Подход Shenandoah позволяет сократить паузы на сборку мусора менее чем до 10 миллисекунд, но за это приходится расплачиваться большим размером хипа (потому что его утилизация оказывается заметно ниже, чем у традиционных GC). А можно ли сделать так, чтобы и волки были сыты, и овцы целы? В Amazon для этого решили добавить поддержку поколений, и в докладе поделятся результатами.




Производительность: Нюансы против очевидностей, Сергей Цыпанов


Производительность тема, где с простым соседствует сложное. Даже в простых с виду частях кода могут обнаруживаться сюрпризы и подводные камни, а то, что казалось очевидным улучшением, может оборачиваться ухудшением производительности. Всё это и будет рассматривать в своём докладе Сергей Цыпанов, в своём профессиональном развитии сосредоточенный как раз на задачах производительности.




Why user-mode threads are (often) the right answer, Ron Pressler


Многопоточное программирование в Java поддерживается с версии 1.0, но за 25 лет в этой части языка почти ничего не поменялось, а вот требования выросли. Серверам требуется работать с сотнями тысяч, и даже миллионами потоков, а стандартное решение в JVM на тредах операционной системы не может так масштабироваться, поэтому Project Loom это одна из самых долгожданных фич языка.


Ранее у нас уже был доклад про Loom от Алана Бейтмана (мы делали расшифровку для Хабра), а теперь и technical lead этого проекта Рон Пресслер рассмотрит разные решения для работы с многопоточностью и подход, который используется в Loom.




Тулинг и фреймворки


Как мы строили высокопроизводительную систему на Akka с нуля: Джентльменский набор и грабли, Кирилл Данилов


Кирилл расскажет про опыт создания платежной системы с использованием Akka от обучения с нуля до построения кластера и интеграции этой платформы с более привычными и удобными в своей нише технологиями, например, Spring Boot, Hazelcast, Kafka.


Будет полезно тем, кто хочет ознакомиться с моделью акторов и с Akka и тем, кому интересны нюансы разработки финансовых систем с большой пропускной способностью.




Jakarta EE 9 and beyond, Ivar Grimstad, Tanja Obradovi


Jakarta EE 9 несет множество изменений, которые затронут большое количество библиотек и фреймворков для Java. Чтобы понять, как эти изменения отразятся на ваших проектах, приходите на доклад Ивана Гримстада и Тани Обрадович.


Ивар Jakarta EE Developer Advocate, а Таня Jakarta EE Program Manager, поэтому вы узнаете о самых важных изменениях и планах на будущее из первых рук.




Чтения из Cassandra внутреннее устройство и производительность, Дмитрий Константинов


В качестве хранилища данных очень часто используется Cassandra, и всем, кто ее использует, будет полезно знать, как она устроена внутри, и от чего зависит её производительность на чтение.


Об этом расскажет системный архитектор и практикующий разработчик из NetCracker Дмитрий Константинов.




The DGS framework by Netflix GraphQL for Spring Boot made easy, Paul Bakker


В Netflix разработали DGS Framework для работы с GraphQL. Он работает поверх graphql-java и позволяет работать с GraphQL, используя привычные модели Spring Boot. И, что приятно, он опенсорсный, стабильный и готов к использованию в продакшне.


Пол Баккер один из авторов DGS. Он расскажет и про GraphQL, и про то, как работать с DGS, и про то, как это используется в Netflix.




Качественный код в тестах не просто приятный бонус, Sebastian Daschner


Для большинства разработчиков тестирование не самая веселая вещь. Однако для сложного реального проекта наличие поддерживаемого и эффективного набора тестов имеет решающее значение для успеха. Доклад покажет с помощью наглядного демо, что удобные интеграционные тесты это не вопрос использования последних фреймворков для тестирования, а скорее правильная разработка тестового кода.


Предыдущие доклады Себастьяна на наших конференциях были англоязычными, но участвуя в российских мероприятиях, он так влился в местное Java-сообщество, что теперь попробует провести доклад на русском!




Why you should upgrade your Java for containers, Ben Evans


Статистика от New Relic говорит, что примерно 62% Java на продакшне в 2021 запущено в контейнерах. Но в большинстве из этих случаев до сих пор используют Java 8 а эта версия подходит для контейнеризации не лучшим образом. Почему? Бен Эванс рассмотрит, в чём проблемы с ней, что улучшилось с Java 11, и как измерить эффективность и расходы.


Хотя в основном речь пойдёт о проблемах, актуальных именно в случае с контейнерами, часть сказанного будет применима и к Java-разработке в целом.




Разошлись как в море корабли: Кафка без Zookeeper, Виктор Гамов


Совсем скоро придет тот день, о котором грезили Kafka-опсы и Apache Kafka больше не будет нуждаться в ZooKeeper! С KIP-500 в Kafka будет доступен свой встроенный механизм консенсуса (на основе алгоритма Raft), полностью удалив зависимость от ZooKeeper. Начиная с Apache Kafka 2.8.0. вы сможете получить доступ к новому коду и разрабатывать свои приложения для Kafka без ZooKeeper.


В конечном счете, удаление ZooKeeper упрощает общее проектирование инфраструктуры и рабочие процессы вокруг Кафки. В этом докладе Виктор сделает краткий обзор того, какие ограничения Zookeeper накладывал на архитектуру Кафки и приложений, что будет изменено, а также текущий статус удаления Zookeeper.




Spring


Spring Data Рostроитель (Spark it!), Евгений Борисов


Товарищ, знай! Чтоб использовать Spark,
Scala тебе не друг и не враг.
Впрочем, и Spark ты можешь не знать,
Spring-data-spark-starter лишь надо создать!


Этот доклад не про Spark и не про Big Data. Его скорее можно отнести к серии потрошителей и построителей. Что будем строить и параллельно потрошить сегодня? Spring Data. Она незаметно просочилась в большинство проектов, подкупая своей простотой и удобным стандартом, который избавляет нас от необходимости каждый раз изучать новый синтаксис и подходы разных механизмов работы с данными.


Хотите разобраться, как Spring Data творит свою магию? Давайте попробуем написать свой аналог. Для чего ещё не написана Spring Data? JPA, Mongo, Cassandra, Elastic, Neo4j и остальные популярные движки уже имеют свой стартер для Spring Data, а вот Spark, как-то забыли. Давайте заодно исправим эту несправедливость. Не факт, что получится что-то полезное, но как работает Spring Data мы точно поймём.




Spring Cloud в эру Kubernetes, Алексей Нестеров


Когда-то давно, много JavaScript-фреймворков назад, когда микросервисы еще были монолитами, в мире существовало много разных инструментов для разработки Cloud Native приложений. Spring Cloud был одним из главных в реалиях Spring и объединял в себе целый набор полезных проектов от Netflix, команды Spring и многих других вендоров.


Казалось бы, в наши дни, когда весь мир захвачен Kubernetes и он уже давно стал универсальным решением любой проблемы, важность Spring Cloud должна неизбежно сойти на нет. Но не все так просто, и в этом докладе Алексей покажет, какие компоненты Spring Cloud могут быть полезны в Kubernetes, чем эти два проекта друг друга дополняют, в каких аспектах пересекаются, ну и самое главное, постарается ответить на вопрос в чем же ценность Spring Cloud в эру Kubernetes?




Reactive Spring, Josh Long


Джош Лонг расскажет про фичи Spring Framework 5.0 для реактивного программирования: Spring WebFlux, Spring Data Kay, Spring Security 5.0, Spring Boot 2.0, Spring Cloud Finchley и это только часть!


Может показаться многовато для одного доклада, но мы-то знаем, что Джош Spring Developer Advocate с 2010 года. Уж кто-кто, а он-то знает, как рассказать всё быстро и по делу.




Inner loop development with Spring Boot on Kubernetes, David Syer


Мы живем во время облачных технологий и чтобы эффективнее перейти от принципа works on my machine к works on my/dev cluster нужен набор инструментов для автоматизация загрузки кода на лету.
Доклад Дэвида Сайера будет про то, как и с помощью каких инструментов Spring Boot и Kubernetes построить этот процесс удобно.
Ускорение первой фазы доставки это тот DevOps, который нужен разработчикам, поэтому всем, кто живет в k8s или хотя бы делает системы из нескольких компонентов этот доклад пригодится.




Люби свою IDE


IntelliJ productivity tips The secrets of the fastest developers on Earth, Victor Rentea


Если впервые ведёшь автомобиль без инструктора и навигатора, не очень получается думать о самом эффективном маршруте с учётом пробок: справиться бы с тем, что видишь вокруг прямо сейчас. С IDE похоже: поначалу требуется освоиться с главным, но есть ещё скрытые возможности, до которых можно дорасти позже.


Виктор Рента покажет много трюков для работы с IntelliJ IDEA, которые помогут писать код быстрее, экспериментировать больше и делать откат результатов неудачных экспериментов проще.




Многоступенчатые рефакторинги в IntelliJ IDEA, Анна Козлова


В IntelliJ IDEA есть ограниченное количество основных рефакторингов: Rename, Move, Inline, Extract. Пользователи часто просят добавить еще, но чаще всего это можно сделать комбинацией уже существующих, просто это не всегда очевидно.


На JPoint 2021 вы сможете получить практические рекомендации по рефакторингу от человека, который разрабатывает рефакторинги: о самых важных приемах расскажет коммитер 1 в IntelliJ IDEA Community Edition Анна Козлова.




С какими языками дружат IDE?, Петр Громов


Разработчики всё чаще выбирают языки с выразительным и кратким синтаксисом, совсем не задумываясь на тем, как долго их код будет компилироваться, и сможет ли IDE помочь им с рефакторингом. В докладе Петра Громова будут интересные идеи о сложности современных языков программирования с точки зрения разработчиков IDE.


Рекомендуем всем, кому интересны механизмы IDE, языки, парсеры, DSL и сложные синтаксические конструкции в современных языках программирования.




Java и JVM-языки


Type inference: Friend or foe?, Venkat Subramaniam


Не все могут объяснять так, как это делает Венкат Субраманиам, поэтому мы любим приглашать его на конференции.


На JPoint 2021 он выступит с докладом про type inference. Хотя тема сама по себе не новая, нюансов в ней хватает, а развитие языков делает её лишь более актуальной (вспоминается доклад Романа Елизарова с TechTrain, где он рассматривал, как ситуация с типами и их выводом менялась со временем). Так что стоит лучше понять, в чём вывод типов помогает, а в чём мешает для этого и рекомендуем сходить на этот доклад.




Babashka: A native Clojure interpreter for scripting, Michiel Borkent


Babashka интерпретатор Clojure для скриптов. Он мгновенно запускается, делая Clojure актуальной заменой для bash. У Babashka из коробки есть набор полезных библиотек, дающих доступ из командной строки к большому количеству фич Clojure и JVM. Сам интерпретатор написан на Clojure и скомпилирован с помощью GraalVM Native Image. В докладе работу с ним наглядно покажут с помощью демо.




Getting the most from modern Java, Simon Ritter


Недавно вышла JDK 16, и это значит, что мы получили 8 (прописью: ВОСЕМЬ) версий Java менее чем за четыре года. Разработчики теперь получают фичи быстрее, чем когда-либо в истории языка.


Так что теперь попросту уследить бы за всем происходящим. Если вы до сих пор сидите на Java 8, на что из появившегося позже стоит обратить внимание и чем это вам будет полезно? В этом поможет доклад Саймона Риттера, где он поговорит о некоторых нововведениях JDK 12-15 и о том, когда их исследовать, а когда нет:


  • Switch expressions (JDK 12);
  • Text blocks (JDK 13);
  • Records (JDK 14);
  • Pattern matching for instanceof (JDK 14);
  • Sealed classes and changes to Records (JDK 15).


Про Scala 3, Олег Нижников


Обзор языка Scala 3 и грядущей работы по переходу. Обсудим, в какую сторону двигается язык, откуда черпает вдохновение, и пройдёмся по фичам.




Java Records for the intrigued, Piotr Przybyl


В Java 14 появились в превью-статусе Records, а с Java 16 они стали стандартной фичей. Для многих это было поводом сказать что-то вроде Lombok мёртв или не нужна больше кодогенерация JavaBeans. Так ли это на самом деле? Что можно сделать с помощью Records, а чего нельзя? Что насчёт рефлексии и сериализации? Разберём в этом докладе.




Жизнь после прототипа


Восстанавливаем утраченную экспертизу по сервису, Анна Абрамова


Представьте ситуацию: вы приходите на работу в компанию, где до вас уже написано многое на Java и вспомогательных технологиях. У вас горят глаза, чешутся руки и вы хотите работать. И тут вас кидают в море легаси, где вместо документации крошки на клавиатуре от вашего предшественника.


Анна Абрамова на примере вымышленной системы расскажет, какими методами можно восстановить сакральные знания.




Что такое Работающий Продукт и как его делать, Антон Кекс


Антон Кекс регулярно сталкивается с проектами, у которых проблемы даже с элементарным запуском. Поэтому целый доклад на JPoint он посвятит тому, как делать на самом деле работающие продукты, которыми можно пользоваться и легко поддерживать как создателю, так и его коллегам.


Если ваша точка зрения не совпадет можно будет всё обсудить с Антоном в дискуссионной зоне. Вероятно, там будет жарко.




Enum в API коварство иллюзорной простоты, Илья Сазонов и Фёдор Сазонов


Вы уверены, что если добавить один маленький enum в API, то ничего страшного не произойдет? Или наоборот уверены, что так делать не стоит, но никто вас не слушает?
Рекомендуем вам доклад Ильи и Федора Сазоновых, пропитанный тяжелой болью по поводу бесконечных обновлений контрактов микросервисов.
Обычно подобные темы не выходят за пределы локального холивара в курилке, но нельзя же вечно добавлять новые значения в enum?




Dismantling technical debt and hubris, Shelley Lambert


Многие разработчики любят строить велосипеды, потому что свой велосипед он же надежнее, быстрее и удобнее, чем всё остальное. А потом все эти велосипеды складываются в один большой технический долг, с которым нужно что-то делать.
Шелли Ламберт научит вас не писать собственные решения для всего подряд, а правильно выбирать существующие.




Подводя итог


Надеемся, по программе ясность появилась, но напоследок подчеркнём, что онлайн-конференция это не только слушать доклады. Это ещё и:
Вопросы спикерам в чатах и видеосозвонах
Общение зрителей (на нашей виртуальной площадке можно подойти к другому зрителю и увидеть его по видеосвязи)
Виртуальные стенды партнёров с различными активностями


Напоминаем, поучаствовать во всём этом можно будет с 13 по 17 апреля в онлайне. Вся дополнительная информация и билеты на сайте.

Подробнее..

Hibernate и Spring Boot кто отвечает за имена таблиц?

28.04.2021 16:12:49 | Автор: admin

Когда мы добавляем зависимость в проект, мы подписываем контракт. Зачастую, многие условия в нем написаны мелким шрифтом. В этой статье мы рассмотрим кое-что, что легко пропустить при подписании трехстороннего контракта между вами, Hibernate и Spring Boot. Речь пойдет о стратегиях именования.

Значения по умолчанию в JPA

Главное правило для значений по умолчанию: они должны быть интуитивно понятными. Давайте проверим, следует ли этому правилу обычное приложение на Spring Boot с конфигурацией по умолчанию, Hibernate в качестве реализации JPA и PostgreSQL в качестве БД. Допустим, у нас есть сущность PetType. Давайте угадаем, как будет называться ее таблица в базе данных.

Первый пример:

@Entitypublic class PetType {    // fields omitted}

Я бы предположил, что именем таблицы станет имя класса, то есть PetType. Однако, после запуска приложения оказалось, что имя таблицы на самом деле pet_type.

Явно зададим имя с помощью @Table:

@Entity@Table(name = "PetType")public class PetType {    // fields omitted}

В этот раз имя точно должно быть PetType. Запустим приложение Таблица снова называется pet_type!

Тогда попробуем заключить название таблицы в кавычки. Таким образом, должно сохраниться не только имя, но и регистр:

@Entity@Table(name = "\"PetType\"")public class PetType {  // fields omitted}

И опять наши ожидания не оправдались, имя снова "pet_type", но теперь в кавычках!

Стратегии именования Hibernate

На запрос имя таблицы поумолчанию для JPA-сущностей Google выдает следующий результат (англ.):

По умолчанию, имя таблицы в JPA это имя класса (без пакета) с заглавной буквы. Каждый атрибут класса хранится в столбце таблицы.

Именно это мы ожидали увидеть в первом примере, не так ли? Очевидно, что-то нарушает стандарт.

Углубимся в Hibernate. Согласно документации (англ.), в Hibernate есть два интерфейса, отвечающих за именование таблиц, столбцов и пр.: ImplicitNamingStrategy и PhysicalNamingStrategy.

ImplicitNamingStrategy отвечает за генерацию имен для всех объектов, которые не были явно названы разработчиком: имя сущности, имя таблицы, имя столбца, индекса, внешнего ключа и т.д.. Получившееся имя называется логическим, оно используется внутри Hibernate для идентификации объекта. Это не то имя, которое будет использовано в базе данных.

PhysicalNamingStrategy создает подлинное физическое имя на основе логического имени объекта JPA. Именно физическое имя используется в базе данных. Фактически, это означает, что с помощью Hibernate нельзя напрямую указать физическое имя объекта в БД, можно указать только логическое. Чтобы лучше понять, как это все работает, посмотрите на схему ниже.

По умолчанию, в Hibernate используются следующие реализации этих интерфейсов: ImplicitNamingStrategyJpaCompliantImpl и PhysicalNamingStrategyStandardImpl. Первый генерирует логические имена в соответствии со спецификацией JPA, а второй использует их как физические имена без каких-либо изменений. Лучше всего это описано в документации:

JPA определяет четкие правила автоматического именования. Если вам важна независимость от конкретной реализации JPA, или если вы хотите придерживаться определенных в JPA правил именования, используйте ImplicitNamingStrategyJpaCompliantImpl (стратегия по умолчанию). Кроме того, в JPA нет разделения между логическим и физическим именем. Согласно спецификации JPA, логическое имя это и есть физическое имя. Если вам важна независимость от реализации JPA, не переопределяйте PhysicalNamingStrategy.

Однако наше приложение ведет себя по-другому. И вот почему. Spring Boot переопределяет реализации Hibernate по умолчанию для обоих интерфейсов и вместо них использует SpringImplicitNamingStrategy и SpringPhysicalNamingStrategy.

SpringImplicitNamingStrategy фактически копирует поведение ImplicitNamingStrategyJpaCompliantImpl, есть только незначительное различие в именовании join таблиц. Значит, дело в SpringPhysicalNamingStrategy. В документации (англ.) указано следующее:

По умолчанию, в Spring Boot используется SpringPhysicalNamingStrategy в качестве физической стратегии именования. Эта реализация использует те же правила именования, что и Hibernate 4:
1. Все точки заменяются символами подчеркивания.
2. Заглавные буквы CamelCase приводятся к нижнему регистру, и между ними добавляются символы подчеркивания. Кроме того, все имена таблиц генерируются в нижнем регистре. Например, сущности TelephoneNumber соответствует таблица с именем telephone_number.

По сути, Spring Boot всегда преобразовывает camelCase и PascalCase в snake_case. Более того, использование чего-либо помимо snake_case вообще невозможно. Я бы не стал использовать camelCase или PascalCase для именования объектов базы данных, но иногда у нас нет выбора. Если ваше приложение на Spring Boot работает со сторонней базой данных, где используется PascalCase или camelCase, конфигурация Spring Boot по умолчанию для вас не подойдет. Обязательно убедитесь, что используемая PhysicalNamingStrategy совместима с именами в базе данных.

Получается, Hibernate соответствует спецификации JPA, а Spring Boot нет. Можно подумать, что это ошибка. Однако Spring Boot фреймворк, в котором множество решений уже принято за разработчика, в этом и есть его ценность. Другими словами, он имеет полное право по-своему реализовывать стандарты и спецификации тех технологий, которые он использует. Для разработчика это означает следующее:

  • Конечное поведение всегда определяется конкретной реализацией и может отличаться от спецификации.

  • Если что-то и работает изкоробки, всегда нужно разбираться, что именно оно делает под капотом.

  • Поведение по умолчанию может измениться с обновлением версии библиотеки, что может привести к непредсказуемым побочным эффектам;

Заключение

Магия конфигураций изкоробки это отлично, но может привести к неожиданному поведению. Один из способов избежать подобных проблем явно задавать все значения и не полагаться на автогенерацию. Для именования объектов JPA рекомендации следующие:

  1. Всегда называйте свои объекты JPA явно, чтобы никакая автоматическая стратегия именования не повлияла на ваш код.

  2. Используйте snake_case для имен столбцов, таблиц, индексов и других объектов JPA, чтобы все реализации PhysicalNamingStrategy никак их не преобразовывали.

  3. Если нельзя использовать snake_case (например, при использовании сторонней базы данных), используйте PhysicalNamingStrategyStandardImpl в качестве PhysicalNamingStrategy.

Еще один плюс явного именования объектов JPA вы никогда случайно не переименуете таблицу или атрибут в самой базе при рефакторинге Java-модели. Для этого придется менять имя в @Table или @Column.

Однако, введя эти правила мы просто переложили ответственность на разработчиков. Теперь нам надо следить, чтобы вся команда им следовала. К счастью, этот процесс можно автоматизировать с помощью инструментов разработки.

Если вы пользуетесь IntelliJ IDEA, попробуйте JPA Buddy плагин, который упрощает работу с JPA, Hibernate, Spring Data JPA, Liquibase и подобными технологиями. В настройках JPA Buddy есть специальная секция, в которой можно установить шаблоны для имен сущностей, атрибутов и пр.. Эти шаблоны применяются каждый раз, когда разработчики создают сущность или атрибут:

По задумке, настройки JPA Buddy хранятся в Git, таким образом все разработчики используют одни и те же шаблоны и следуют одним и тем же правилам.

Подробнее..

Перевод Okta безопасный доступ к приложениям на Angular Spring Boot

30.04.2021 20:15:00 | Автор: admin

Перевод статьи подготовлен в рамках набора учащихся на курс Разработчик на Spring Framework.

Приглашаем также всех желающих на открытый демо-урок Конфигурация Spring-приложений. На занятии рассмотрим, как можно конфигурировать Spring Boot приложения с помощью свойств:
- properties vs. YAML
- @Value + SpEL
- @ConfigurationProperties
- Externalized конфигурация.
Присоединяйтесь!


Разрабатывая корпоративные веб-приложения, каждый из нас рано или поздно сталкивается с необходимостью обеспечить их безопасность и защитить их ресурсы от несанкционированного доступа. Нужно определить роли для управления доступом, которые будут назначаться пользователям или группам и наделять их полномочиями выполнять те или иные операции в приложении.

Okta это облачный сервис, который позволяет управлять удостоверениями и доступом. Согласно документации Okta, это сервис корпоративного уровня, который создан для управления удостоверениями в облачной среде, но при этом совместим и со многими локальными приложениями. С его помощью ИТ-специалисты могут управлять доступом сотрудников к любому приложению или устройству. Сервис развернут на надежной и защищенной облачной платформе, которая обладает широкими возможностями аудита и тесно интегрируется с локальными приложениями, службами каталогов и системами управления удостоверениями. Подробную информацию о том, как Okta интегрируется с приложениями, можно получить по этой ссылке.

Для авторизации пользователей в Okta используется протокол OAuth2. Подробнее о протоколе OAuth2 и стандарте Open ID Connect (OIDC) можно почитать в блоге Okta.

В этой статье мы рассмотрим демонстрационное приложение Контакты и настройку разрешений на просмотр, создание, редактирование и удаление контактов. Это вторая часть цикла статей о приложении Контакты, посвященная его защите с помощью Okta. О базовом приложении подробно написано в первой статье цикла: Разработка веб-приложения на Spring Boot + Angular.

Полный код, фрагменты которого мы рассматриваем в этой статье, доступен на GitHub.

В итоге наше приложение будет иметь следующую архитектуру:

Компонентная архитектура приложения Контакты, использующего протокол OAuthКомпонентная архитектура приложения Контакты, использующего протокол OAuth

О том, как контейнеризировать это приложение и развернуть его в кластере Kubernetes, можно узнать по ссылкам:

Kubernetes: развертывание приложения на Angular + Java/ Spring Boot в Google Kubernetes Engine (GKE)

Kubernetes: развертывание приложения на Angular + Spring Boot в облаке Microsoft Azure

Конфигурация на портале разработчика Okta

Для начала нам нужно настроить учетную запись Okta и добавить приложение в Okta. Здесь можно создать учетную запись разработчика бесплатно.

После создания учетной записи мы можем добавить наше приложение в консоль администрирования Okta. Для этого выберем вкладку Applications (Приложения) и щелкнем Add Application (Добавить приложение).

Выберем в качестве платформы Single Page App (Одностраничное приложение) и настроим его так, как показано на скриншоте ниже. Здесь мы отметим только опцию Authorization code (Код авторизации), поскольку нам не нужно, чтобы токен возвращался непосредственно в URL-адресе (о связанных с этим рисках безопасности написано в этой статье в блоге Okta).

В нашем случае требуется два перенаправления входа: во-первых, когда пользователь входит в приложение через пользовательский интерфейс, куда сервер авторизации Okta должен перенаправлять пользователя с указанием кода авторизации, а во-вторых когда пользователь напрямую вызывает открытые API серверной части. Также выберем здесь PKCE.

OAuth предлагает различные потоки авторизации (authorization code flows) выбор конкретного потока зависит от сценария использования приложения. О том, какой поток OAuth выбрать, можно прочитать в этой статье на Medium или в документации Okta. Пользовательский интерфейс нашего демонстрационного приложения представляет собой одностраничное приложение на Angular, поэтому выберем неявный поток (implicit flow) с дополнительной проверкой для обмена кодом (Proof Key Code Exchange, PKCE).

Авторизация запросов через сервер авторизации

Для авторизации всех входящих запросов к приложению нам понадобится сервер авторизации. В нашем примере используется сервер авторизации, который Okta предоставляет по умолчанию. Если вы захотите написать собственный сервер для авторизации запросов, это тоже возможно; тогда нужно будет указать в Okta ссылку на его конечную точку.

Чтобы увидеть сервер авторизации на портале Okta, нужно выбрать пункт меню, показанный ниже на скриншоте.

Добавление заявлений о группах (groups claims) в приложение Контакты

Для демонстрации создадим группу Admin. Администратор будет обладать правами на создание/редактирование/удаление.

О том, как создать группу и идентифицировать ее с помощью токена доступа, можно узнать в блоге Okta. В официальном блоге Okta описана автономная конфигурация приложения на Spring Boot в качестве веб-проекта Okta. В нашем случае менять тип проекта не нужно. Мы просто создадим группы и включим заявления о группах в токен доступа, выдаваемый сервером авторизации.

На скриншотах ниже показано, как мы создали группу, связали ее с нашим приложением и включили заявление о группах в токен доступа.

Управление группамиУправление группамиНазначение групп/пользователей для приложенияНазначение групп/пользователей для приложенияДобавление заявления о группах в токен доступа, выдаваемый сервером авторизацииДобавление заявления о группах в токен доступа, выдаваемый сервером авторизации

Настроив проект через консоль администрирования Okta описанным выше способом, можно приступать к его интеграции с приложением Контакты для защиты доступа к приложению.

Настройка Okta в клиентской части приложения

Для защиты клиентской части приложения Контакты воспользуемся SDK-библиотекой Okta для Angular. Мы будем авторизовывать пользователя, перенаправляя его на конечную точку авторизации, настроенную для нашей организации в Okta. Библиотеку можно установить с помощью npm:

npm install @okta/okta-angular --save

Чтобы реализовать этот промежуточный слой, после установки нужно будет указать значения из клиента OIDC, полученные на предыдущем этапе. Также понадобится URL-адрес организации в Okta его можно узнать на домашней странице консоли разработчика Okta.

В файле app.module.ts создадим объект конфигурации и в нем установим true для параметра PKCE.

const oktaConfig = {issuer: 'https://{yourOktaDomain}/oauth2/default',redirectUri: window.location.origin + '/implicit/callback',clientId: 'your clientId',pkce: true};

Этот объект нужно добавить в раздел providers. Также импортируем OktaAuthModule:

import { OktaAuthModule, OktaCallbackComponent } from '@okta/okta-angular';import {OKTA_CONFIG} from '@okta/okta-angular';....imports:[...OktaAuthModule...]providers: [...{ provide: OKTA_CONFIG, useValue: oktaConfig }...]

В модуле обработки маршрутов приложения зададим защиту маршрута, воспользовавшись Route Guard из Angular. Вот фрагмент кода из app-routing-module.ts:

import { OktaCallbackComponent } from '@okta/okta-angular';...const routes: Routes = [{ path: 'contact-list',canActivate: [ OktaAuthGuard ],component: ContactListComponent },{ path: 'contact',canActivate: [ OktaAuthGuard, AdminGuard ],component: EditContactComponent },{path: 'implicit/callback',component: OktaCallbackComponent},{ path: '',redirectTo: 'contact-list',pathMatch: 'full'},];

Здесь мы защищаем просмотр контактов с помощью AuthGuard, а создание, обновление, удаление контактов с помощью AdminGuard и OktaAuthGuard.

Метод canActivate в OktaAuthGuard используется для проверки того, прошел ли пользователь процедуру аутентификации. Если нет, он перенаправляется на страницу входа Okta; если да, мы позволяем ему просматривать страницу, на которую ведет маршрут.

async canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {this.authenticated = await this.okta.isAuthenticated();if (this.authenticated) { return true; }// Redirect to login flow.this.oktaAuth.loginRedirect();return false;}

Аналогичным образом метод canActivate в AdminGuard проверяет, принадлежат ли вошедшие в систему пользователи к группе Admin; если нет, запрос на доступ к маршруту отклоняется и выводится предупреждение.

async canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {this.user = await this.okta.getUser();const result = this.user.groups.find((group) => group === 'Admin');if (result) {return true;} else {alert('User is not authorized to perform this operation');return false; }}

Ниже показана последовательность операций, которые выполняются, когда пользователь пытается обратиться к маршруту /contact-list для просмотра списка контактов.

Последовательность операций при выводе контактов на экранПоследовательность операций при выводе контактов на экран

Ниже представлена последовательность операций, демонстрирующая принцип работы PKCE. В случае одностраничного приложения, если токен возвращается непосредственно как часть URL-адреса перенаправления, любое расширение браузера может получить доступ к токену еще до того, как его увидит приложение. Это представляет потенциальную угрозу безопасности. Для снижения этого риска в PKCE вычисляется хэш SHA256 от случайной строки верификатора кода (code verifier), и этот хэш включается в запрос кода доступа как контрольное значение (code challenge). Когда поступает запрос на обмен токена доступа на код доступа, сервер авторизации может снова вычислить хэш SHA256 от верификатора кода и сопоставить результат с сохраненным контрольным значением.

Библиотека для Angular производит все эти операции за кадром: вычисляет хэш от верификатора кода с помощью алгоритма SHA256 и обменивает токен на код доступа, сопоставляя верификатор кода с контрольным значением.

Неявное разрешение на доступ (implicit grant) с использованием PKCE в приложении КонтактыНеявное разрешение на доступ (implicit grant) с использованием PKCE в приложении Контакты

Настройка Okta в серверной части приложения

Для того чтобы приложение Spring Boot поддерживало Okta, нужно установить следующие зависимости:

<dependency><groupId>com.okta.spring</groupId><artifactId>okta-spring-boot-starter</artifactId><version>1.2.1</version><exclusions><exclusion><groupId>org.springframework.security.oauth</groupId><artifactId>spring-security-oauth2</artifactId></exclusion></exclusions></dependency><dependency><groupId>org.springframework.security.oauth</groupId><artifactId>spring-security-oauth2</artifactId><version>2.4.0.RELEASE</version></dependency>

Spring Security OAuth2 и Okta Spring Boot Starter следует добавить в classpath, тогда Spring настроит поддержку Okta во время запуска.

Укажем следующие значения конфигурации для настройки и подключения Spring к приложению Okta:

okta.oauth2.client-id=<clientId>okta.oauth2.issuer=https://{yourOktaDomain}/oauth2/defaultokta.oauth2.groups-claim=groups

В классе SpringSecurity нужно указать, что приложение Spring Boot является сервером ресурсов:

@EnableWebSecurity@EnableGlobalMethodSecurity(prePostEnabled = true)@Profile("dev")@Slf4jpublic class SecurityDevConfiguration extends WebSecurityConfigurerAdapter {@Overrideprotected void configure(HttpSecurity http) throws Exception{http.cors().and().csrf().disable();http.cors().configurationSource(request -> new CorsConfiguration(corsConfiguratione()));// http.authorizeRequests().antMatchers(HttpMethod.OPTIONS, "/**").permitAll()// .and().http.antMatcher("/**").authorizeRequests().antMatchers(HttpMethod.OPTIONS, "/**").permitAll().antMatchers("/").permitAll().anyRequest().authenticated();http.oauth2ResourceServer();}

При такой конфигурации конечные точки нашего приложения защищены. Если попробовать обратиться к конечной точке /contacts по адресу http://localhost:8080/api/contacts, будет возвращена ошибка 401, поскольку запрос не пройдет через фильтр аутентификации.

Для того чтобы предоставить права на создание, обновление и удаление контактов только администратору, нужно включить защиту методов в классе SpringSecurityConfig при помощи следующей аннотации:

@EnableGlobalMethodSecurity(prePostEnabled = true)

На конечных точках, которые мы хотим защитить, можно выполнять проверку ролей с помощью PreAuthorize следующим образом:

@PreAuthorize("hasAuthority('Admin')")public Contact saveContact(@RequestBody Contact contact,@AuthenticationPrincipal Principal userInfo) {

Для получения сведений о вошедшем в систему пользователе можно использовать объект Principal (@AuthenticationPrincipal).

Защита доступа к API из клиентской части приложения с помощью токена доступа

Теперь Okta защищает и клиентскую, и серверную часть нашего приложения. Когда клиентская часть направляет запрос к API, она должна передавать токен доступа в заголовке авторизации. В Angular для этого можно использовать перехватчик HttpInterceptor. В классе перехватчика авторизации можно задать токен доступа для любого HTTP-запроса следующим образом:

private async handleAccess(request: HttpRequest<any>, next: HttpHandler): Promise<HttpEvent<any>> {const accessToken = await this.oktaAuth.getAccessToken();if ( accessToken) {request = request.clone({setHeaders: {Authorization: 'Bearer ' + accessToken}});}return next.handle(request).toPromise();}}

Прямой доступ к API приложения через внешний сервер API

Если все настроено правильно, пользовательский интерфейс нашего приложения сможет получать доступ к API серверной части. В корпоративных приложениях часто присутствует несколько микросервисов, к которым обращается пользовательский интерфейс приложения, а также ряд микросервисов, доступ к которым открыт непосредственно для других приложений или пользователей. Так как наше приложение настроено как одностраничное, в настоящее время оно поддерживает доступ только из JavaScript-кода. Чтобы открыть доступ к микросервисам как к API для других потребителей API, нужно создать в Okta серверное приложение с типом веб-приложение, а затем создать микросервисы как одностраничные приложения и разрешить единый вход для доступа к ним (технически мы имеем дело с двумя разными приложениями в Okta).

Я разработал небольшое решение, позволяющее обойти эту проблему. Мы по-прежнему будем использовать неявный поток с PKCE, но на этот раз не станем перенаправлять пользователя на страницу входа (при направлении запроса к API войти в Okta в ручном режиме невозможно, поскольку в этом случае пользователем будет пользователь API). Вместо этого будем следовать следующему алгоритму.

Последовательность операций при прямом доступе к серверному APIПоследовательность операций при прямом доступе к серверному API

Я создал сервер API, тоесть микросервис-обертку, предоставляющий список API, к которым мы хотим открыть доступ как к серверным API.

Эта обертка выдает токены доступа с указанием конечной точки входа, а затем вызывает нужный API, используя токен доступа.

Она выступает в роли прокси-сервера для основного серверного API нашего приложения и открывает доступ к необходимым сервисам. В ней используется библиотека Spring Cloud OpenFeign, предназначенная для написания декларативных REST-клиентов. Такая обертка представляет собой очень простой способ создания клиентов для веб-сервисов. Она позволяет сократить количество кода при написании потребителей веб-сервисов на базе REST, а также поддерживает перехватчики, позволяющие реализовать любые промежуточные операции, которые должны выполняться до направления запроса к API. В нашем случае мы будем использовать перехватчик для задания токена доступа и распространения прав доступа пользователей. Дополнительные сведения о Feign доступны по этой ссылке.

При правильной настройке все конечные точки нашего приложения, а также компоненты клиентской части приложения будут надежно защищены. Доступ к нему будет открыт только для авторизованных пользователей. О том, как контейнеризировать это приложение и развернуть его в кластере Kubernetes, можно прочитать по ссылкам:

Kubernetes: развертывание приложения на Angular + Java/ Spring Boot в Google Kubernetes Engine (GKE)

Kubernetes: развертывание приложения на Angular + Spring Boot в облаке Microsoft Azure


Узнать подробнее о курсе Разработчик на Spring Framework

Смотреть вебинар Конфигурация Spring-приложений

Подробнее..

Как подружить Redis Cluster c Testcontainers?

20.06.2021 12:09:43 | Автор: admin
В 26-м выпуске NP-полного подкаста я рассказывал, что начал переводить один из своих сервисов из Redis Sentinel на Redis Cluster. На этой неделе я захотел потестировать данный код, и, конечно же, выбрал Testcontainers для этого. К сожалению, Redis Cluster в тестовых контейнерах не завелся из коробки, и мне пришлось вставить несколько костылей. О них и пойдет речь далее.



Вводные


Сначала я бы хотел описать все вводные, а потом рассказать про костыли. Мой проект построен на Spring Boot. Для взаимодействия с редисом используется Lettuce клиент. Для тестирования testcontainers-java с JUnit. Версия обоих редисов 6. В общем, всё типичное, нет ничего особенного с точки зрения стека.

Если кто-то еще не знаком с testcontainers, то пара слов о них. Это библиотека для интеграционного тестирования. Она построена на другой библиотеке https://github.com/docker-java/docker-java. Тестконтейнеры, по сути говоря, помогают быстро и просто запускать контейнеры с разными зависимостями в ваших интеграционных тестах. Обычно это базы данных, очереди и другие сложные системы. Некоторые люди используют testcontainers и для запуска своих сервисов, от которых зависит тестируемое приложение (чтобы тестировать микросервисное взаимодействие).

Про Redis Cluster


Redis Cluster это одна из нескольких реализаций распределнного режима Редиса. К сожалению, в Редисе нет единого правильного способа, как масштабировать базу. Есть Sentinel, есть Redis Cluster, а еще ребята активно разрабатывают RedisRaft распредеделенный редис на базе протокола консенсуса Raft (у них там своя реализация, которая, как они сами заявляют, не совсем каноничный Рафт, но конкретно для Redis самое то).

В целом, про Redis Cluster есть две замечательных статьи на официальном сайте https://redis.io/topics/cluster-tutorial и https://redis.io/topics/cluster-spec. Большинство деталей описано там.

Для использования Redis Cluster в testcontainers важно знать несколько вещей из документации. Во-первых, Redis Cluster использует gossip протокол поэтому каждый узел кластера имеет TCP-соединение со всеми другими узлами. Поэтому, между нодами должна быть сетевая связность, даже в тестах.

Вторая важная штука, которую надо знать при тестировании это наличие в Redis Cluster bootstrap узлов для конфигурации. То есть, вы в настройках можете задать лишь подмножество узлов, которые будут использоваться для старта приложения. В последствие, Redis клиент сам получит Топологию кластера через взаимодействие с Редисом. Исходя из этого, получается вторая особенность тестируемое приложение должно иметь сетевую связность с теми Redis URI, которые будут аннонсированы со стороны редис кластера (кстати, эти адреса можно сконфигурировать через cluster-announce-port и cluster-announce-ip).

Про костыли с Redis Cluster и testcontainers


Для тестирования я выбрал довольно популярный docker-образ https://github.com/Grokzen/docker-redis-cluster. Он не подходит для продакшена, но очень прост в использовании в тестах. Особенность этого образа все Редисы (а их 6 штук, по умолчанию 3 мастера и 3 слейва) будут подняты в рамках одного контейнера. Поэтому, мы автоматически получаем сетевую связность между узлами кластера из коробки. Осталось решить вторую из двух проблем, связанную с получением приложением топологии кластера.

Я не хотел собирать свой docker-образ, а выбранный мной image не предоставляет возможности задавать настройки cluster-announce-port и cluster-announce-ip. Поэтому, если ничего не делать дополнительно, при запуске тестов вы увидите примерно такие ошибки:

Unable to connect to [172.17.0.3/<unresolved>:7003]: connection timed out: /172.17.0.3:7003


Ошибка означает, что мы со стороны приложения пытаеся приконнектится к Узлу редис кластера, используя IP докер контейнера и внутренний порт (порт 7003 используется данным узлом, но наружу он отображается на какой-то случайный порт, который мы и должны использовать в нашем приложении; внутренний порт, по понятным причинам, не доступен из вне). Что касается данного IP-адреса он доступен для приложения, если это Linux, и он не доступен для приложения, если это MacOs/Windows (из-за особенностей реализации докера на этих ОС).

Решение проблемы (а-ка костыль) я собрал по частичкам из разных статей. А давайте сделаем NAT RedisURI на стороне приложения. Ведь это нужно именно для тестов, и тут не так страшно вставлять такой ужас. Решение, на самом деле, состоит из пары строк (огромное спасибо Спрингу и Lettuce, где можно сконфигурировать практически всё, только и успевай, как переопределять бины).

public SocketAddress resolve(RedisURI redisURI) {    Integer mappedPort = redisClusterNatPortMapping.get(redisURI.getPort());    if (mappedPort != null) {        SocketAddress socketAddress = redisClusterSocketAddresses.get(mappedPort);        if (socketAddress != null) {            return socketAddress;        }        redisURI.setPort(mappedPort);    }    redisURI.setHost(DockerClientFactory.instance().dockerHostIpAddress());    SocketAddress socketAddress = super.resolve(redisURI);    redisClusterSocketAddresses.putIfAbsent(redisURI.getPort(), socketAddress);    return socketAddress;}


Полный код выложен на гитхаб https://github.com/Hixon10/spring-redis-cluster-testcontainers.

Идея кода супер простая. Будем хранить две Map. В первой маппинг между внутренними портами редиса (7000..7005) и теми, что доступны для приложения (они могут быть чем-то типа 51343, 51344 и тд). Во-второй внешние порты (типа, 51343) и SocketAddress, полученный для них. Теперь, когда мы получаем от Редиса при обновлении топологии что-то типа 172.17.0.3:7003, мы сможем легко найти нужный внешний порт, по которому сможем найти SocketAddress и переиспользовать его. То есть, с портами проблема решена. А что с IP?

С IP-адресом всё просто. Тут нам на помощь приходят Тест контейнеры в которых есть утилитный метод DockerClientFactory.instance().dockerHostIpAddress(). Для MacOs/Windows он будет отдавать localhost, а для linux IP-адрес контейнера.

Выводы


Программирование это супер интересно, но это вы и без меня знали. А ещё, порой приходится вспомить, что было на первой лекции по сетям в универе, чтобы написать на своей любимой джавке пару новых интеграционных тестов. Приятно, когда знания из института пригождаются в самый неожиданный момент.
Подробнее..

JPoint 2021 тенденции и тренды мира Java

19.04.2021 00:19:54 | Автор: admin
В третьем онлайн-сезоне конференций, проводимых JUG Ru Group, с 13 по 17 апреля 2021 года успешно прошла Java-конференция JPoint 2021.



Что было интересного на конференции? Какой тематики были доклады? Кто из спикеров и про что рассказывал? Что изменилось в организации конференции и долго ли ждать возвращение офлайн-формата? Можно ли что-то ещё придумать оригинальное при написании обзора о конференции?

Основным инструментом, который поможет делать рассказ о конференции и её докладах в этом обзоре, будет облако тегов (англ. tag cloud). Облако тегов визуальное представление текстовых данных, в котором слова, используемые с большей частотой, выделяются размером шрифта или цветом. Облака тегов помогут

  • показать общие тенденции, тренды, направленность прошедшей конференции;
  • проиллюстрировать каждый из представленных в обзоре докладов;
  • поиграть в игру, где будут и облака тегов, и доклады, и спикеры.

Картинка в начале статьи с облаком тегов в форме логотипа JPoint была сформирована с использованием названий и описаний абсолютно всех докладов конференции. Посмотреть файл в оригинальном размере можно по следующей ссылке. Из 1685 слов в топ-3 с заметным отрывом попали: Spring (50 повторений), Java (49 повторений) и data (21 повторение). Из прочих фаворитов, но с меньшей частотой использования, можно также отметить слова session, JDK, cloud, code, Kubernetes, GraphQL и threads. Данная информация помогает понять, куда движется Java-платформа и названия каких сущностей, технологий и продуктов являются самыми актуальными сегодня.

Открытие


Долгожданное открытие конференции выполнили Алексей Фёдоров, Глеб Смирнов, Андрей Когунь и Иван Углянский. Ими были представлены спикеры, эксперты и программный комитет все те, без которых проведение конференции было бы невозможным.



Редкий случай, когда можно было видеть одновременно трёх лидеров Java-сообществ: JUG.ru (Алексей Фёдоров), JUG.MSK (Андрей Когунь) и JUGNsk (Иван Углянский).



Основные события конференции были трёх типов:

  • доклады;
  • мини-доклады партнёров;
  • воркшопы.

Доклады


Приятной неожиданностью для русскоязычных участников конференции стало то, что Себастьян Дашнер свой доклад Качественный код в тестах не просто приятный бонус делал на русском языке. Себастьян принимает участие в качестве спикера в конференциях JUG Ru Group c 2017 года, причём, не только в Java-конференциях. Текущий доклад был посвящён интеграционному тестированию, поэтому в нём присутствовали и Java, и тесты на JUnit, и Docker. В качестве приглашённого эксперта рассказ успешно дополнил Андрей Солнцев. Отличное знание русского языка и неизменно интересный доклад от Себастьяна Дашнера.





В докладе Building scalable microservices for Java using Helidon and Coherence CE от Дмитрия Александрова и Aleksandar Seovic было продемонстрировано совместное использование двух продуктов компании Oracle Helidon (в его разработке участвует Дмитрий) и Oracle Coherence (Aleks является архитектором продукта). Митя ранее делал доклады про MicroProfile (первый доклад и второй) и написал хорошую статью на Хабре про Helidon, поэтому было любопытно посмотреть дальнейшее развитие темы. Повествование сопровождалось демонстрацией кода и запуском приложения, код которого доступен на GitHub. Докладчики, каждый из которых лучше знаком со своим продуктом, отлично дополняли друг друга. Посмотреть оказалось увлекательно и полезно.





Анна Козлова работает над созданием нашего любимого инструмента IntelliJ IDEA, внеся по количеству коммитов самый большой вклад среди всех конрибьютеров в репозиторий IntelliJ IDEA Community Edition, что вызывает огромное уважение.

В своём докладе Многоступенчатые рефакторинги в IntelliJ IDEA Анна очень доходчиво и убедительно показала, как сложные типы рефакторингов могут быть получены комбинацией более простых уже существующих рефакторингов. В препарировании рефакторингов ей ассистировал коллега по компании JetBrains Тагир Валеев. Исключительно полезен как сам доклад (определённо, стоит его пересмотреть), так и озвученная Анной и Тагиром статистика применения разного типа рефакторингов пользователями.





Type inference: Friend or foe? от Venkat Subramaniam. Венкат фантастически харизматичный спикер, которого каждый раз хочется смотреть при присутствии его докладов на конференции. Мне кажется, ценность его докладов в том числе в том, что он заставляет увидеть другую сторону каких-то вещей, ранее казавшимися простыми и очевидными. В этот раз подобной темой было выведение типов (type inference). Кроме интересной информации в очень экспрессивном исполнении наконец-то узнал, в чём Венкат показывает презентации и запускает код (ломал голову над этим при просмотре его предыдущих докладов) это редактор vi.





Доклад Антона Кекса про то, Что такое Работающий Продукт и как его делать своеобразное продолжение его выступления The world needs full-stack craftsmen двухлетней давности. Если в прошлом докладе Антон говорил о недопустимости узкой специализации разработчика, то в этот раз сфокусировал своё внимание и внимание слушателей на том, почему важно и как можно сделать качественный работающий программный продукт. Докладчик подкреплял приведённые теоретические тезисы практическими примерами, поэтому просмотр стал весьма захватывающим зрелищем.





Под доклад Spring Data Рostроитель (Spark it!) в исполнении Евгения Борисова предусмотрительно был отведён отдельный пятый день конференции. Планировалось, что демонстрация написания поддержки Spark для Spring Data займёт 6 часов (в итоге вышло почти 7). Положительным моментом онлайн-конференции является то, что в случае длинных докладов можно комфортно прерывать и продолжать просмотр позднее. Много кода, новой информации и подробных пояснений. Традиционно получилось качественно, основательно и увлекательно.



Мини-доклады партнёров


+10 к безопасности кода на Java за 10 минут стал первым из 15-минутных докладов партнёров, увиденных на конференции. Алексей Бабенко сконцентрировал в небольшом времени, отведённом на доклад, внимание на вопросах безопасности при написании кода на языке Java. Формат мини-докладов, которые показываются в перерывах между большими докладами, оказался достаточно удачным и востребованным.





Ещё один мини-доклад, 1000 и 1 способ сесть на мель в Spring WebFlux при написании высоконагруженного сервиса от Анатолия Тараканова, может пригодиться в том случае, если используете Spring WebFlux и возникли какие-либо проблемы в разработке и эксплуатации приложения. Краткое перечисление проблем и способов их решений может чем-то помочь.





В кратком докладе R2DBC. Стоит ли игра свеч? от Антона Котова даётся оценка практической применимости спецификации R2DBC в текущий момент. После ранее прослушанного вот этого доклада Олега Докуки было интересно узнать сегодняшнее положение вещей. Антон в конце доклада даёт однозначный ответ на вопрос Стоит ли игра свеч?. Через некоторое время ответ должен, вероятно, измениться.





Доклад Секретный ингредиент: Как увеличить базу пользователей в 3 раза за год в исполнении Александра Белокрылова и Алисы Дрожжиновой представил следующие новости от компании BellSoft, наиболее известной своим продуктом Liberica JDK:

  • клиентская база компании увеличилась в 3 раза за последний год;
  • появился новый инструмент Liberica Administration Center (LAC) для централизованного обновления Java на компьютерах пользователей;
  • стала доступна утилита Liberica Native Image Kit на базе GraalVM CE;
  • компания ведёт работы в области серверов приложений (на сайте доступен продукт LiberCat на основе Apache Tomcat).





Кирилл Скрыган докладом Code With Me новая платформа для удаленной коллаборативной разработки представил новую возможность продуктов компании JetBrains для парного программирования и коллективной разработки в среде разработки. Была показана базовая функциональность сервиса и перечислены получаемые преимущества.



Воркшопы


На конференции было два воркшопа: Парное программирование вместе с Андреем Солнцевым и Антоном Кексом и Строим Бомбермена с RSocket вместе с Сергеем Целовальниковым и Олегом Докукой. Для просмотра во время конференции выбор пал на воркшоп Строим Бомбермена с RSocket. Олег и Сергей убедительно продемонстрировали на примере игры взаимодействие составных частей приложения по протоколу RSocket. Код приложения доступен на GitHub для изучения и повторения действий, выполненных во время воркшопа.



Конференции, Java-митапы и игра


На сайте jugspeakers.info по-прежнему доступно приложение, состоящее из двух частей:

  • поиск и просмотр информации о конференциях и Java-митапах, организуемых JUG Ru Group, JUG.MSK и JUGNsk (спикеры, доклады, презентации, видео, статистика);
  • игра Угадай спикера.

К новому сезону конференций в приложение были сделаны ряд доработок и новшеств, первое из которых позволит более эффективно использовать программу во время конференций:

  1. Начальная страница отображает теперь ближайшую или идущую в данный момент конференцию (картинка слева ниже сделана во время работы JPoint 2021). Установка значений всех фильтров поиска по умолчанию на текущую конференцию также должна помочь сделать программу максимально полезной во время идущей сейчас конференции.
  2. Приложение дополнено фильтрами по организатору конференций и митапов (средняя картинка).
  3. Добавлена информация о видео всех докладов, сделанных публично доступными (в том числе видео докладов с Joker 2020).
  4. Появились данные о конференции SnowOne, второй год проводящейся новосибирским Java-сообществом JUGNsk (см. картинку внизу справа).
  5. Стало возможным видеть учётные записи Хабра у спикеров.



Во второй части приложения (в игре Угадай спикера) появилось 2 новых режима: угадывание облака тегов по спикеру и спикера по облаку тегов. Облака тегов формируются на лету, при выборе пользователем конференций или митапов. Источником для создания облаков тегов по спикерам являются наименования и описания их докладов. Для каждого спикера создаётся одно (по тексту на английском языке) или два облака тегов (второе облако возможно, если у докладов есть описание и на русском языке). Переключением языка интерфейса можно посмотреть оба облака тегов.

Хорошее знание тематики, на которую спикеры предпочитают делать свои доклады, поможет Вам правильно выбрать из нескольких вариантов либо облако тегов, либо спикера.



Чем больше конференций выбрано в игре для данных режимов (угадывание облака тегов по спикеру и спикера по облаку тегов), тем больше информации для формирования облака тегов и результат будет более точный. Java-разработчикам для игры можно порекомендовать следующие варианты в порядке усложнения:

  1. Выбрать только одну конференцию JPoint 2021 (Тип события JPoint, Событие JPoint 2021)
  2. Выбрать все конференции JPoint (Тип события JPoint, Событие конференции за все годы)
  3. Выбрать все Java-события (Тип события Joker, JPoint, SnowOne, JBreak, JUG.MSK, JUG.ru и JUGNsk)

Код приложения находится на GitHub, репозиторию можно ставить звёздочки.

Закрытие


Алексей Фёдоров, Глеб Смирнов и Андрей Когунь закрыли конференцию, подведя итоги и поделившись каждый своими впечатлениями от пятидневного конференционного марафона.



Несмотря на вынужденное ограничение онлайн-форматом, конференция продолжает держать высокую планку: удобная платформа для просмотра докладов и взаимодействия с другими участниками, множество докладов по Java-технологиям, горячая информация о новых продуктах (Space и Code With Me), любимые спикеры с отлично дополняющими их приглашёнными экспертами.

В весенне-летнем сезоне онлайн-конференций JUG Ru Group ещё будут конференции HolyJS, DotNext (20-23 апреля 2021 года) и Hydra (15-18 июня 2021 года). Можно посетить любую из конференций отдельно или купить единый билет на все шесть конференций сезона (три уже прошедших и три оставшихся), видео докладов становятся доступными сразу же после завершения конференций.
Подробнее..

Релиз Spring Native Beta

13.03.2021 20:20:43 | Автор: admin

Недавно команда, занимающаяся портированием Spring для GraalVM, выпустила первый крупный релиз - Spring Native Beta. Вместе с создателями GraalVM они смогли пофиксить множество багов как в самом компиляторе так и спринге. Теперь у проекта появилась официальная поддержка, свой цикл релизов и его можно щупать :)


Самым главным препятствием при переносе кода из JVM в бинарники является проблема использования фишек, присущих только java - рефлексия, работа с classpath, динамическая загрузка классов и т.д.

Согласно документации, ключевые различия между обычным JVM и нативной реализацией заключаются в следующем:

  • Статический анализ всего приложения выполняется во время сборки.

  • Неиспользуемые компоненты удаляются во время сборки.

  • Рефлексия, ресурсы и динамические прокси могут быть настроены только с помощью дополнительных конфигураций.

  • На время сборки фиксируются все компоненты в Classpath.

  • Нет ленивой загрузки класса: при загрузке все, что поставляется в исполняемых файлах, будет загружено в память. Например, чтобы вызов Class.forName ("myClass") отработал верно, нужно иметь myClass в файле конфигурации. Если в файле конфигурации не будет найден класс, который запрашивается для динамической загрузки класса, будет выбрано исключение ClassNotFoundException

  • Часть кода будет запущена во время сборки, чтобы правильно связать компоненты. Например, тесты.

В самом спринге рефлексия, создание прокси и ленивая инициализация встречается практически везде, поэтому все конфигурации надо было аккуратно обработать, из-за этого к релизу шли больше года.

В ходе исследований был создан новый компонент Spring AOT, который отвечает за все необходимые преобразования вашего кода в удобоваримый для Graal VM формат.

Spring AOT анализирует код и на основе него создает файлы конфигурации такие как native-image.properties, reflection-config.json, proxy-config.json или resource-config.json.

Так как Graal VM поддерживает первоначальную настройку через статические файлы, эти файлы помещаются при сборке в каталог META-INF/native-image.

Для каждого сборщика выпущен свой плагин, который активирует работу Spring AOT. Для maven это spring-aot-maven-plugin, соответственно для gradle - spring-aot-gradle-plugin.Для того, чтобы добавить gradle плагин в свой проект нужна всего одна строка:

plugins {id 'org.springframework.experimental.aot' version '0.9.0'}

Плагин пытается сконфигурировать максимально возможное количество компонентов, выполняется предварительные преобразования по всем компонентам программы, необходимые для улучшения совместимости.

В случае, если ему это не удалось, вам в ручную необходимо добавить эти данные. Это можно сделать вручную поправив файлы конфигурации, либо использовать специально созданные аннотации.

Например, для случаев реализации компонентов с помощью WebClient можно использовать аннотацию из пакета org.springframework.nativex.hint, чтобы указать какой тип мы будем обрабатывать:

@TypeHint(types = Data.class, typeNames = "com.example.webclient.Data$SuperHero")@SpringBootApplicationpublic class WebClientApplication {// ...}

Здесь мы указываем, что будем сериализовать класс Data, в котором есть подкласс SuperHero. Во время сборки для нас заранее создадут клиент, который сможет работать с этим типом данных.

Так как graavlvm не поддерживает работу с динамическими прокси, то для поддержки работы с java.lang.reflect.Proxy создана аннотация @ProxyHint.

Применять ее можно, например, так:

@ProxyHint(types = {     org.hibernate.Session.class,     org.springframework.orm.jpa.EntityManagerProxy.class})

Если необходимо подтянуть какие-либо ресурсы в образ, то необходимо воспользоваться аннотацией@ResourceHint.Например, таким образом:

@ResourceHint(patterns = "com/mysql/cj/TlsSettings.properties")

Чтобы указать какие классы / пакеты должны быть инициализированы явно во время сборки или выполнения, нужно воспользоваться аннотацией @InitializationHint:

@InitializationHint(types = org.h2.util.Bits.class,    initTime = InitializationTime.BUILD)

Для того, чтобы компактно собрать все эти аннотации воедино создана аннотация @NativeHint:

@Repeatable(NativeHints.class)@Retention(RetentionPolicy.RUNTIME)public @interface NativeHint

Все вместе это будет выглядеть, например, вот так:

@NativeHint(    trigger = Driver.class,    options = "--enable-all-security-services",    types = @TypeHint(types = {       FailoverConnectionUrl.class,       FailoverDnsSrvConnectionUrl.class,       // ...    }), resources = {@ResourceHint(patterns = "com/mysql/cj/TlsSettings.properties"),@ResourceHint(patterns = "com.mysql.cj.LocalizedErrorMessages",                      isBundle = true)})

В качестве тригера, мы выбираем тот класс, присутствие которого в classpath должно вызвать построение конфигурации.

Все активные аннотации учитываются во время компиляции и преобразуются в конфигурацию Graal VM плагином Spring AOT.

Spring Native уже включена в релизный цикл, забрать шаблон можно прямо со start.spring.io. Так как поддержка JPA и прочих spring компонентов уже реализована, то собрать простое CRUD приложение можно сразу. Если необходимо указать дополнительные параметры Graal VM при сборке, их можно добавить с помощью переменной среды BP_NATIVE_IMAGE_BUILD_ARGUMENTS в плагине Spring AOT, если сборка идет через Buildpacks, или с помощью элемента конфигурации <buildArgs> в pom.xml, если вы собираете через плагин native-image-maven-plugin.

Собственно, выполняем команды mvn spring-boot: build-image или gradle bootBuildImage - и начнется сборка образа. Стоит отметить, что сборщику нужно более 7 Гб памяти, для того сборка завершилась успешно. На моей машине сборка, вместе с загрузкой образов заняла не более 5 минут. При этом образ получился очень компактным, всего 60 Мб. Стартовало приложение за 0.022 секунды! Это невероятный результат. Учитывая, что все большее количество компаний переходит на K8s и старт приложения, так же как и используемые ресурсы очень важны в современном мире, то данная технология позволяет Spring сделать фреймворком номер один для всех типов микросервисов, даже для реализаций FaaS, где очень важна скорость холодного старта.

Подробнее..
Категории: Микросервисы , Java , Spring , Graalvm , Jvm , Graal

Юнит тестирование Spring Bot в Docker и Яндекс облаке

08.02.2021 18:21:29 | Автор: admin

Всем привет.

Меня зовут Евгений Фроликов я разработчик в АльфаСтрахование

В ходе работы над проектом в АльфаСтрахование пишем проект на микро сервисах и сложилось так что один из "микро сервисов" сильно разросся (но до монолита ему ещё далеко :) ). Жили мы так долго и счастливо , пока не стали "переезжать" в облако, тут и начались приключения.

Переезд не чем особенно не запомнился для команды разработки только вопросами от DevOps насчёт портов и т.д. Замечу что все интеграционные тесты мы выпилили для того чтобы отвязаться от зависимости от других команд когда у них что то падает на тестовых стендах. Но стало происходить "магия" в JUnit тестах , а именно стали падать тесты. Падали они фантомное и не предсказуемо , лечилось до поры до времени это retraem pipeline , до тех пор пока эта проблема не стала блокером для выкладок изменений .

тест 1 запусктест 1 запуск

Дальше просто retraem

тест 2 запусктест 2 запуск

И так можно было "крутить рулетку" долго и упорно.

Стали разбираться (спасибо понимающему бизнесу за то что дали на это время) . Так примерно выглядели заголовки наших тестов (которых было ооочень много , так как мы иcпользуем Sonar).

@RunWith(SpringJUnit4ClassRunner.class)@SpringBootTestpublic class ContractStatusServiceTest {    @Autowired    private ContractStatusService contractStatusService;    @MockBean    private RsaInfoComponent rsaInfoComponent;    @MockBean    private ContractRepository contractRepository;

Давайте разберём "магические" анотации

  1. @RunWith(SpringJUnit4ClassRunner.class) -Запуск контейнера Spring для выполнения модульного теста

  2. @SpringBootTest -аннотация говорит Spring Boot пойти и найти основной класс конфигурации (например, с @SpringBootApplication) и использовать его для запуска контекста приложения Spring. SpringBootTest загружает полное приложение

  3. @Autowired - Инжектит Bean;

И закралась мысль а почему мы используем @Autowired ведь его строго не рекомендуют использовать при разработке приложений , так как есть риск что он не успеет проинжектиться в поле.

Начались эксперименты такова рода.

@RunWith(SpringRunner.class)@SpringBootTest@RequiredArgsConstructorpublic class  ComponentTestTest {   // @Autowired    private final ComponentTest componentTest;    

То есть попытка проинжектить бин как в приложение , через конструктор

1)@RequiredArgsConstructor - Аннотация Lombok для автоматического создания конструкторов из полей final.

Но.....

java.lang.Exception: Test class should have exactly one public zero-argument constructorat org.junit.runners.BlockJUnit4ClassRunner.validateZeroArgConstructor(BlockJUnit4ClassRunner.java:171)at org.junit.runners.BlockJUnit4ClassRunner.validateConstructor(BlockJUnit4ClassRunner.java:148)at org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:127)...

а жаль.

Дальше стали приходить осознавание , а зачем мы поднимаем контекст всего приложения для простых тестов и вспомнили про Mock

@RunWith(MockitoJUnitRunner.class)public class CrossProductServiceTest {    @InjectMocks    private CrossProductService crossProductService;    @Mock    private KaskoService kaskoService;    @Mock    private CrownVirusOfferService crownVirusOfferService;

Давайте разберёмся что тут происходит и всём принципиальная разница

  1. @RunWith(MockitoJUnitRunner.class) - Заполняет заглушками наш Bean , а не поднимается контекст (подробнее можно почитать в доках )

  2. @Mock - сама заглушка

  3. @InjectMocks - создаёт Bean и передаёт в конструктор заглушки

И всё "звалось".

Плюсы :

  1. У нас в разы ускорились тесты при деплоях (так как контекст не поднимается)

  2. Мы перестали ловить и бояться не проинжектеных бинов

Минусы:

  1. Пришлось переписывать все тесты

Подробнее..

Разбираемся, как работает Spring Data Repository, и создаем свою библиотеку по аналогии

28.01.2021 18:09:16 | Автор: admin

На habr уже была статья о том, как создать библиотеку в стиле Spring Data Repository (рекомендую к чтению), но способы создания объектов довольно сильно отличаются от "классического" подхода, используемого в Spring Boot. В этой статье я постарался быть максимально близким к этому подходу. Такой способ создания бинов (beans) применяется не только в Spring Data, но и, например, в Spring Cloud OpenFeign.

Содержание

ТЗ

Начнем с краткого технического задания: что мы в итоге хотим получить. Весь бизнес-слой является полностью выдумкой и не является примером качественного программирования, основная его цель - показать, как можно взаимодействовать со Spring.

Итак, у нас прошли праздники, но мы хотим иметь возможность создавать на лету бины (beans), которые позволили бы нам поздравлять всех, кого мы в них перечислим.

Пример:

public interface FamilyCongratulator extends Congratulator {    void сongratulateМамаAndПапа();}

При вызове метода мы хотим получать:

Мама,Папа! Поздравляю с Новым годом! Всегда ваш

Или вот так

@Congratulate("С уважением, Пупкин")public interface ColleagueCongratulator {    @CongratulateTo("Коллега")    void сongratulate();}

и получать

Коллега! Поздравляю с Новым годом! С уважением, Пупкин

Т.е. мы должны найти все интерфейсы, которые расширяют интерфейс Congratulator или имеют аннотацию @Congratulate

В этих интерфейсах мы должны найти все методы, начинающиеся с congratulate , и сгенерировать для них метод, выводящий в лог соответствующее сообщение.

@Enable

Как и любая взрослая библиотека у нас будет аннотация, которая включает наш механизм (как @EnableFeignClients и @EnableJpaRepositories).

@Retention(RetentionPolicy.RUNTIME)@Target(ElementType.TYPE)@Documented@Import(FeignClientsRegistrar.class)public @interface EnableFeignClients {...}@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@Import(JpaRepositoriesRegistrar.class)public @interface EnableJpaRepositories {...}

Если посмотреть внимательно, то можно заметить, что обе этиx аннотации содержат @Import, где есть ссылка на класс, расширяющий интерфейс ImportBeanDefinitionRegistrar

public interface ImportBeanDefinitionRegistrar { default void registerBeanDefinitions(    AnnotationMetadata importingClassMetadata,     BeanDefinitionRegistry registry,     BeanNameGenerator importBeanNameGenerator) {registerBeanDefinitions(importingClassMetadata, registry);} default void registerBeanDefinitions(    AnnotationMetadata importingClassMetadata,    BeanDefinitionRegistry registry) {}}

Напишем свою аннотацию

@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Import(CongratulatorsRegistrar.class)public @interface EnableCongratulation {}

Не забудем прописать @Retention(RetentionPolicy.RUNTIME), чтобы аннотация была видна во время выполнения.

ImportBeanDefinitionRegistrar

Посмотрим, что происходит в ImportBeanDefinitionRegistrar у Spring Cloud Feign:

class FeignClientsRegistrarimplements ImportBeanDefinitionRegistrar,    ResourceLoaderAware,     EnvironmentAware {...  @Override public void registerBeanDefinitions(AnnotationMetadata metadata,BeanDefinitionRegistry registry) { //создаются beans для конфигураций по умолчанию  registerDefaultConfiguration(metadata, registry); //создаются beans для создания клиентов  registerFeignClients(metadata, registry);}...   public void registerFeignClients(AnnotationMetadata metadata,BeanDefinitionRegistry registry) {  LinkedHashSet<BeanDefinition> candidateComponents = new LinkedHashSet<>();... //выполняется поиск кандидатов на создание  ClassPathScanningCandidateComponentProvider scanner = getScanner();  scanner.setResourceLoader(this.resourceLoader);  scanner.addIncludeFilter(new AnnotationTypeFilter(FeignClient.class));  Set<String> basePackages = getBasePackages(metadata);  for (String basePackage : basePackages) {    candidateComponents.addAll(scanner.findCandidateComponents(basePackage));  }... for (BeanDefinition candidateComponent : candidateComponents) {  if (candidateComponent instanceof AnnotatedBeanDefinition) {...  //заполняем контекст   registerFeignClient(registry, annotationMetadata, attributes);   }  } }   private void registerFeignClient(BeanDefinitionRegistry registry,AnnotationMetadata annotationMetadata, Map<String, Object> attributes) {String className = annotationMetadata.getClassName(); //Создаем описание для FactoryBeanDefinitionBuilder definition = BeanDefinitionBuilder    .genericBeanDefinition(FeignClientFactoryBean.class);...  //Регистрируем это описание BeanDefinitionHolder holder = new BeanDefinitionHolder(  beanDefinition, className, new String[] { alias }); BeanDefinitionReaderUtils.registerBeanDefinition(holder, registry); }      ...}

В Spring Cloud OpenFeign сначала создаются бины конфигурации, затем выполняется поиск кандидатов и для каждого кандидата создается Factory.

В Spring Data подход аналогичный, но так как Spring Data состоит из множества модулей, то основные моменты разнесены по разным классам (см. например org.springframework.data.repository.config.RepositoryBeanDefinitionBuilder#build)

Можно заметить, что сначала создаются Factory, а не сами bean. Это происходит потому, что мы не можем в BeanDefinitionHolder описать, как должен работать наш bean.

Сделаем по аналогии наш класс (полный код класса можно посмотреть здесь)

public class CongratulatorsRegistrar implements         ImportBeanDefinitionRegistrar,        ResourceLoaderAware, //используется для получения ResourceLoader        EnvironmentAware { //используется для получения Environment    private ResourceLoader resourceLoader;    private Environment environment;    @Override    public void setResourceLoader(ResourceLoader resourceLoader) {        this.resourceLoader = resourceLoader;    }    @Override    public void setEnvironment(Environment environment) {        this.environment = environment;    }...

ResourceLoaderAware и EnvironmentAware используется для получения объектов класса ResourceLoader и Environment соответственно. При создании экземпляра CongratulatorsRegistrar Spring вызовет соответствующие set-методы.

Чтобы найти требуемые нам интерфейсы, используется следующий код:

//создаем scannerClassPathScanningCandidateComponentProvider scanner = getScanner();scanner.setResourceLoader(this.resourceLoader);//добавляем необходимые фильтры //AnnotationTypeFilter - для аннотаций//AssignableTypeFilter - для наследованияscanner.addIncludeFilter(new AnnotationTypeFilter(Congratulate.class));scanner.addIncludeFilter(new AssignableTypeFilter(Congratulator.class));//указываем пакет, где будем искать//importingClassMetadata.getClassName() - возвращает имя класса,//где стоит аннотация @EnableCongratulationString basePackage = ClassUtils.getPackageName(  importingClassMetadata.getClassName());//собственно сам поискLinkedHashSet<BeanDefinition> candidateComponents =   new LinkedHashSet<>(scanner.findCandidateComponents(basePackage));...private ClassPathScanningCandidateComponentProvider getScanner() {  return new ClassPathScanningCandidateComponentProvider(false,                                                    this.environment) {    @Override    protected boolean isCandidateComponent(      AnnotatedBeanDefinition beanDefinition) {      //требуется, чтобы исключить родительский класс - Congratulator      return !Congratulator.class.getCanonicalName()        .equals(beanDefinition.getMetadata().getClassName());    }  };}

Регистрация Factory:

String className = annotationMetadata.getClassName();// Используем класс CongratulationFactoryBean как наш Factory, // реализуем в дальнейшемBeanDefinitionBuilder definition = BeanDefinitionBuilder.genericBeanDefinition(CongratulationFactoryBean.class);// описываем, какие параметры и как передаем,// здесь выбран - через конструкторdefinition.addConstructorArgValue(className);definition.addConstructorArgValue(configName);AbstractBeanDefinition beanDefinition = definition.getBeanDefinition();beanDefinition.setAttribute(FactoryBean.OBJECT_TYPE_ATTRIBUTE, className);// aliasName - создается из наших CongratulatorString aliasName = AnnotationBeanNameGenerator.INSTANCE.generateBeanName(  candidateComponent, registry);String name = BeanDefinitionReaderUtils.generateBeanName(  beanDefinition, registry);BeanDefinitionHolder holder = new BeanDefinitionHolder(beanDefinition,  name, new String[]{aliasName});BeanDefinitionReaderUtils.registerBeanDefinition(holder, registry);

Попробовав разные способы, я советую остановиться на передаче параметров через конструктор, этот способ работает наиболее стабильно. Если вы захотите передать параметры не через конструктор, а через поля, то в параметры (beanDefinition.setAttribute) обязательно надо положить переменную FactoryBean.OBJECT_TYPE_ATTRIBUTE и соответствующий класс (именно класс, а не строку). Без этого наш Factory создаваться не будет. И Sping Data и Spring Feign передают строку: скорее всего это действует как соглашение, так как найти место, где эта строка используется, я не смог (если кто подскажет - дополню).

Что, если мы хотим иметь возможность получать наши beans по имени, например, так

@Autowiredprivate Congratulator familyCongratulator;

это тоже возможно, так как во время создания Factory в качестве alias было передано имя bean (AnnotationBeanNameGenerator.INSTANCE.generateBeanName(candidateComponent, registry))

FactoryBean

Теперь займемся Factory.

Стандартный интерфейс FactoryBean имеет 2 метода, которые нужно имплементировать

public interface FactoryBean<T> {  Class<?> getObjectType();  T getObject() throws Exception;  default boolean isSingleton() {return true;}}

Заметим, что есть возможность указать, является ли объект, который будет создаваться, Singleton или нет.

Есть абстрактный класс (AbstractFactoryBean), который расширяет интерфейс дополнительной логикой (например, поддержка destroy-методов). Он так же имеет 2 абстрактных метода

public abstract class AbstractFactoryBean<T> implements FactoryBean<T>{...@Overridepublic abstract Class<?> getObjectType();protected abstract T createInstance() throws Exception;}

Первый метод getObjectType требует вернуть класс возвращаемого объекта - это просто, его мы передали в конструктор.

@Overridepublic Class<?> getObjectType() {return type;}

Второй метод требует вернуть уже сам объект, а для этого нужно его создать. Для этого есть много способов. Здесь представлен один из них.

Сначала создадим обработчик для каждого метода:

Map<Method, MethodHandler> methodToHandler = new LinkedHashMap<>();for (Method method : type.getMethods()) {    if (!AopUtils.isEqualsMethod(method) &&            !AopUtils.isToStringMethod(method) &&            !AopUtils.isHashCodeMethod(method) &&            !method.getName().startsWith(СONGRATULATE)    ) {        throw new UnsupportedOperationException(        "Method " + method.getName() + " is unsupported");    }    String methodName = method.getName();    if (methodName.startsWith(СONGRATULATE)) {         if (!"void".equals(method.getReturnType().getCanonicalName())) {            throw new UnsupportedOperationException(              "Congratulate method must return void");        }        List<String> members = new ArrayList<>();        CongratulateTo annotation = method.getAnnotation(          CongratulateTo.class);        if (annotation != null) {            members.add(annotation.value());        }        members.addAll(Arrays.asList(methodName.replace(СONGRATULATE, "").split(AND)));        MethodHandler handler = new MethodHandler(sign, members);        methodToHandler.put(method, handler);    }}

Здесь MethodHandler - простой класс, который мы создаем сами.

Теперь нам нужно создать объект. Можно, конечно, напрямую вызвать Proxy.newInstance, но лучше воспользоваться классами Spring, которые, например, дополнительно создадут для нас методы hashCode и equals.

//Класс Spring для создания proxy-объектовProxyFactory pf = new ProxyFactory();//указываем список интерфейсов, которые этот bean должен реализовыватьpf.setInterfaces(type);//добавляем advice, который будет вызываться при вызове любого метода proxy-объектаpf.addAdvice((MethodInterceptor) invocation -> {    Method method = invocation.getMethod();    //добавляем какой-нибудь toString метод    if (AopUtils.isToStringMethod(method)) {        return "proxyCongratulation, target:" + type.getCanonicalName();    }    //находим и вызываем наш созданный ранее MethodHandler    MethodHandler methodHandler = methodToHandler.get(method);    if (methodHandler != null) {        methodHandler.congratulate();        return null;    }    return null;});target = pf.getProxy();

Объект готов.

Теперь при старте контекста Spring создает бины (beans) на основе наших интерфейсов.

Исходный код можно посмотреть здесь.

Полезные ссылки

Подробнее..
Категории: Java , Spring , Spring-boot

Swagger (OpenAPI 3.0)

09.02.2021 14:04:30 | Автор: admin

Всем привет!!! Это мой первый пост на Хабре и я хочу поделиться с вами своим опытом в исследование нового для себя фреймворка.

Мне предоставился момент выбрать тему и подготовить презентацию для своей команды. Вдохновившись спикером Евгений Маренков, я решил выбрать данную тему. В процессе подготовки, я облазил много статей и репозиториев что бы компактно и эффективно донести нужную информацию.

Сейчас хочу поделиться ею в надежде, что кому-то она поможет в изучение Swagger (OpenApi 3.0)

Введение

Я на 99% уверен у многих из вас были проблемы с поиском документации для нужного вам контроллера. Многие если и находили ее быстро, но в конечном итоге оказывалось что она работает не так как описано в документации, либо вообще его уже нет.
Сегодня я вам докажу, что есть способы поддерживать документацию в актуальном виде и в этом мне будет помогать Open Source framework от компании SmartBear под названием Swagger, а с 2016 года он получил новое обновление и стал называться OpenAPI Specification.

Swagger - это фреймворк для спецификации RESTful API. Его прелесть заключается в том, что он дает возможность не только интерактивно просматривать спецификацию, но и отправлять запросы так называемый Swagger UI.

Также возможно сгенерировать непосредственно клиента или сервер по спецификации API Swagger, для этого понадобиться Swagger Codegen.

Основные подходы

Swagger имеет два подхода к написанию документации:

  • Документация пишется на основании вашего кода.

    • Данный подход позиционируется как "очень просто". Нам достаточно добавить несколько зависимостей в проект, добавить конфигурацию и уже мы будем иметь нужную документацию, хоть и не настолько описанной какою мы хотели.

    • Код проекта становиться не очень читабельным от обилия аннотаций и описания в них.

    • Вся документация будет вписана в нашем коде (все контроллеры и модели превращаются в некий Java Swagger Code)

    • Подход не советуют использовать, если есть возможности, но его очень просто интегрировать.

  • Документация пишется отдельно от кода.

    • Данный подход требует знать синтаксис Swagger Specification.

    • Документация пишется либо в JAML/JSON файле, либо в редакторе Swagger Editor.

Swagger Tools

Swagger или OpenAPI framework состоит из 4 основных компонентов:

  1. Swagger Core - позволяет генерировать документацию на основе существующего кода основываясь на Java Annotation.

  2. Swagger Codegen - позволит генерировать клиентов для существующей документации.

  3. Swagger UI - красивый интерфейс, который представляет документацию. Дает возможность просмотреть какие типы запросов есть, описание моделей и их типов данных.

  4. Swagger Editor - Позволяет писать документацию в YAML или JSON формата.

Теперь давайте поговорим о каждом компоненте отдельно.

Swagger Core

Swagger Code - это Java-реализация спецификации OpenAPI

Для того что бы использовать Swagger Core во все орудие, требуется:

  • Java 8 или больше

  • Apache Maven 3.0.3 или больше

  • Jackson 2.4.5 или больше

Что бы внедрить его в проект, достаточно добавить две зависимости:

<dependency>    <groupId>io.swagger.core.v3</groupId>    <artifactId>swagger-annotations</artifactId>    <version>2.1.6</version></dependency><dependency>    <groupId>org.springdoc</groupId>    <artifactId>springdoc-openapi-ui</artifactId>    <version>1.5.2</version></dependency>

Также можно настроить maven плагин, что бы наша документация при сборке проект генерировалсь в YAML

<plugin> <groupId>org.springdoc</groupId> <artifactId>springdoc-openapi-maven-plugin</artifactId> <version>0.3</version> <executions>   <execution>   <phase>integration-test</phase>   <goals>     <goal>generate</goal>   </goals>   </execution> </executions> <configuration>   <apiDocsUrl>http://localhost:8080/v3/api-docs</apiDocsUrl>   <outputFileName>openapi.yaml</outputFileName>   <outputDir>${project.build.directory}</outputDir> </configuration></plugin>

Дальше нам необходимо добавить конфиг в проект.

Для конфигурации Swagger необходимо добавить два бина. Где нам нужно будет описать название приложения, версию нашего API, так же можно добавить контакт разработчик который отвечает за данные API

    @Bean    public GroupedOpenApi publicUserApi() {        return GroupedOpenApi.builder()                             .group("Users")                             .pathsToMatch("/users/**")                             .build();    }    @Bean    public OpenAPI customOpenApi(@Value("${application-description}")String appDescription,                                 @Value("${application-version}")String appVersion) {        return new OpenAPI().info(new Info().title("Application API")                                            .version(appVersion)                                            .description(appDescription)                                            .license(new License().name("Apache 2.0")                                                                  .url("http://springdoc.org"))                                            .contact(new Contact().name("username")                                                                  .email("test@gmail.com")))                            .servers(List.of(new Server().url("http://localhost:8080")                                                         .description("Dev service"),                                             new Server().url("http://localhost:8082")                                                         .description("Beta service")));    }

После добавление нужных нам зависимостей, у нас появятся новые аннотация с помощью которых можно документировать наш код.

Вот некоторые из них:

  • @Operation - Описывает операцию или обычно метод HTTP для определенного пути.

  • @Parameter - Представляет один параметр в операции OpenAPI.

  • @RequestBody - Представляет тело запроса в операции

  • @ApiResponse - Представляет ответ в операции

  • @Tag - Представляет теги для операции или определения OpenAPI.

  • @Server - Представляет серверы для операции или для определения OpenAPI.

  • @Callback - Описывает набор запросов

  • @Link - Представляет возможную ссылку времени разработки для ответа.

  • @Schema - Позволяет определять входные и выходные данные.

  • @ArraySchema - Позволяет определять входные и выходные данные для типов массивов.

  • @Content - Предоставляет схему и примеры для определенного типа мультимедиа.

  • @Hidden - Скрывает ресурс, операцию или свойство

Примеры использования:

@Tag(name = "User", description = "The User API")@RestControllerpublic class UserController {}
    @Operation(summary = "Gets all users", tags = "user")    @ApiResponses(value = {            @ApiResponse(                    responseCode = "200",                    description = "Found the users",                    content = {                            @Content(                                    mediaType = "application/json",                                    array = @ArraySchema(schema = @Schema(implementation = UserApi.class)))                    })    })    @GetMapping("/users")    public List<UserApi> getUsers()

Swagger Codegen

Swagger Codegen - это проект, который позволяет автоматически создавать клиентские библиотеки API (создание SDK), заглушки сервера и документацию с учетом спецификации OpenAPI.

В настоящее время поддерживаются следующие языки / фреймворки:

  • API clients:

    • Java (Jersey1.x, Jersey2.x, OkHttp, Retrofit1.x, Retrofit2.x, Feign, RestTemplate, RESTEasy, Vertx, Google API Client Library for Java, Rest-assured)

    • Kotlin

    • Scala (akka, http4s, swagger-async-httpclient)

    • Groovy

    • Node.js (ES5, ES6, AngularJS with Google Closure Compiler annotations)

    • Haskell (http-client, Servant)

    • C# (.net 2.0, 3.5 or later)

    • C++ (cpprest, Qt5, Tizen)

    • Bash

  • Server stub:

    • Java (MSF4J, Spring, Undertow, JAX-RS: CDI, CXF, Inflector, RestEasy, Play Framework, PKMST)

    • Kotlin

    • C# (ASP.NET Core, NancyFx)

    • C++ (Pistache, Restbed)

    • Haskell (Servant)

    • PHP (Lumen, Slim, Silex, Symfony, Zend Expressive)

    • Python (Flask)

    • NodeJS

    • Ruby (Sinatra, Rails5)

    • Rust (rust-server)

    • Scala (Finch, Lagom, Scalatra)

  • API documentation generators:

    • HTML

    • Confluence Wiki

  • Other:

    • JMeter

Что бы внедрить его в проект, достаточно добавить зависимость, если используете Swagger:

<dependency>    <groupId>io.swagger</groupId>    <artifactId>swagger-codegen-maven-plugin</artifactId>    <version>2.4.18</version></dependency>

и если используете OpenApi 3.0, то:

<dependency>    <groupId>io.swagger.codegen.v3</groupId>    <artifactId>swagger-codegen-maven-plugin</artifactId>    <version>3.0.24</version></dependency>

Можно настроить maven плагин, и уже на процессе сборки мы можем сгенерировать нужный для нас клиент либо мок сервиса.

      <plugin>        <groupId>org.openapitools</groupId>        <artifactId>openapi-generator-maven-plugin</artifactId>        <version>3.3.4</version>        <executions>          <execution>            <phase>compile</phase>            <goals>              <goal>generate</goal>            </goals>            <configuration>              <generatorName>spring</generatorName>              <inputSpec>${project.basedir}/src/main/resources/api.yaml</inputSpec>              <output>${project.build.directory}/generated-sources</output>              <apiPackage>com.api</apiPackage>              <modelPackage>com.model</modelPackage>              <supportingFilesToGenerate>                ApiUtil.java              </supportingFilesToGenerate>              <configOptions>                <groupId>${project.groupId}</groupId>                <artifactId>${project.artifactId}</artifactId>                <artifactVersion>${project.version}</artifactVersion>                <delegatePattern>true</delegatePattern>                <sourceFolder>swagger</sourceFolder>                <library>spring-mvc</library>                <interfaceOnly>true</interfaceOnly>                <useBeanValidation>true</useBeanValidation>                <dateLibrary>java8</dateLibrary>                <java8>true</java8>              </configOptions>              <ignoreFileOverride>${project.basedir}/.openapi-generator-ignore</ignoreFileOverride>            </configuration>          </execution>        </executions>      </plugin>

Также все это можно выполнить с помощью командной строки.

Запустив джарник codegen и задав команду help можно увидеть команды, которые предоставляет нам Swagger Codegen:

  • config-help - Справка по настройке для выбранного языка

  • generate - Сгенерировать код с указанным генератором

  • help - Отображение справочной информации об openapi-generator

  • list - Перечисляет доступные генераторы

  • meta - Генератор для создания нового набора шаблонов и конфигурации для Codegen. Вывод будет основан на указанном вами языке и будет включать шаблоны по умолчанию.

  • validate - Проверить спецификацию

  • version - Показать информацию о версии, используемую в инструментах

Для нас самые нужные команды это validate, которая быстро проверять на валидность спецификации и generate,с помощью которой мы можем сгенерировать Client на языке Java

  • java -jar openapi-generator-cli-4.3.1.jar validate -i openapi.yaml

  • java -jar openapi-generator-cli-4.3.1.jar generate -i openapi.yaml -g java --library jersey2 -o client-gener-new

Swagger UI

Swagger UI - позволяет визуализировать ресурсы API и взаимодействовать с ними без какой-либо логики реализации. Он автоматически генерируется из вашей спецификации OpenAPI (ранее известной как Swagger), а визуальная документация упрощает внутреннюю реализацию и использование на стороне клиента.

Вот пример Swagger UI который визуализирует документацию для моего pet-project:

Нажавши на кнопку "Try it out", мы можем выполнить запрос за сервер и получить ответ от него:

Swagger Editor

Swagger Editor - позволяет редактировать спецификации Swagger API в YAML внутри вашего браузера и просматривать документацию в режиме реального времени. Затем можно сгенерировать допустимые описания Swagger JSON и использовать их с полным набором инструментов Swagger (генерация кода, документация и т. Д.).

На верхнем уровне в спецификации OpenAPI 3.0 существует восемь объектов. Внутри этих верхнеуровневых объектов есть много вложенных объектов, но на верхнем уровне есть только следующие объекты:

  1. openapi

  2. info

  3. servers

  4. paths

  5. components

  6. security

  7. tags

  8. externalDocs

Для работы над документацией со спецификацией используется онлайн-редактор Swagger Редактор Swagger имеет разделенное представление: слева пишем код спецификации, а справа видим полнофункциональный дисплей Swagger UI. Можно даже отправлять запросы из интерфейса Swagger в этом редакторе.

Редактор Swagger проверит контент в режиме реального времени, и укажет ошибки валидации, во время кодирования документа спецификации. Не стоит беспокоиться об ошибках, если отсутствуют X-метки в коде, над которым идет работа.

Первым и важным свойством для документации это openapi. В объекте указывается версия спецификации OpenAPI. Для Swagger спецификации это свойство будет swagger:

 openapi: "3.0.2"

Объект info содержит основную информацию о вашем API,включая заголовок, описание, версию, ссылку на лицензию, ссылку на обслуживания и контактную информацию. Многие из этих свойство являются не обязательными.

info:  title: "OpenWeatherMap API"  description: "Get the current weather, daily forecast for 16 days, and a three-hour-interval forecast for 5 days for your city."  version: "2.5"  termsOfService: "https://openweathermap.org/terms"  contact:  name: "OpenWeatherMap API"    url: "https://openweathermap.org/api"    email: "some_email@gmail.com"  license:    name: "CC Attribution-ShareAlike 4.0 (CC BY-SA 4.0)"    url: "https://openweathermap.org/price"

Объект servers указывает базовый путь, используемый в ваших запросах API. Базовый путь - это часть URL, которая находится перед конечной точкой. Объект servers обладает гибкой настройкой. Можно указать несколько URL-адресов:

servers:  - url: https://api.openweathermap.org/data/2.5/        description: Production server  - url: http://beta.api.openweathermap.org/data/2.5/        description: Beta server  - url: http://some-other.api.openweathermap.org/data/2.5/        description: Some other server

paths - Это та же конечная точка в соответствии с терминологии спецификации OpenAPI. Каждый объект path содержит объект operations - это методы GET, POST, PUT, DELETE:

paths:  /weather:     get:

Объект components уникален среди других объектов в спецификации OpenAPI. В components хранятся переиспользуемые определения, которые могут появляться в нескольких местах в документе спецификации. В нашем сценарии документации API мы будем хранить детали для объектов parameters и responses в объекте components

Conclusions

  • Документация стала более понятней для бизнес юзера так и для техническим юзерам (Swagger UI, Open Specifiation)

  • Может генерировать код для Java, PHP, .NET, JavaScrypt (Swager Editor, Swagger Codegen)

  • Можно проверять насколько совместимы изменения. Можно настраивать это в дженкинсе

  • Нет ни какой лишней документации к коде, код отдельно, документация отдельно

Подробнее..
Категории: Java , Api , Spring , Swagger , Openapi

Кастомная (де) сериализация даты и времени в Spring

24.02.2021 18:11:35 | Автор: admin

Представьте довольно распространённую ситуацию: ваше приложение взаимодействует с клиентами, которые находятся в разных часовых поясах. Вам часто приходится работать с датами, а для корректной работы системы, они передаются с указанием часового пояса отправителя. При этом, вам нужно:

  1. При получении запроса привести дату к серверному времени и работать с ней, а также сохранять в базу данных в таком виде

  2. В ответ возвращать дату и время с указанием серверного часового пояса

Для решения этой задачи Spring предоставляет удобный механизм для написания кастомной сериализации и десериализации. Главным его преимуществом является возможность вынести преобразования дат (и других типов данных) в отдельный конфигурационный класс и не вызывать методы преобразования каждый раз в исходном коде.

Десериализация

Для того, чтобы Spring понимал, что именно наш класс нужно использовать для (де)сериализации, его необходимо пометить аннотацией @JsonComponent

Ну а чтобы код был максимально кратким, я буду использовать внутренний статический класс, который должен быть унаследован от JsonDeserializerи параметризован нужным нам типом данных. Поскольку JsonDeserializerэто абстрактный класс, нам необходимо переопределить его абстрактный метод deserialize()

@JsonComponentpublic class CustomDateSerializer {        public static class LocalDateTimeDeserializer extends JsonDeserializer<LocalDateTime> {            @Override        public LocalDateTime deserialize(JsonParser jsonParser, DeserializationContext deserializationContext) {            return null;        }    }}

Из параметров метода получаем переданную клиентом строку, проверяем её на null и получаем из неё объект класса ZonedDateTime

public LocalDateTime deserialize(JsonParser jsonParser, DeserializationContext deserializationContext) {    String date = jsonParser.getText();    if (date.isEmpty() || isNull(date) {        return null;    }    ZonedDateTime userDateTime = ZonedDateTime.parse(date);}

Для получения разницы во времени, у переменной userDateTime нужно вызвать метод withZoneSameInstant() и передать в него текущую серверную таймзону. Нам остаётся лишь преобразовать полученную дату кLocalDateTime

Для надежности, предположим, что нам может прийти дата без таймзоны, либо вообще некорректные данные. Для этого случая, добавим обработку исключений. Полностью десериализатор будет выглядеть так

public static class LocalDateTimeDeserializer extends JsonDeserializer<LocalDateTime> {    @Override    public LocalDateTime deserialize(JsonParser jsonParser, DeserializationContext deserializationContext) throws IOException {        String date = jsonParser.getText();        if (date.isEmpty()) {            return null;        }        try {            ZonedDateTime userDateTime = ZonedDateTime.parse(date);            ZonedDateTime serverTime = userDateTime.withZoneSameInstant(ZoneId.systemDefault());            return serverTime.toLocalDateTime();        } catch (DateTimeParseException e) {            try {                return LocalDateTime.parse(date);            } catch (DateTimeParseException ex) {                throw new IllegalArgumentException("Error while parsing date", ex);            }        }    }}

Предположим, что серверное времяUTC+03. Таким образом, когда клиент передаёт дату 2021-01-21T22:00:00+07:00, в нашем контроллере мы уже можем работать с серверным временем

public class Subscription {    private LocalDateTime startDate;      // standart getters and setters}
@RestController public class TestController {    @PostMapping  public void process(@RequestBody Subscription subscription) {    // к этому моменту поле startDate объекта subscription будет равно 2021-01-21T18:00  }}

Сериализация

С сериализацией алгоритм действий похожий. Нам нужно унаследовать класс от JsonSerializer, параметризовать его и переопределить абстрактный метод serialize()

Внутри метода мы проверим нашу дату на null, добавим к ней серверную таймзону и получим из неё строку. Остаётся лишь отдать её клиенту

public static class LocalDateTimeSerializer extends JsonSerializer<LocalDateTime> {    @Override    public void serialize(LocalDateTime localDateTime, JsonGenerator jsonGenerator, SerializerProvider serializerProvider) throws IOException {        if (isNull(localDateTime)) {            return;        }        OffsetDateTime timeUtc = localDateTime.atOffset(ZoneOffset.systemDefault().getRules().getOffset(LocalDateTime.now()));        jsonGenerator.writeString(timeUtc.toString());    }}

Круто? Можно в прод? Не совсем. В целом, этот код будет работать, но могут начаться проблемы, если серверная таймзона будет равна UTC+00. Дело в том, что конкретно для этого часового пояса id таймзоны отличается от стандартного формата. Посмотрим в документацию класса ZoneOffset

Таким образом, имея серверную таймзону UTC+03, на выходе мы получим строку следующего вида: 2021-02-21T18:00+03:00.Но если же оно UTC+00, то получим 2021-02-21T18:00Z

Поскольку мы работаем со строкой, нам не составит труда немного изменить код, дабы на выходе мы всегда получали дату в одном формате. Объявим две константы одна из них будет равна дефолтному id UTC+00, а вторая которую мы хотим отдавать клиенту, и добавим проверку - если серверное время находится в нулевой таймзоне, то заменим Z на +00:00. В итоге наш сериализотор будет выглядеть следующим образом

public static class LocalDateTimeSerializer extends JsonSerializer<LocalDateTime> {    private static final String UTC_0_OFFSET_ID = "Z";    private static final String UTC_0_TIMEZONE = "+00:00";    @Override    public void serialize(LocalDateTime localDateTime, JsonGenerator jsonGenerator, SerializerProvider serializerProvider) throws IOException {        if (!isNull(localDateTime)) {            String date;            OffsetDateTime timeUtc = localDateTime.atOffset(ZoneOffset.systemDefault().getRules().getOffset(LocalDateTime.now()));            if (UTC_0_OFFSET_ID.equals(timeUtc.getOffset().getId())) {                date = timeUtc.toString().replace(UTC_0_OFFSET_ID, UTC_0_TIMEZONE);            } else {                date = timeUtc.toString();            }            jsonGenerator.writeString(date);        }    }}

Итого

Благодаря встроенным механизмам спринга мы получили возможность автоматически конвертировать дату и время в требуемом формате, без каких-либо явных вызовов методов в коде

Полностью исходный код можно посмотреть здесь

Подробнее..
Категории: Java , Spring , Json , Maven , Spring-boot , Serialization , Date , Deserialization

Документируй это

08.05.2021 12:05:15 | Автор: admin

Всем привет! В данной статье хотел бы рассмотреть инструменты документирования в принципиально разных подходах в разработке REST API, а именно для CodeFirst - инструменты SpringRestDocs (а также его надстройку SpringAutoRestDocs) и для ApiFirst - инструменты экосистемы Swagger(Open-Api).

Дисклеймер: В подробности холивара на тему что же лучше CodeFirst или ApiFirst я вдаваться не будут, а постараюсь продемонстрировать возможную практику документации в обоих вариантах.

CodeFirst плюс SpringAutoRestDocs

Как уже описывали в статье про SpringRestDocs это инструмент достаточно широкого использования, позволяющий генерировать различную документацию (аскедок, хтмл и т.д.) на основе тестов. Пожалуй один из немногих недостатков этого инструмента, является его многословность в тестах, а именно - необходимо описывать каждый параметр, каждое поле и т.д. В свою очередь тесы в SpringAutoRestDocs, используя JSR и Spring аннотации, а также Javadoc, становятся более коротким и немногословными.

Чуть более подробно про SpringAutoRestDocs

SpringAutoRestDocs это надстройка над SpringRestDocs, которая ставит своей целью уменьшение написания кода и документации. Основное преимущество этого иструмента - является меньшее количество написанной документации и большая связаность с рабочим кодом.

Некоторые из фичей инструмента:

  • Автоматическое документирования полей запроса и ответа, хедеров и параметров запроса с использованием Jackson, а также описательной части на основе Javadocs

  • Автоматическое документирование опциональности и ограничения полей по спецификации JSR-303

  • Возможность кастомизации итоговых снипеттов

Подробнее можно почитать в официальной документации.

Для демонстрации возьмем классический Swagger PetStore (с небольшой модернизацией, подробно можно посмотреть спеку в репозитории) и имплементируем несколько методов контроллера (addPet, deletePet, getPetById). В статье будет приведен пример на основе одного метода getPetById

Контроллер:

@RestController@RequiredArgsConstructorpublic class PetController implements PetApi {    private final PetRepository petRepository;        @Override    public ResponseEntity<Pet> getPetById(Long petId) {        return new ResponseEntity<>(petRepository.getPetById(petId), HttpStatus.OK);    }  //и другие имплементированные методы}

Репозиторий является обычным листом с несколькими методами доступа.

Базовые настройки для тестовой автодокументации:

Для начала нам необходимо определить базовый класс для всех тестов, который опишет основные правила нашей автоматической документации. Основное что нам понадобится, это сконфигурированный MockMvc (более подробно можно посмотреть в репозитории):

@Beforevoid setUp() throws Exception {  this.mockMvc = MockMvcBuilders    .webAppContextSetup(context)    .alwaysDo(prepareJackson(objectMapper, new TypeMapping()))    .alwaysDo(commonDocumentation())    .apply(documentationConfiguration(restDocumentation)           .uris().withScheme("http").withHost("localhost").withPort(8080)           .and()           .snippets().withTemplateFormat(TemplateFormats.asciidoctor())           .withDefaults(curlRequest(), httpRequest(), httpResponse(),                         requestFields(), responseFields(), pathParameters(),                         requestParameters(), description(), methodAndPath(),                         section(), links(), embedded(), authorization(DEFAULT_AUTHORIZATION),                         modelAttribute(requestMappingHandlerAdapter.getArgumentResolvers())))    .build()  }protected RestDocumentationResultHandler commonDocumentation(Snippet... snippets) {  return document("rest-auto-documentation/{class-name}/{method-name}", commonResponsePreprocessor(), snippets)  }protected OperationResponsePreprocessor commonResponsePreprocessor() {  return preprocessResponse(replaceBinaryContent(), limitJsonArrayLength(objectMapper), prettyPrint())  }
Чуть более подробно про настройки MockMVC

WebApplicationContext получаем от @SpringBootTest

prepareJackson(objectMapper, new TypeMapping()) позволяет настроить ResultHandler, который подготовит наши pojo для библиотеки документирования

withDefaults(curlRequest(), httpRequest(), и т.д.) набор сниппетов, которые будут сгенерированы

commonDocumentation() описывает директорию, куда в build папке разместятся сгенерированные сниппеты, а также препроцессинг ответа контроллера.

Непосредственно сам тест:

Пример теста более подробно можно посмотреть в репозитории.

@Testvoid getPetTest() {//givendef petId = 1L//whendef resultActions = mockMvc.perform(RestDocumentationRequestBuilders.get("/pet/{petId}", petId).header("Accept", "application/json"))//thenresultActions.andExpect(status().isOk()).andExpect(content().string(objectMapper.writeValueAsString(buildReturnPet())))}

Здесь приведен стандартный MockMvc тест, с ожидаемым статусом и ожидаемым телом ответа.

Итого на выходе:

Набор снипеттов с "главным" сниппетом под названием auto-section.adoc (который содержит информацию из всех остальных, указанных в настройках MockMVC) из которых позже можно собрать общий index.adoc для всех методов API. Готовая структура сниппетов:

Готовые сниппеты документы можно посмотреть в репозитории: сниппеты, html сгенеренный на основе сниппетов.

Также при настройках библиотеки мы можем изменять шаблоны либо добавлять свои сниппеты и SprinAutoRestDocs их распознает и воспроизведет ту функциональность, что вам нужна. Дока кастомизации сниппетов, констрейнтов.

Чуть подробнее про кастомизацию сниппетов и ограничений

Функционал кастомизации в SpringAutoRestDocs базируется на таковом же в SpringRestDocs.

К примеру русификация шапок сниппетов и описание ограничений:

ApiFirst плюс Swagger

Как уже описывалось во множестве статей (пример1, пример2) swagger - это open-source проект, включающий OpenApi Specification и широкий набор инструментов для описания, визуализации и документирования REST api.

Чуть более подробно про Swagger

Swagger состоит из двух основных частей - это OpenApi Specification и Swagger Tools.

  • OpenApi Specification - это спецификация описывающая процесс создания REST контракта для более простого процесса разработки и внедрения API. Спецификация может быть описана в формате YAML и JSON. Описание базового синтаксиса, а также более подробную информацию можно изучить по ссылке.

  • Swagger Tools - это инструменты визуализации, документации и генерации клиентно-серверной части REST api. Состоят из трех основных блоков: Swagger Editor(браузерный эдитор, для более удобного написания контракта с поддержкой валидации ситаксиса), Swagger UI(рендер спецификации в качестве интерактивной документации API), Swagger Codegen(генератор серверно-клиентной части, а также некоторых типов документаций)

Ниже мы рассмотрим мульти-модульный проект со следущей структурой: библиотека со свагер генератором (swagger-library), стартер с swagger-ui(swagger-webjar-ui-starter), приложение которое имплементирует классы библиотеки(spring-auto-rest-docs).

Для демонстрации возможностей Swagger возьмем классический Swagger PetStore из примера SpringAutoRestDocs выше.

Настройки build.gradle для модуля библиотеки:

Для реализации генерации server stub и документации на основе Swagger контракта используем OpenApi Generator.

Чуть более подробно про OpenApi Generator

В модуле используется gradle плюс gradle plugin OpenApi Generator.

Сам плагин дает возможность генерить как серверно-клиентную часть, так и различные форматы документации. Более подробно можно посмотреть в ссылке на репозиторий.

Основная таска для генерации библиотеки и ее настройки:

openApiGenerate {    generatorName = 'spring'    inputSpec = specFile    outputDir = "${project.projectDir}/"    id = "${artifactId}"    groupId = projectPackage    ignoreFileOverride = ignoreFile    apiPackage = "${projectPackage}.rest.api"    invokerPackage = "${projectPackage}.rest.invoker"    modelPackage = "${projectPackage}.rest.model"    configOptions = [            dateLibrary            : 'java8',            hideGenerationTimestamp: 'true',            interfaceOnly          : 'true',            delegatePattern        : 'false',            configPackage          : "${projectPackage}.configuration"    ]}
Чуть более подробно про настройки таски openApiGenerate

Незабываем выполнять генерацию кода до компиляции проекта:

task codegen(dependsOn: ['openApiGenerate', 'copySpecs'])compileJava.dependsOn(codegen)compileJava.mustRunAfter(codegen)

Копируем спеки в ресурсы, чтобы была позже возможность отобразить UI прямо из спек:

task copySpecs(type: Copy) {    from("${project.projectDir}/specs")    into("${project.projectDir}/src/main/resources/META-INF/specs")}

При необходимости также можно сгенерить Asciidoc или Html2.

Swagger-ui стартер:

Стартер добавляет в регистр ресурсов спеки с определенными в дефолтными настройками и webjar swagger-ui с измененным путем до дефолтного контракта.

Rest-docs API:

В самом приложении достаточно имплементировать сгенерированный интерфейс и переопределить настройки UI стартера:

@RestController@RestController@RequiredArgsConstructorpublic class PetController implements PetApi {    private final PetRepository petRepository;        @Override    public ResponseEntity<Pet> getPetById(Long petId) {        return new ResponseEntity<>(petRepository.getPetById(petId), HttpStatus.OK);    }  //и другие имплементированные методы}
swagger:  ui:    indexHandler:      enabled: true      resourceHandler: "/api/**"    apis:      - url: http://localhost:8080/specs/some_swagger.yaml        name: My api

Итого на выходе:

Server stub - готовая библиотека с сущностями и интерфейсом для реализации серверной части API.

Swagger UI - с помощью которого мы получаем наглядную визуализацию API и возможность направлять запросы прямо из UI:

Также примеры Asciidoc или Html2 из самого swagger контракта:

Заключение:

Что дает SpringAutoRestDocs:

  • Возможность хранить документацию как в проекте (к примеру в форме собранного index.html из множества сниппетов), так и в любом другом удобном месте.

  • Документация и модель данных всегда синхронизирована с кодом, так как документация генерируется на основе "зеленых" тестов контроллера.

  • Возможность кастомизации сниппетов и ограничений.

Что дает Swagger:

  • Единый артефакт на всех этапах разработки.

  • Документация и модель данных всегда синхронизирована с кодом, так как код генерируется на основе контракта.

  • Возможность использовать UI, в котором будет вся та же информация, что в контракте с возьможностью направлять запросы.

Какой бы вы не выбрали путь разработки, инструменты выше практически всегда позволят вам содержать актуальную документацию, тесно связанную с рабочим кодом.

Подробнее..
Категории: Java , Api , Spring , Documentation , Swagger , Spring auto rest docs

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru