Pull to refresh

Comments 26

Кол-во XML в жабаразработках просто зашкаливает
Как человек, который писал усиленно на Spring, потом перешел на Guice, а теперь снова на Spring уже третий, могу сказать что xml это скорее добро. Чтобы собрать сложное приложение на guice, мне приходилось раза в три больше писать кода, чем на spring (это конечно за счет развитой инфраструктуры, когда все из коробки, но все рано — связывание бинов между собой это просто кайф).
а можно подробнее, почему перешли на spring3 с guice и чем xml так крут?
не холивара ради — сами на guice и все вроде бы отлично и кода уж точно не больше
Были проблемы, которые решались сначала на g, а потом полностью выкидывались когда перешли на spring. Но опять же это только из-за того что g это чистый ioc, а спринг это много всего из коробки.

1. Спринговые бины — это читый POJO, который соберется без спринга. Если guice использовать, то его надо всегда тащить с собой. Поэтому со спринга можно перейти на джус, а обратно тяжелее. Хрен какой довод, но все таки. И из-за того что только аннотации, то для интеграции со сторонними либами надо писать код для вызова методов или инициализации.

2. Spring Remoting — код состоит из интерфейса и реализации на сервере без какой либо зависимости на сторонние либы. Захотел jms общение с сервисом — берешь camel и синхронные и асинхронные вызовы интерфейсов получаешь сразу. Захотел через http — опять подкрутил xml и кайфуй — все unit test работают, ничего даже пересобирать не надо.

3. JDO template — без комментариев.

Собственно поэтому и перешел — для guice написал велосипедов или либ левых прикрутил мама дорогая, как смигрировал так слава богу все выкинул.

Ну и будущее osgi, хотя для GAE это не актуально собственно.
Зря вы аннотации игнорите, они гораздо удобнее чем xml-hell.
Аннотации хороши для статического задания конфигурации.
Они неприменимы, если конфигурация меняется в runtime, например.
Или если нужно уметь подменить конфигурацию без изменения исходников. Бывает, что требуется переконфигурять сервер без заливания новой, еще не до конца протестированной версии исходников.
Ну вроде как в нашем случае автор не собирался динамически подменять систему кеширования.
это проблема не джавы, а конкретного подхода к разработке: эмуляция кода при помощи более высокоуровневых средств (xml, к примеру). Это не всегда зло, но фанатизм в любом виде приводит к проблемам.
Термоядерно сложно и не очевидно, в этой каше потом никто не разберётся.
Я тоже несколько лет использовал spring, а теперь пишу на guice. Очень доволен.
Посмотрите выложенные исходники проектов которые пишут гугловые программисты. Они бы так не написали.
> Для этого не потребуется писать код, достаточно добавить конфигурации
> в xml файлы Spring'а и разметить код с помощью аннотаций.

По-моему лучше писать код, чем писать XML :-)
Кто бы мне рассказал, как по-человечески c jpa (entity relationships) и со связкой spring transaction management + jpa на AppEngine работать :-)
А что там за проблема? У меня вроде все заработало.
Связи с каскадированием, версионность, транзакции с более чем одной энтити в сессии — все это стандартным образом не взлетает и красивые ворараунды мною не найдены
Ключевые слова parent-pk, datanucleus.appengine.autoCreateDatastoreTxns false и KeyBuilder. Можно и про это статью написать…
Находилось, костыли липились… Сейчас как раз свое приложение разрабатываю spring+jpa+struts2+dwr on +gae. Только вот решения не особо красивыми получились, было бы интересно глянуть, как решаются проблемы коллегами.
А какой оверхед на возврат простого значения (строчка, например) из кеша AE?

В смысле? Сколько времени тратится на запрос к memcached?
Нужно добавить imlpements SampleDAO в SampleDAOImpl.
Спасибо, поправил.
А я отказался от Spring на GAE, из-за слишком долгого времени инициализации Spring'а.

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

Я для своего приложения написал свой кэш для DAO-уровня. Причем, из-за того, что обращение к mamcache занимает несколько десятков ms, я еще сделал промежуточный кэш, который делает lookup из локальной памяти, без обращения к memcache — гораздо быстрее все работать стало.
Ну в принципе я старался сохранить максимальную платформонезависимость и все работает через стандартные jsr107. Просто в конфигурации добавлены ключи, которые специфичны для GAE — namespace и expire.
    Среди прочих библиотек есть ehcache.sourceforge.net/
    Легко встраивается в Spring IoC Container через установку Ehcache manager.
    Конфигурится через ehcache.xml (максимальное число элементов в памяти, максимальное число элементов на диске, путь куда сохранять, время жизни, частота обновления — основные атрибуты).
    <encache...>
      <defaultCache .../>
      <cache name=«engroupCache»...>
      
    
    В Spring context добавляется 2 бина, первый это менеджер кеша, но не org.springmodules.cache.provider.jsr107.Jsr107CacheManagerFactoryBean а org.springframework.cache.ehcache.EhCacheManagerFactoryBean, где configLocation атрибут равен classpath:ehcache.xml, а второй это cacheProviderFacade, класса org.springmodules.cache.provider.ehcache.EhCacheFacade (где name=cacheManager ref=cacheManager).

@RunWith(EngroupClassRunner.class)
@ContextConfiguration(locations = { "/META-INF/spring/cache-context.xml" })
public class CacheTest {
    @Autowired
    protected CacheProviderFacade cacheProviderFacade;

    @Test
    public void testCacheConfiguration() {
        Assert.assertNotNull(cacheProviderFacade);

        EhCacheCachingModel model = new EhCacheCachingModel();
        model.setCacheName("engroupCache");

        cacheProviderFacade.putInCache("a", model, new Integer(1));
        Integer fromCache = (Integer) cacheProviderFacade.getFromCache("a",
                model);
        Assert.assertEquals(new Integer(1), fromCache);
    }
}


https://springmodules.dev.java.net/. — 10 минут для общего развития


Spring context:
<bean id="cacheManager"
 class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
 <property name="configLocation">
  <value>classpath:ehcache.xml</value>
 </property>
</bean>

<pre lang=«xml» xml:space=«preserve» xml:lang=«xml»>
<bean id=«cacheProviderFacade»
class=«org.springmodules.cache.provider.ehcache.EhCacheFacade»>
/>



encache.xml
<?xml version="1.0" encoding="UTF-8"?>

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="ehcache.xsd">

 <diskStore path="java.io.tmpdir" />

 <defaultCache maxElementsInMemory="10000" eternal="false"
  timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="true"
  diskSpoolBufferSizeMB="30" maxElementsOnDisk="10000000"
  diskPersistent="false" diskExpiryThreadIntervalSeconds="120"
  memoryStoreEvictionPolicy="LRU" />
 
 <cache name="engroupCache" maxElementsInMemory="10000"
  maxElementsOnDisk="10000000" eternal="false" overflowToDisk="true"
  diskSpoolBufferSizeMB="20" timeToIdleSeconds="300"
  timeToLiveSeconds="600" memoryStoreEvictionPolicy="LFU" />
</ehcache>


Ну это все замечательно, только в чем смысл этого здесь?
import org.springmodules.cache.CachingModel;

public class EhCacheCachingModel implements CachingModel {...}
вы привели пример JSR107 JCACHE реализации open-source ehcache модуля от Terracota. в вашем примере используется кеширование POJO. Смысл этого всего в том что кешировать можно объекты любого неординарного типа и существует довольно таки много настроек для Ehcache, реализованных via Spring as IoC container, только и всего
Sign up to leave a comment.

Articles