Примечания к выпуску Django 1.10 ¶

Полнотекстовый поиск с PostgreSQL ¶

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

Он также включает поддержку триграмм с использованием запросов trigram_similar и выражений TrigramSimilarity и TrigramDistance .

Промежуточное ПО нового стиля ¶

Был введен новый стиль промежуточного программного обеспечения для устранения отсутствия строгого стекирования запросов / ответов промежуточного программного обеспечения старого поколения, как описано в DEP 0005 . Чтобы воспользоваться преимуществами улучшений,необходимо адаптировать старое настраиваемое промежуточное ПО и перейти от настройкиMIDDLEWARE_CLASSES к новой настройкеMIDDLEWARE .

Официальная поддержка имен пользователей Unicode ¶

User Модель django.contrib.auth изначально только принятых ASCII букв и цифр в именах пользователей. Хотя это не был преднамеренный выбор, символы Unicode всегда принимались при использовании Python 3.

Валидатор имени пользователя теперь явно принимает символы Unicode по умолчанию только на Python 3.

Пользовательские модели пользователей могут использовать новые ASCIIUsernameValidator или UnicodeUsernameValidator .

Незначительные особенности ¶

API ядра СУБД ¶

• В поле ГИС AreaField используется неопределенный числовой тип, который на практике может быть любым числовым типом Python. Значения decimal.Decimal из базы данных теперь преобразованы в, float чтобы облегчить их комбинирование со значениями, используемыми библиотеками ГИС.
• Чтобы включить временное вычитание, вы должны установить supports_temporal_subtraction флаг функции базы данных True и реализовать DatabaseOperations.subtract_temporals() метод. Этот метод должен возвращать SQL и параметры , необходимый для вычисления разницы в микросекундах между lhs и rhs аргументами в типе данных , используемых для хранения DurationField .

select_related() запрещает нереляционные поля для вложенных отношений ¶

В Django 1.8 добавлена ​​проверка нереляционных полей в select_related() :

>>> Book.objects.select_related('title')
Traceback (most recent call last):
...
FieldError: Non-relational field given in select_related: 'title'

Но он не запрещал вложенные поля, не относящиеся к отношениям, как сейчас:

>>> Book.objects.select_related('author__name')
Traceback (most recent call last):
...
FieldError: Non-relational field given in select_related: 'name'

_meta.get_fields() возвращает согласованные обратные поля для прокси-моделей ¶

До Django 1.10 get_fields() метод возвращал разные обратные поля при вызове в модели прокси по сравнению с его конкретным прокси-классом. Это несоответствие было исправлено путем возврата полного набора полей, указывающих на конкретный класс или один из его прокси в обоих случаях.

AbstractUser.username max_length увеличена до 150 ¶

Перенос для django.contrib.auth.models.User.username включен. Если у вас есть пользовательская модель пользователя, наследующая от AbstractUser , вам необходимо создать и применить миграцию базы данных для вашей пользовательской модели.

Мы рассмотрели увеличение до 254 символов, чтобы упростить использование адресов электронной почты (которые ограничены 254 символами) в качестве имен пользователей, но отклонили это из-за ограничений MySQL. При использовании utf8mb4 кодировки (рекомендуется для правильной поддержки Unicode) MySQL по умолчанию может создавать уникальные индексы только с 191 символом. Поэтому, если вам нужна большая длина, используйте индивидуальную пользовательскую модель.

Если вы хотите сохранить ограничение в 30 символов для имен пользователей, используйте настраиваемую форму при создании пользователя или изменении имени пользователя:

from django.contrib.auth.forms import UserCreationForm

class MyUserCreationForm(UserCreationForm):
    username = forms.CharField(
        max_length=30,
        help_text='Required. 30 characters or fewer. Letters, digits and @/./+/-/_ only.',
    )

Если вы хотите сохранить это ограничение в админке, UserAdmin.add_form используйте эту форму:

from django.contrib.auth.admin import UserAdmin as BaseUserAdmin
from django.contrib.auth.models import User

class UserAdmin(BaseUserAdmin):
    add_form = MyUserCreationForm

