Валентин

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

this.replaceStandardHtmlEntities = (text) => {
  // маскируем ссылки
  text = text.replace(/\<a([^\>]*)\>/g, String.fromCharCode(1) + 'a$1' + String.fromCharCode(1));
  text = text.replace(/\<\/a\>/g, String.fromCharCode(1) + '/a' + String.fromCharCode(1));

  // остальной код без изменений
  let regular = /( {2}|&|'|<|>|\\n)/g, translate = {
    '  ': '&nbsp',
    '&': '&amp',
    '\'': '&quot',
    '<': '&lt',
    '>': '&gt',
    '\\n': '<br>'
  };

  // результат замены передаем в переменную
  let result = (text.replace(regular, (match, entity) => {
    return translate[entity];
  }));
  
  // возвращаем ссылки обратно
  result = result.replace(/\x01a([^\x01]*)\x01/g, '<a$1>');
  result = result.replace(/\x01\/a\x01/g, '</a>');
  
  return result;
};

Смотреть в JSFiddle

Category parentCategory = entityManager.find(Category.class, 1);

Здесь вероятно вместо 1 нужно поставить parentId.

И ответ на ваш вопрос: вместо ручного инкремента largestIndex вам нужно использовать id последней добавленной записи.

Кстати раз уж вы используете hibernate то посмотрите в сторону Closure Table, этот паттерн как мне кажется более органично смотрится с hibernate.

Вот пример кода с id(обязательно обернуть в транзакцию):

public ResponseMessage addCategory(List<Category> newCategoryList, int parentId) {
    Category parentCategory = parentId == 0 ? null : entityManager.find(Category.class, parentId);

    for (Category category : newCategoryList) {
        entityManager.persist(category);
        entityManager.flush();
        if (parentCategory != null) {
            category.setPath(parentCategory.getPath() + "." + category.getId());
            category.setParent(parentCategory);
        } else {
            category.setPath(String.valueOf(category.getId()));
        }
    }
    return new ResponseMessage(true, " ");
}

1. Если characteristic_value привязано к subject_model, characteristic_name (почему бы не назваьть эту таблицу просто characteristics, ведь там может храниться еще что-то кроме имени) можно не привязывать к subject. Этим достигается независимость характеристик от субъекта и отсутствие дублей среди характеристик.
   
2. Что-бы при назначении значения характеристики модели можно было производить проверку на то, возможна ли вообще такая характеристика для субъекта, нужно ввести кросс-таблицу subject_characteristics (характеристики субъектов), которая бы имела внешние ключи к subject и characteristic_name, то есть many-to-many зависимость между ними, через отдельную кросс-таблицу.
   
3. У вас всего два фиксированных уровня иерархии. Что, если на практике потребуется больше? Вы, кажется, стремитесь создать гибкую/универсальную систему. Тогда вам нужна динамическая иерархия категорий.
   
4. Если view служит для представления, то внешний ключ к нему в characrteristic_name не нужен, так как логически характеристика, как единица учета, не подчинена представлению данных. Опять же лучше ввести many-to-many зависимость между характеристиками и представлениями, реализованную через кросс-таблицу. Подсистема представлений при этом остается полностью независимой ото основной структуры данных (ее можно убрать не нарушая структуру).
   

P.S.: Интересно, в каком это смысле дрель (инструмент) может быть субъектом.

Делайте по-правильному, через /admin/... . Если есть трудности, то почитайте этот ответ с SO.
В самой документации ангуляра есть пример

Делал так.
Возвращаю статику:

@RequestMapping(path = {"film/*", "serial/*"}, method = RequestMethod.GET)
    public String index() {
        return "forward:/index.html";
    }

Обращаюсь к rest:

@RestController
@RequestMapping("/rest/content")
public class ContentController {

    @RequestMapping(method = RequestMethod.GET)
    public HttpStatus searchContent(@Param("name") String name) {
        System.out.println("search for content with param: " + name);
        return HttpStatus.ACCEPTED;
    }

