Александр Косарев

Никакого Swing и никаких настольных разработок - в мире Java это очень слабо востребованное направление. "Изучаем Java" - книга хорошая, но её мало для начала серьёзной разработки. Она скорее полезна для подготовки к прочтению книг Шилдта, Хорстмана и Гослинга. "Философия Java" очень доступно рассказывает о Java, но только о 6 версии.
Для подготовки к собеседованию можно почитать книги для подготовки к экзаменам OCAJP/OCPJP (например), всё основное и самое важное там есть.
Так же рекомендую ознакомиться с азами веб-профиля Java EE (сервлеты, JSP).

JavaRush в целом, если смириться с косяками в структуре лекций, очень хорошо подходит.

Что бы получать наборы связанных объектов (@OneToMany и @ManyToMany) нужно указать fetch=FetchType.EAGER в аннотации связи. Это удобно, но есть подводный камень - количество выполняемых запросов к БД увеличится, ровно как и объёмы передаваемых данных.

Второй вариант с точки зрения ООП однозначно правильнее. Ответ на вопрос: да, правильно.

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

Возможно ли обойтись без контроллеров?

Можно, но с ними проще и правильнее. И вообще, какие аргументы против?

Какие библиотеки следует использовать?

Java EE (Jersey например) или Spring Web

Как это реализовать максимально просто?
На Spring:

@RestController
@RequestMapping("/books")
public class BooksService {
    @Autowired
    private BooksRepository booksRepository;

    /**
     *  Список книг
     */
    @RequestMapping
    public ResponseEntity list() {
        return ResponseEntity.ok(booksRepository.findAll());
    }

    /**
     *  Добавление новой книги
     */
    @RequestMapping(method = RequestMethod.POST)
    public ResponseEntity create(@RequestBody Book book) {
        return ResponseEntity.ok(booksRepository.save(book));
    }

    /**
     *  Получение существующей книги
     */
    @RequestMapping("/{id}")
    public ResponseEntity get(@PathVariable String id) {
        if (bookRepository.exists(id)) {
            return ResponseEntity.ok(booksRepository.save(book));
        }

        return ResponseEntity.notFound().build();
    }
}

В данном случае используется ещё Spring Data JPA.

Вот здесь описывается то, что ты хочешь сделать. В целом это можно использовать, но по-моему использование Spring Data MongoDB выглядит удобнее.

Ну, а насчёт конфигураций в XML или Java - кому как нравится.

UPD java-конфиг Mongo

@Configuration
@EnableMongoRepositories
public class MongoConfiguration extends AbstractMongoConfiguration {

    @Override
    protected String getDatabaseName() {
        return "dataBaseName";
    }

    @Override
    public Mongo mongo() throws Exception {
        return new MongoClient("127.0.0.1", 27017);
    }

    @Override
    protected String getMappingBasePackage() {
        return "foo.bar.domain";
    }
}

Аннотация @Service указывает Spring, что нужно создать экземпляр данного класса и положить его в контекст приложения.

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

Если интересно почитать про архитектуру, то советую почитать Изучаем Java EE 7 Э. Гонсалвес и официальную документацию.

Java EE определяет большое количество спецификаций для работы с различными технологиями, например для работы с БД - спецификация JPA (Java Persistence API), которая описывает стандартный ORM-фреймворк.

В Java EE приложение не обязательно должно быть веб-приложением. Классическое JEE-приложение разворачивается в сервере приложений, при помощи которого можно управлять жизненным циклом и настройками приложений. Сервер приложений сам находит классы, инстансы которых нужно создать. Application-класс для таких приложений не предусмотрен.

Но в последнее время, в виду популярности микросервисов, появилась возможность разрабатывать standalone-приложения на Java EE, вот в таких микросервисах нужен Application-класс.

Кроме Java EE для интерпрайза в Java-мире существует Spring.io с собственной экосистемой. Приложение на Spring может быть как обычным веб-приложением (с веб-профилем или с полным профилем Java EE), так и микросервисом с Application-классом (обычно Spring Boot, но можно и без него).

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

Насколько я знаю - нет, готового механизма нет в PGPoolingDataSource. И вообще, он официально не рекомендуется к использованию. Если пул соединений не нужен, то лучше использовать PGSimpleDataSource, если же пул нужен, то нужно использовать HikariCP, C3P0 или хотя бы DBCP.

Вот это:

<c:set var="array" value="${pageContext.request.contextPath}/spring_link/getarray"/>

создаёт в JSP переменную array с строкой равной ${pageContext.request.contextPath}/spring_link/getarray

Скажу даже больше - из представления, возвращённым не контроллером Spring WebMVC, невозможно получить данные из контроллеров (если точнее, то можно, но это костыли). В стандартном WebMVC контроллер решает, какое представление отдавать и какие данные передавать представлению через модели. Это тебе не JSF/CDI, хотя если сильно хочется, то можно скрестить JSF/CDI со Spring, но это тоже извращения.

Правильный вариант один - контроллер возвращающий нужное представление и передающий в него нужные данные.

P.S.: зачем решать задачи способами, противоречащими устоявшимся концепциям?

Для начала: Java != Java EE. Прекращение разработки Java EE со стороны Oracle никак не повлияет на жизнь самого языка программирования. Есть вообще сомнения, что Oracle решится на этот шаг, т.к. у них самих большое количество проектов именно на Java EE разработано.

Плюс стоит помнить, что Java EE - это набор спецификаций, а не конкретная реализация. Java EE состоит из кучи JSR, которые обсуждаются и принимаются JCP (Java Community Process), то есть сообществом, в котором кроме самих Oracle есть Red Hat, IBM, Spring, Apache и многие другие. Oracle может просто передать управление Java EE сообществу. И да, новые JSR выходят вне зависимости от Java EE.

И стоит помнить, что на Java EE интерпрайз не кончается, ведь есть ещё Spring, который развивается гораздо быстрее и занимает существенную нишу на рынке.

Так что, учитывая сказанное выше, учить однозначно стоит, если есть желание.

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

Во-первых:

@Autowired
    private static GreetingServiceImpl greetingService;

у тебя greetingService является статическим. Внедрение зависимостей при помощи @Autowired работает не со свойствами/методами классов, а со свойствами/методами объектов.

Во-вторых класс Starter не является управляемым, соответственно, внедрение зависимости в объект этого класса невозможно. Да и объект этого класса ты не создаёшь.

Что бы твой пример заработал, в методе main класса Starter после создания контекста получи нужный компонент из контекста и вызови метод. Получится что-то вроде:

public static void main(String[] args) {
        logger.info("Starting configuration...");
        ApplicationContext context = new AnnotationConfigApplicationContext(LessonsConfiguration.class);
        logger.info(
                context.getBean(GreetingServiceImpl.class).sayGreeting()
        );
    }

И ещё у тебя на классе GreetingServiceImpl есть аннотация @Component, но при этом ты ещё и в конфигурации создаёшь компонент этого же класса. По-хорошему либо убери @Component, либо удали метод

@Bean
    public GreetingServiceImpl greetingService(){
        return new GreetingServiceImpl();
    }

Про внедрение зависимостей в Spring Framework я вкратце писал тут.