admin.site.unregister(User)
admin.site.register(User, UserAdmin)

Прекращение поддержки PostgreSQL 9.1 ¶

Поддержка PostgreSQL 9.1 в апстрим-проектах заканчивается в сентябре 2016 года. В результате Django 1.10 установил 9.2 как минимальную официально поддерживаемую версию PostgreSQL.

Вывод runserver проходит через инфраструктуру логирования ¶

Обработка запросов и ответов на runserver команду отправляется в регистратор django.server, а не в sys.stderr . Если вы отключите конфигурацию ведения журнала Django или замените ее своей собственной, вам нужно будет добавить соответствующую конфигурацию ведения журнала, если вы хотите увидеть этот вывод:

'formatters': {
    'django.server': {
        '()': 'django.utils.log.ServerFormatter',
        'format': '[%(server_time)s] %(message)s',
    }
},
'handlers': {
    'django.server': {
        'level': 'INFO',
        'class': 'logging.StreamHandler',
        'formatter': 'django.server',
    },
},
'loggers': {
    'django.server': {
        'handlers': ['django.server'],
        'level': 'INFO',
        'propagate': False,
    }
}

auth.CustomUser и auth.ExtensionUser тестовые модели были удалены ¶

С момента появления миграции для приложений contrib в Django 1.8 таблицы этих пользовательских тестовых моделей больше не создавались, что делало их непригодными для использования в контексте тестирования.

Реестр приложений больше не заполняется автоматически при извлечении моделей вне Django ¶

Реестр приложений больше не заполняется автоматически при отборе моделей. Это было добавлено в Django 1.7.2 как попытка разрешить распаковку моделей вне Django, например, в RQ worker, без вызова django.setup() , но это создает возможность тупиковой ситуации. Чтобы адаптировать свой код в случае RQ, вы можете предоставить собственный рабочий скрипт, который вызывает django.setup() .

Удалена проверка нулевого назначения для ненулевых полей внешнего ключа ¶

В более старых версиях присваивание None не обнуляемому ForeignKey или OneToOneField поднятому . Для согласованности с другими полями модели, которые не имеют подобной проверки, эта проверка удалена.ValueError('Cannot assign None: "model.field" does not allow null values.')

Удалены хешеры слабых паролей из PASSWORD_HASHERS настройки по умолчанию ¶

Django 0.90 хранит пароли как несоленые MD5. В Django 0.91 добавлена ​​поддержка соленого SHA1 с автоматическим обновлением паролей при входе пользователя в систему. Django 1.4 добавил PBKDF2 в качестве хешера паролей по умолчанию.

Если у вас есть старый проект Django с паролями в кодировке MD5 или SHA1 (даже с солеными), имейте в виду, что их можно довольно легко взломать с помощью современного оборудования. Чтобы пользователи Django признали продолжение использования слабых хешеров, следующие хешеры удалены из PASSWORD_HASHERS настройки по умолчанию :

'django.contrib.auth.hashers.SHA1PasswordHasher'
'django.contrib.auth.hashers.MD5PasswordHasher'
'django.contrib.auth.hashers.UnsaltedSHA1PasswordHasher'
'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher'
'django.contrib.auth.hashers.CryptPasswordHasher'

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

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

from django.contrib.auth import get_user_model
User = get_user_model()

# Unsalted MD5/SHA1:
User.objects.filter(password__startswith='md5$$')
User.objects.filter(password__startswith='sha1$$')
# Salted MD5/SHA1:
User.objects.filter(password__startswith='md5$').exclude(password__startswith='md5$$')
User.objects.filter(password__startswith='sha1$').exclude(password__startswith='sha1$$')
# Crypt hasher:
User.objects.filter(password__startswith='crypt$$')

from django.db.models import CharField
from django.db.models.functions import Length
CharField.register_lookup(Length)
# Unsalted MD5 passwords might not have an 'md5$$' prefix:
User.objects.filter(password__length=32)

Field.get_prep_lookup() и Field.get_db_prep_lookup() методы удалены ¶

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

from django.db.models import Field
from django.db.models.lookups import Exact

