Java web

А кто раньше заставлял тебя ковыряться в xml'ках?

Java EE, конфигурируемая через xml?

3 автогенерируемые xml'ки, которые и сейчас никуда не делись?

beans.xml, web.xml, давай вспоминай, че там еще было до 6-7 версий? Не знаю что там куда делось или не девалось, потому что, к счастью, удается проекты на JEE обходить стороной, сейчас вместо beans.xml у меня конфиги спринга, а вместо web.xml — AbstractAnnotationConfigDispatcherServletInitializer. Не понимаю суть нашего спора. Раньше JEE вовсю конфигурировалась в xml, сейчас частично аннотациями, частично xml. Что ты пытаешься мне доказать?

В том, что в хмл тэгов больше, чем текста, когда с ним работаешь не особо часто, это боль в глазах. Да и в том же вэбе парсить json одно удовольствие.Но это субъективно, кто с чем привык работать, но вот давать возможность выбора в той же джее было бы неплохо. Я работаю на нескольких проектах и где-то json, где-то хмл, поэтому приходится подстраиваться.

AbstractAnno... бляяять

Спринговый класс, название в стиле его же naming conventions — если меньше 5-ти слов, то это просто несерьезно :)
А по удобству использования он уделывает web.xml совершенно не напрягаясь.

А persistence.xml уделает?

Что, нужно все пути к СУБД захардкодить и забыть?

В XML хранится информация, которая обеспечивает связь приложения со средой выполнения, и в отдельных случаях нащёлкивается мышкой и заполняется данными форм консоли управления сервером. Так вот, чтобы это всё не прщёлкивать каждый раз на каждом сервере, были введены XML. Но раньше их использовали и для конфигурации отношений между объектами (EJB 2.0) и СУБД, сейчас аннотации и DI взяли на себя часть конфигураций отношений/отображений, поэтому XML сейчас выполняет именно те функции, для чего, собственно, задумывался. (Хотя можно было бы использовать и JSON.)

И зачем ты это мне написал? Это ни разу не отвечает на мой вопрос почему большинство продолжают конфигурировать отношения между компонентами приложения XML'ем.

А persistence.xml уделает?

Можно использовать Hibernate, не написав ни строчки в persistence.xml. Вот, например, как делаю это я в своем проекте

@Configuration
@EnableTransactionManagement
@EnableJpaRepositories("com.ctv.registration.persistence")
@Import({PersistencePropertyConfig.class, PersistenceAdapterConfig.class})
public class PersistenceConfig {

    public static final String ENTITIES_LOCATION = "com.ctv.registration.adapter.persistence.model";

    @Value("${dbInitializerEnabled}")
    private boolean dataInit;

    @Autowired
    private DataSourcePropertiesHolder dataSourcePropertiesHolder;

    @Autowired
    private HibernatePropertiesHolder hibernatePropertiesHolder;

    @Bean
    public DataSource dataSource() {
        Properties dataSourceProperties = dataSourcePropertiesHolder.toProperties();
        HikariConfig config = new HikariConfig(dataSourceProperties);
        return new HikariDataSource(config);
    }

    @Bean
    public JpaTransactionManager transactionManager() {
        JpaTransactionManager transactionManager = new JpaTransactionManager();
        EntityManagerFactory entityManagerFactory = entityManagerFactory().getObject();
        transactionManager.setEntityManagerFactory(entityManagerFactory);
        return transactionManager;
    }

    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
        LocalContainerEntityManagerFactoryBean entityManagerFactoryBean = new LocalContainerEntityManagerFactoryBean();
        entityManagerFactoryBean.setDataSource(dataSource());
        entityManagerFactoryBean.setPackagesToScan(ENTITIES_LOCATION);
        entityManagerFactoryBean.setPersistenceProviderClass(HibernatePersistenceProvider.class);
        Properties jpaProperties = hibernatePropertiesHolder.toProperties();
        entityManagerFactoryBean.setJpaProperties(jpaProperties);
        return entityManagerFactoryBean;
    }

    @Bean
    public DataSourceInitializer dataSourceInitializer(DataSource dataSource, ResourceDatabasePopulator databasePopulator) {
        DataSourceInitializer initializer = new DataSourceInitializer();
        initializer.setDataSource(dataSource);
        initializer.setDatabasePopulator(databasePopulator);
        initializer.setEnabled(dataInit);
        return initializer;
    }

    @Bean
    public ResourceDatabasePopulator resourceDatabasePopulator() {
        ResourceDatabasePopulator databasePopulator = new ResourceDatabasePopulator();
        Resource resource = new ClassPathResource("data.sql");
        databasePopulator.setScripts(resource);
        databasePopulator.setContinueOnError(true);
        return databasePopulator;
    }

