Если вы присоединяете отладчик к классическому веб-приложению ASP, вам необходимо убедиться, что вы также хотите отладить управляемый код.
В окне Attach to Process
перед выбором процесса для присоединения найдите опцию Select...
справа от метки Attach to:
;
Откроется окно Select Code Type
, где вы можете выбрать отладчики типа кода для подключения.
Выберите несколько типов кода из перечисленных, в частности, версию [.NET] Managed
, которая подходит для компиляции .Net COM DLL, которую вы хотите отлаживать.
Присоединяйтесь к процессу как обычно.
Эталонная реализация JAXB имеет недокументированное системное свойство именно по этой причине:
-Dcom.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.fastBoot=true
или для старых версий, предшествующих рефакторингу пакета:
-Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true
Это указывает JAXB пропустить дорогостоящий процесс предварительного кэширования различных отражающих мышц, необходимых для работы. Вместо этого он будет делать все отражение при использовании контекста. Это снижает время выполнения, но значительно ускоряет инициализацию, особенно для большого количества классов.
Однако одна часть проблемы скорости неизбежна, а именно тот факт, что JAXB должен загружать каждый из ваших классов, и загрузка классов происходит медленно. Это очевидно, если вы создадите второй контекст сразу после первого, с той же конфигурацией - вы увидите, что это намного, намного быстрее, если уже загрузили классы.
Кроме того, вы говорите, что у вас есть несколько экземпляров JAXBContext, потому что у вас есть несколько контекстных путей. Вы поняли, что можете поместить несколько путей контекста в один контекст? Вам просто нужно передать их все в виде строки, разделенной точкой с запятой, при инициализации контекста, например,
JaxbContext.newInstance("a.b.c:x.y.z");
загрузит контексты abc
и xyz
. Однако это, скорее всего, не повлияет на производительность.
В общем случае вам не нужно создавать много экземпляров JAXBContext, поскольку они настроены на многопоточность после их настройки. В большинстве случаев подходит только один контекст.
Так есть ли конкретная причина, по которой создается много экземпляров? Возможно, было предположение, что они не являются потокобезопасными? (что понятно, учитывая, что это не ясно задокументировано - но это очень распространенный шаблон, необходимо синхронизировать его во время конфигурации, но не во время использования, если конфигурация не изменена).
Если не использовать этот параметр, если это все еще проблема, профилирование узких мест и регистрация проблемы на jaxb.dev.java.net (указание горячих точек из профиля) поможет улучшить ситуацию. Команда JAXB очень хорошая, отзывчивая, и если вы можете показать, где проблемы, они обычно находят хорошие решения.
JAXBContext действительно является потокобезопасным, поэтому рекомендуется использовать его синглтон. Я написал простой синглтон, содержащий класс-> контекстную карту, которая, кажется, выполняет свою работу. Вы также можете создать пул объектов [un] marshaller, если ваше приложение использует много потоков, поскольку эти объекты не являются потокобезопасными, и вы также можете столкнуться с некоторыми штрафами за инициализацию с ними.
В нашем случае обновление библиотек JAXB было хорошей идеей. Кстати, использование серверной виртуальной машины вместо клиентской виртуальной машины даже в среде разработки было здесь хорошей идеей, хотя обычно это замедляет запуск сервера: поскольку инициализация JAXB занимает так много времени, лучшая компиляция серверной виртуальной машины помогает.