class MyField(Field):
    ...

class MyFieldExact(Exact):
    def get_prep_lookup(self):
        # do_custom_stuff_for_myfield
        ....

MyField.register_lookup(MyFieldExact)

django.contrib.gis ¶

• Поддержка SpatiaLite <3.0 и GEOS <3.3 прекращена.
• В add_postgis_srs() псевдониме обратной совместимости для django.contrib.gis.utils.add_srs_entry() удаляется.
• В Oracle / GIS Area агрегатная функция теперь возвращает float вместо decimal.Decimal . (Он все еще упакован в квадратные метры.)
• Представление по умолчанию GEOSGeometry (вывод WKT) по умолчанию обрезано. То есть вместо того , чтобы получить .POINT (23.0000000000000000 5.5000000000000000) POINT (23 5.5)

Максимальный размер тела запроса и количество параметров GET / POST ограничены ¶

Две новые настройки помогают уменьшить атаки типа «отказ в обслуживании» с помощью больших запросов:

• DATA_UPLOAD_MAX_MEMORY_SIZE ограничивает размер тела запроса. Загрузки файлов не учитываются в этом лимите.
• DATA_UPLOAD_MAX_NUMBER_FIELDS ограничивает количество анализируемых параметров GET / POST.

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

Разное ¶

• Объект repr() a QuerySet завернут, чтобы исключить его из простого списка при отладке.<QuerySet >
• utils.version.get_version() возвращается Версии-кандидаты на выпуск, совместимые с PEP 440 (например, «1.10rc1» вместо «1.10c1»).
• Значения токена CSRF теперь должны быть строками из 64 букв и цифр; значения из 32 буквенно-цифровых символов, установленные по умолчанию в старых версиях Django, автоматически заменяются строками из 64 символов. Остальные значения считаются недопустимыми. Это должно коснуться только разработчиков или пользователей, которые заменяют эти токены.
• Этот LOGOUT_URL параметр удален, поскольку Django не использовал его с версии до 1.0. Если вы используете его в своем проекте, вы можете добавить его в настройки своего проекта. Значение по умолчанию было '/accounts/logout/' .
• Объекты, которым close() переданы такие методы, как файлы и генераторы HttpResponse , теперь закрываются немедленно, а не тогда, когда сервер WSGI вызывает close() ответ.
• Избыточный transaction.atomic() вызов QuerySet.update_or_create() удален. Это может повлиять на количество запросов, проверенных TransactionTestCase.assertNumQueries() .
• Поддержка skip_validation in BaseCommand.execute(**options) удалена. skip_checks Вместо этого используйте (добавлено в Django 1.7).
• loaddata теперь вызывает CommandError вместо предупреждения, когда указанный файл фикстуры не найден.
• Вместо прямого доступа к LogEntry.change_message атрибуту теперь лучше вызвать LogEntry.get_change_message() метод, который предоставит сообщение на текущем языке.
• Отображения ошибок по умолчанию теперь повышаются, TemplateDoesNotExist если template_name указано несуществующее .
• Неиспользуемый choices аргумент ключевого слова метода Select и SelectMultiple widgets » render() удален. choices Аргумент render_options() метода также удаляется, что делает selected_choices первый аргумент.
• Тесты, нарушающие откладываемые ограничения базы данных, теперь будут вызывать ошибку при запуске в базе данных, которая поддерживает откладываемые ограничения.
• Встроенные команды управления теперь используют индексацию ключей options , например options['verbosity'] , вместо приведения options.get() какого-либо типа и больше не выполняют его. Это может быть проблемой, если вы вызываете команды с использованием Command.execute() (в обход парсера аргументов, который устанавливает значение по умолчанию) вместо call_command() . Вместо вызова Command.execute() передайте объект команды в качестве первого аргумента функции call_command() .
• ModelBackend и RemoteUserBackend теперь отклоняйте неактивных пользователей. Это означает, что неактивные пользователи не могут войти в систему и выйдут из системы, если переключатся с is_active=True на False . Если вам нужно предыдущее поведение, используйте вместо него новый AllowAllUsersModelBackend или AllowAllUsersRemoteUserBackend in AUTHENTICATION_BACKENDS .
• В свете предыдущего изменения метод тестового клиента login() больше не всегда отклоняет неактивных пользователей, а вместо этого делегирует это решение бэкэнду аутентификации. force_login() также делегирует решение бэкэнду аутентификации, поэтому, если вы используете бэкэнды по умолчанию, вам необходимо использовать активного пользователя.
• django.views.i18n.set_language() теперь может возвращать код состояния 204 для запросов AJAX.
• base_field Атрибут RangeField теперь тип поля, не является экземпляром поля. Если вы создали собственный подкласс RangeField , вам следует изменить base_field атрибут.
• Классы промежуточного программного обеспечения теперь инициализируются при запуске сервера, а не во время первого запроса.
• Если вы переопределяете is_authenticated() или is_anonymous() в пользовательской модели пользователя, вы должны преобразовать их в атрибуты или свойства, как описано в примечании об устаревании .
• При использовании ModelAdmin.save_as=True кнопка «Сохранить как новый» теперь перенаправляет на вид изменений для нового объекта, а не на список изменений модели. Если вам нужно предыдущее поведение, установите для нового ModelAdmin.save_as_continue атрибута значение False .
• Обязательные поля формы теперь имеют required атрибут HTML. Установите для Form.use_required_attribute атрибута значение, False чтобы отключить его. Вы также можете добавить novalidate атрибут, <form> если не хотите, чтобы проверка браузера. Чтобы отключить required атрибут в пользовательских виджетах, переопределите Widget.use_required_attribute() метод.
• Обработчик WSGI больше не удаляет содержимое ответов из HEAD запросов или ответов с status_code числом 100–199, 204 или 304. Большинство веб-серверов уже реализуют такое поведение. К ответам, полученным с помощью тестового клиента Django, по-прежнему применяются эти «исправления ответов».
• Model.__init__() теперь получает django.db.models.DEFERRED как значение отложенных полей.
• Model._deferred Атрибут удаляется как динамические модели классов при использовании QuerySet.defer() и only() удаляется.
• Storage.save() больше не заменяется '\' на '/' . Это поведение перемещено, FileSystemStorage поскольку это конкретная деталь реализации хранилища. Любой пользователь Windows с реализацией настраиваемого хранилища, который полагается на это поведение, должен будет реализовать его в save() методе настраиваемого хранилища .
• Частные FileField методы get_directory_name() и get_filename() не больше не вызывается (и теперь устаревшее) , который является назад несовместимое изменение для пользователей этих методов временной отмены пользовательских полей. Чтобы адаптировать такой код, переопределите FileField.generate_filename() или Storage.generate_filename() вместо него. Возможно upload_to также использовать .
• Тема письма, отправляемого пользователем AdminEmailHandler , больше не обрезается до 989 символов. Если вы рассчитывали на ограниченную длину, обрежьте тему самостоятельно.
• Частные выражения django.db.models.expressions.Date и DateTime удаляются. Новые Trunc выражения обеспечивают ту же функциональность.
• _base_manager И _default_manager атрибуты удаляются из экземпляров модели. Они остаются доступными в классе модели.
• Доступ к удаленному полю в экземпляре модели, например, после , перезагружает значение поля вместо повышения .del obj.field AttributeError
• Если вы создаете подкласс AbstractBaseUser и переопределяете clean() , убедитесь, что он вызывает super() . AbstractBaseUser.normalize_username() вызывается в новом AbstractBaseUser.clean() методе.
• Частный API django.forms.models.model_to_dict() возвращает набор запросов, а не список первичных ключей для ManyToManyField s.
• Если django.contrib.staticfiles установлен, static тег шаблона использует staticfiles хранилище для создания URL, а не просто объединяет значение с STATIC_ROOT . Новый подход кодирует URL-адрес, который может быть обратно несовместимым в таких случаях, как включение фрагмента в путь, например , поскольку кодируется как . Для адаптации переместите фрагмент за пределы тега шаблона .{% static 'img.svg#fragment' %} # %23 {% static 'img.svg' %}#fragment
• Когда USE_L10N это True , локализация в настоящее время применяется для date и time фильтров , когда не указана строка формата. Спецификаторы DATE_FORMAT и TIME_FORMAT из активного языкового стандарта используются вместо одноименных настроек.