    @RequestMapping(method = RequestMethod.POST)
    public HttpStatus uploadContent(@RequestBody Content content) {
        System.out.println("upload content");
        return upload != null ? HttpStatus.CREATED : HttpStatus.BAD_REQUEST;
    }
}

require('es6-promise!./about/about')('About')

что же это за чудо такое?

Попробуем разобраться. Заходим на документацию к вебпаку тык.

Т.е. эта конструкция require('es6-promise!./about/about') является вызовом загрузки модуля с помощью переопределенного лоадера, а не просто лоадера, который прописан в webpack.config.js этой сборки

loaders: [
  // See: https://github.com/s-panferov/awesome-typescript-loader
  {test: /\.ts$/, loader: 'awesome-typescript-loader', exclude: [/\.(spec|e2e)\.ts$/]},

Идем в исходники es6-promise-loader, который как раз у нас является одной из devDependencies сборки. Там можно маленько посмеяться над комментариями).
Смотрим, что тут, ага - это pitch лоадер, который делает обертку es6-promise. А внутри метод из вебпака ensure, который позволяет отделять chunk и загружать его динамически. В итоге получается примерно такой модуль (пути я порезал маленько)



Т.е. require('es6-promise!./about/about') грубо говоря превращается в функцию с параметром namespace. И вобщем когда придет время сдерживать своё обещание и возвращать модуль, то сработает следующее выражение
require("......app\\about\\about.ts")[namespace]
Require вернет нам как раз наш exports объект, который мы возвращаем в about.ts
export class About {
Смотрим на практике

А к свойству объекта мы уж по namespace сможем легко обратиться. Именно поэтому там 'About'.

Если напишете about, то не видать вам

ngOnInit() {
  console.log('hello `About` component');
}

из компонента

@Autowired
private UserService service;

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

И там же явно сказано в конце этой нескончаемой портянки:

Can not set com.springapp.mvc.DAO.UserDaoImpl field com.springapp.mvc.Service.UserServiceImpl.userDaoImpl to com.sun.proxy.$Proxy37

В случае insert я бы посоветовал использовать метод persist вместо merge

Я вам не скажу за всю Одессу, но у нас в Сибири считается, что
1) @GeneratedValue(strategy = GenerationType.TABLE) - говорит, что нужно использовать таблицу для генерации PK. Не таблицу, на которую маппится сущность, а просто таблицу. Отсюда и возникает таблица hibernate_sequences. И возникает она из-за hibernate.hbm2ddl.auto=update.
2) Про длину колонки, это опять из-за hibernate.hbm2ddl.auto=update.
3) @Transaction говорит, что метод будет транзакционным. Что это значит. Это значит, что вызов метода будет обернут в proxy объект, у которого будет сессия, и при вызове всех вложенных методов эта сессия будет одна и та же, и при завершении метода транзакция закроется.
4) propagation = Propagation.REQUIRED - это означает, что наличие сессии при вызове метода обязательно, если ее нету, то hibernate попытается ее создать.
5) Откат транзакции (rollbak грубо говоря) происходит, по-умолчанию, только в случае возникновения RuntimeException, как этим управлять написано в документации к hibernate.
6) значение в аннотации @Repository("personDao") задает имя бина.

Теперь по классике надо что-то по советовать. Советую Вам не использовать hibernate.hbm2ddl.auto=update. Лучше посмотрите в сторону liquibase для управления состоянием БД.
И почитайте вводные туториалы по Spring, разберитесь как работает IoC в Spring, как работает AOP в Spring, как Spring управляет бинами. И тогда Вам станет все понятно.

Дерзайте, удачи Вам!

И лисенер, и диспетчер поднимают ApplicationContext. Сначала поднимает лисенер, далее диспатчер поднимает дочерний контекст. Таким образом в бинах, подгружаемых диспатчером, можно делать референсы на бины, загружаемые лисенером.
Главный вопрос - зачем?
Для секьюрити. В лисенере прописывается спринг секьюрити конфигурация, а в диспатчере бины из spring mvc. Т.о. бины из приложения могут использовать бины для секьюрити, но не наоборот.
Подробнее можно почитать в какой-нибудь книге по спринг секьюрити, например Spring Security 3.1.