|
|
|
JBoss classpath ordering
|
|||
|---|---|---|---|
|
#18+
Привет, есть сторонняя библиотека и веб апп, который деплоится в jboss, есть класс com.Main. Я хочу ( и не спрашивайте зачем ) создать такой же класс com.Main, который потом скомпилится и по задумке "заместит" оригинальный класс. Вопрос: Как добиться того, чтобы мой класс был загружен первым? А не клас из стороннего джарника... Плиз хелп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2014, 17:32 |
|
||
|
JBoss classpath ordering
|
|||
|---|---|---|---|
|
#18+
Anatoly D, У вас есть проблема. Но вместо того чтобы рассказать о ней и подумать над вариантами как её решить, вы уже предлагаете одно из решений, как будто других вариантов уже и нет. com.Main находится внутри библиотеки, которую вы почему-то менять не можете? Она подписана? JBoss-ом куда это нужно деплоить вы владете или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2014, 17:36 |
|
||
|
JBoss classpath ordering
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, менять могу. Но это error prone. Ибо я-то поменяю в таргет библиотеке, придёт на неё сервис пак 2, и снова там объявится этот класс. Да и вообще могут быть варианты разные для разных версий. К деплойменту джбосса доступ есть. А что Вы предлагаете? Я ж готов к диалогу, чё нет-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2014, 17:51 |
|
||
|
JBoss classpath ordering
|
|||
|---|---|---|---|
|
#18+
Anatoly D менять могу. Но это error prone. Ибо я-то поменяю в таргет библиотеке, придёт на неё сервис пак 2, и снова там объявится этот класс. Да и вообще могут быть варианты разные для разных версий. К деплойменту джбосса доступ есть. Не вижу связи. Обновится библиотека, ваш собственный класс станет таким же не актуальным. Какая разница внутри ли он библиотеки или снаружи? Anatoly DА что Вы предлагаете? Я ж готов к диалогу, чё нет-то. По-хорошему. Пишется отдельный модуль в проекте, с отдельным классом. В процессе сборки библиотека патчится классами из этого модуля. Желательно ещё и пару тестов написать, чтобы несовместимость с новыми версиями раньше выявить. Единственный минус - подход не будет работать, если jar подписан. С другой стороны, если вы контролируете JBoss, то и подписи проверять некому, можно смело их выкинуть, если лицензия позволяет. Геморный вариант - добавить агента, который при загрузке класса библиотеки внесет в байт-код нужные изменения. Сложно написать. Но не сложно поддерживать. Если изменения не большие, то и способ довольно простой. Минус - если класс нужен радикально другой, с другими методами, то этот вариант ещё и работать не будет без JRebel. Можно свой класс кинуть в либы JBoss, в commons, в JDK (не рекомендую) и даже прописать в bootstrap classpath в скриптах запуска JBoss. Минусы есть. - не будет работать для sealed jar. Может сломаться package private доступ. (Не помню точно, кажется это только для sealed) - в JBoss хитрая система ClassLoader-ов, чтобы изолировать JEE модули. Поэтому если ваш класс будет вне JEE модуля, то JBoss вполне сможет загрузить этот класс ещё раз из JEE модуля. Что чревато тем что такой фикс не будет работать без удаления оригинального класса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2014, 18:03 |
|
||
|
|

start [/forum/topic.php?fid=59&fpage=190&tid=2127811]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
64ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 430ms |

| 0 / 0 |