Прямое присвоение обратному внешнему ключу или отношению «многие ко многим» ¶

Вместо назначения связанных объектов с помощью прямого назначения:

>>> new_list = [obj1, obj2, obj3]
>>> e.related_set = new_list

Используйте set() метод, добавленный в Django 1.9:

>>> e.related_set.set([obj1, obj2, obj3])

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

Storage API без учета часовых поясов ¶

Старые методы accessed_time() , не учитывающие часовые пояса created_time() , и modified_time() устарели в пользу новых get_*_time() методов.

Сторонние серверные части хранилища должны реализовать новые методы и пометить старые как устаревшие. А пока новые get_*_time() методы базового Storage класса преобразуют datetime старые методы по мере необходимости и выдают предупреждение об устаревании при этом.

Сторонние серверные части хранилища могут сохранять старые методы, пока они хотят поддерживать более ранние версии Django.

django.contrib.gis ¶

• get_srid() И set_srid() методы GEOSGeometry являются устаревшими в пользу srid собственности.
• get_x() , set_x() , get_y() , set_y() , get_z() , И set_z() методы Point являются устаревшими в пользу x , y и z свойств.
• get_coords() И set_coords() методы Point являются устаревшими в пользу tuple собственности.
• cascaded_union Свойство MultiPolygon является устаревшим в пользу unary_union собственности.
• django.contrib.gis.utils.precision_wkt() Функция устарела в пользу WKTWriter .