Что, нужно все пути к СУБД захардкодить и забыть?

Какие еще варианты ты можешь придумать? Все, что не хочется хардкодить, записано в файлике persistence-default.properties, который читается спрингом и распихивается в нужные проперти холдеры, которые и используются для конфигурации. Преимущество в том, что этот persistence-default.properties лежит себе тихо в ресурсах с самым низким приоритетом, и перечислено там практически все. Когда нужно настроить приложение под специфический энвайронмент, в класспасс кладется persistence.properties с только теми пропертями, которые нужно заоверрайдить, а именно специфическими для конечного энвайронмента. Если приложение запускается на компьютере разработчика, то у него в ~/.config/appname/persistence.properties данные, которые нужно заоверрайдить, а если нужно один раз запустить приложение, передав туда какой-то параметр ради теста, то можно запустить его так

java -Dkey=value -jar app.jar

# Data source
connectionTestQuery=SELECT 1
dataSourceClassName=org.postgresql.ds.PGPoolingDataSource
maximumPoolSize=80
dataSource.user=xxx
dataSource.password=xxx
dataSource.databaseName=xxx
dataSource.serverName=localhost

# Hibernate
hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
hibernate.hbm2ddl.auto=create
hibernate.show_sql=true


dbInitializerEnabled=true

Ты просто подменяешь валидируемый XML невалидируемым текстовиком (.proprties). И, как следствие, за глюки из-за опечаток и космических лучей отвечаешь сам. XML хотя бы поможет понять, где закралась ошибка.

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

Люто плюсую. Кстати, по опыту параметры конфигурации, предназначенные для изменения, всё равно часто выносят в подобные *.properties, даже при том, что остальная конфигурация живет XML. По той простой причине, что

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

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

Откуда станет очевидной проблема? Выхлопа-то нет — Спринг не запустился и всё. Рой .properties весь, пока найдёшь, в какой букве облажался.

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

А что ты предлагаешь, если db-провайдер поменяется и/или СУБД вынесется на другой сервер? Перекомпилировать код или отредактировать .properties?

Вот как это решается редактированием одного persistence.xml: http://not-accidental-chaos.blogspot.ru/p/persistencexml.html в стандартной JPA.

Не понимаю суть нашего спора. Раньше JEE вовсю конфигурировалась в xml, сейчас частично аннотациями, частично xml. Что ты пытаешься мне доказать?

Спринг не является частью jee, и раньше конфигурялся исключительно через xml. Я всего лишь говорю что «принуждение» к использованию xml в jee всегда ограничивалось парой весьма дубовых конфигов, в которые разработчик заглядывал раз в полгода. То что народ с радостью хватался за всякие библиотеки, которые требовали сотен xml к jee отношения не имеет никакого, более того, в тот момент считалось, что xml как язык конфигов лучше, эффективнее и читабельнее. Просто мода поменялась.

Откуда станет очевидной проблема? Выхлопа-то нет — Спринг не запустился и всё. Рой .properties весь, пока найдёшь, в какой букве облажался.

Изя, если не знаешь, то не нужно делать предположения, а потом убеждать себя, меня и всех остальных в их правильности. Будет что-то вроде

Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'jdbc.url' in string value «${jdbc.url}»

А что ты предлагаешь, если db-провайдер поменяется
Перекомпилировать код

Ты имеешь в виду jpa провайдер? Добавить новый провайдер в зависимости, перекомпилировать, запустить юнит тесты, затем запустить интеграционные тесты, передать приложение на тестирование QA парням, а только потом запускать версию в продакшен. Просто отредактировать persistence.xml не получится.

и/или СУБД вынесется на другой сервер
отредактировать .properties

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

Так все-таки приходилось? web.xml, beans.xml, persistence.xml, ejb-jar.xml — это немного. Но в больших проектах все эти xml-ники разрастались до довольно страшных размеров, для тестов некоторые приходилось повторять с небольшими изменениями, отсюда и такая нелюбовь к ним.