CommaSeparatedIntegerField поле модели ¶

CommaSeparatedIntegerField осуждается в пользу CharField с validate_comma_separated_integer_list() валидатора:

from django.core.validators import validate_comma_separated_integer_list
from django.db import models

class MyModel(models.Model):
    numbers = models.CharField(..., validators=[validate_comma_separated_integer_list])

Если вы используете Oracle, CharField используется другой тип поля базы данных ( NVARCHAR2 ), чем CommaSeparatedIntegerField ( VARCHAR2 ). В зависимости от настроек вашей базы данных это может означать другую кодировку и, следовательно, другую длину (в байтах) для одного и того же содержимого. Если ваши сохраненные значения длиннее предела в 4000 байт NVARCHAR2 , вы должны использовать вместо этого TextField ( NCLOB ). В этом случае, если у вас есть какие-либо запросы, группирующиеся по полю (например, аннотирование модели с помощью агрегирования или использования distinct() ), вам необходимо изменить их (чтобы отложить поле).

Использование имени модели в качестве поиска в запросе, если default_related_name установлено ¶

Предположим следующие модели:

from django.db import models

class Foo(models.Model):
    pass

class Bar(models.Model):
    foo = models.ForeignKey(Foo)

    class Meta:
        default_related_name = 'bars'

В более старых версиях default_related_name нельзя было использовать в качестве поиска по запросу. Это исправлено, и поддержка старого имени поиска устарела. Например, поскольку default_related_name он установлен в модели Bar , вместо использования имени модели bar в качестве поиска:

>>> bar = Bar.objects.get(pk=1)
>>> Foo.objects.get(bar=bar)

используйте default_related_name bars :

>>> Foo.objects.get(bars=bar)

__search поиск по запросу ¶

search Поиск, который поддерживает MySQL только и крайне ограничен в особенности, является устаревшим. Замените его пользовательским поиском:

from django.db import models

class Search(models.Lookup):
    lookup_name = 'search'

    def as_mysql(self, compiler, connection):
        lhs, lhs_params = self.process_lhs(compiler, connection)
        rhs, rhs_params = self.process_rhs(compiler, connection)
        params = lhs_params + rhs_params
        return 'MATCH (%s) AGAINST (%s IN BOOLEAN MODE)' % (lhs, rhs), params

models.CharField.register_lookup(Search)
models.TextField.register_lookup(Search)

Использование методов User.is_authenticated() и User.is_anonymous() как ¶

В is_authenticated() и is_anonymous() методы AbstractBaseUser и AnonymousUser классы теперь свойства. Они по-прежнему будут работать как методы до Django 2.0, но все использование в Django теперь использует доступ по атрибутам.

Например, если вы используете AuthenticationMiddleware и хотите знать, вошел ли пользователь в систему в настоящее время, вы должны использовать:

if request.user.is_authenticated:
    ... # Do something for logged-in users.
else:
    ... # Do something for anonymous users.

вместо request.user.is_authenticated() .

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

if request.user.is_authenticated:
    return sensitive_information

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

Django использует CallableBool объект, чтобы эти атрибуты работали как свойство, так и как метод. Таким образом, пока не закончится период устаревания, вы не сможете сравнивать эти свойства с помощью is оператора. То есть не сработает следующее:

if request.user.is_authenticated is True:
    ...

Доступные через настраиваемые классы менеджеров prefetch_related должны определять _apply_rel_filters() метод ¶

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

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

«Побег» половина django.utils.safestring ¶

mark_for_escaping() Функции и классы , которые он использует: EscapeData , EscapeBytes , EscapeText , EscapeString и EscapeUnicode являются устаревшими.

В результате "ленивое" поведение escape фильтра (когда он всегда будет применяться в качестве последнего фильтра, независимо от того, где он появился в цепочке фильтров) не рекомендуется. Фильтр изменится на немедленное применение conditional_escape() в Django 2.0.

Manager.use_for_related_fields и изменения наследования ¶

Manager.use_for_related_fields устарело в пользу установки Meta.base_manager_name на модели.

Manager Наследование модели будет следовать правилам наследования MRO в Django 2.0, изменяя текущее поведение, при котором менеджеры, определенные для неабстрактных базовых классов, не наследуются дочерними классами. Предупреждение об устаревании с инструкциями по адаптации кода появляется, если у вас есть затронутые менеджеры. Вы либо повторно объявите менеджера из абстрактной модели в дочернем классе, чтобы переопределить менеджера из конкретной модели, либо вы установите Meta.manager_inheritance_from_future=True опцию модели, чтобы отказаться от нового поведения наследования.

Во время периода устаревания use_for_related_fields будет выполняться и выводиться предупреждение, даже если base_manager_name установлено. Это позволяет стороннему коду сохранять устаревшее поведение при переходе на новый API. Предупреждение можно отключить, установив silence_use_for_related_fields_deprecation=True в диспетчере.

Разное ¶

• Устарели в пользу варианты.makemigrations --exit makemigrations --check
• django.utils.functional.allow_lazy() устарел в пользу новой keep_lazy() функции, которую можно использовать с более естественным синтаксисом декоратора.
• Этот параметр устарел в пользу или .shell --plain -i python --interface python
• Импорт из django.core.urlresolvers объекта не рекомендуется в пользу его новой аренды django.urls .
• Метод шаблона Context.has_key() устарел и заменен на in .
• Частный атрибут virtual_fields из Model._meta осуждается в пользу private_fields .
• Аргументы частного ключевого слова virtual_only in Field.contribute_to_class() и virtual in Model._meta.add_field() устарели в пользу private_only и private , соответственно.
• Представления javascript_catalog() и json_catalog() устарели в пользу представлений на основе классов JavaScriptCatalog и JSONCatalog .
• При многотабличном наследовании неявное преобразование a OneToOneField в a parent_link не рекомендуется. Добавьте parent_link=True в такие поля.
• Частный API Widget._format_value() становится общедоступным и переименовывается в format_value() . Старое имя будет работать в течение периода устаревания.
• Частные FileField методы get_directory_name() и get_filename() не рекомендуются в пользу выполнения этой работы в Storage.generate_filename() ).
• Используемое промежуточное ПО старого типа settings.MIDDLEWARE_CLASSES устарело. Адаптируйте старое настраиваемое промежуточное ПО и используйте новую MIDDLEWARE настройку.