Yui компресор StringIndexOutOfBoundsException на jboss

Когато минимизирам yui с 2.4.6, получавам този проблем:

java.lang.StringIndexOutOfBoundsException: Индекс на низ извън диапазона: 232

at java.lang.String.substring(String.java:1934)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceString(JavaScriptCompressor.java:267)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:330)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.<init>(JavaScriptCompressor.java:533)

Работи, когато се стартира през моята IDE, но когато се внедри в jboss, не го прави. Това място: http://yuilibrary.com/forum/viewtopic.php?p=20086 има някои обсъждане на същия проблем.

Очевидно проблемът е около това, че org/mozilla/javascript/Parser е в двата буркана, които са изтеглени от моята конфигурация на maven:

<dependency>
<groupId>com.yahoo.platform.yui</groupId>
<artifactId>yuicompressor</artifactId>
<version>2.4.6</version>
</dependency>

Има ли някакъв начин да разреша това с помощта на maven изключения и т.н. или като надстроя моята версия на YUI. Изглежда глупаво, че просто не работи и не искам да пиша персонализиран зареждащ клас.

Моля помогнете!


java javascript jboss tapestry yui
person lukewm    schedule 11.07.2011    source източник
comment
И аз имам този проблем! По дяволите! Моят обаче е tomcat 6.   -  person egervari    schedule 08.12.2011
comment
Успяхте ли да преопаковате добре? Накрая пъхнах по-голямата част от източника на носорог в моя пакет. Вероятно мога да направя пакета достъпен в github, ако имате няколко дни?   -  person lukewm    schedule 05.01.2012
comment

В книгата Системно програмиране на Linux прочетох някои като това:

fgetc връща символа, прочетен като unsigned char кастинг към int или EOF в края на файла или грешка. Често срещана грешка при използване на fgetc е:

char c;
if ((c = fgetc()) != EOF) {...}

Правилната версия на този код е:

int c;
if ((c = fgetc()) != EOF) { printf("%c", (char)c); ... }

И така, защо не мога да прехвърля върната стойност към char, преди да сравня с EOF? Защо трябва да сравнявам EOF точно с int? Тъй като EOF е дефинирано като -1, не е ли обикновено прехвърлено към char?
Има ли платформи/компилатори, където не е вярно?

  -  person Danubian Sailor    schedule 13.01.2012
comment
Подадох сигнал за грешка: github.com/yui/yuicompressor/issues/161   -  person Timothy Kim    schedule 27.09.2014

Отговори (4)


arrow_upward
8
arrow_downward

Заобиколно решение: За JBoss AS 7.1.1.Final и YUICompressor 2.4.7

Изключете носорога от зависимостта:

        <dependency>
          <groupId>com.yahoo.platform.yui</groupId>
          <artifactId>yuicompressor</artifactId>
          <version>${yuicompressor.version}</version>
          <exclusions>
            <exclusion>
               <groupId>rhino</groupId>
               <artifactId>js</artifactId>
            </exclusion>
          </exclusions>
        </dependency>

Защо? Вижте https://github.com/greenlaw110/greenscript/pull/29#issuecomment-4017147

Забележка: ако имате rhino в classpath по някакъв друг начин, изглежда, че ще получите тази грешка отново.

person Alexander Shagin    schedule 10.11.2012

arrow_upward
5
arrow_downward

Реших този проблем, като сам преопаковах yuicompressor, за да включа по-голямата част от източника на rhino. Вижте отговора ми на Howard M. Lewis Ship.

Преопакованият източник може да бъде намерен тук: http://viscri.co.uk/labs/tapestry/yuicompressor-rhino-bugfix-5.0.jar. Просто добавете това към вашия pom:

<dependency>
   <groupId>yuicompressorbugfix</groupId>
   <artifactId>yuicompressor-rhino-bugfix</artifactId>
   <version>5.0</version>
</dependency>

Ако не използвате собствена версия на nexus, ще трябва да я инсталирате на машината, върху която искате да надграждате. Мисля, че това е командата, от която се нуждаете: http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html

Ще трябва също да изключите версията на yuicompressor, която tapepry изтегля:

<dependency>
   <groupId>org.apache.tapestry</groupId>
   <artifactId>tapestry-yuicompressor</artifactId>
   <version>5.3.2</version>
   <exclusions>
       <exclusion>
             <groupId>com.yahoo.platform.yui</groupId>
             <artifactId>yuicompressor</artifactId>
       </exclusion>
   </exclusions>

Това трябва да работи.

person lukewm    schedule 01.08.2011
comment
Да, те чисти малки мравки се базират изцяло на последователност от библиотеки в зареждащия клас, който е толкова болен, че все още едва дишам, докато го пиша бррр! При тях работи, защото използват ant, на сървъра на приложения е обратното. Направих опаковката, която описахте, и работи както трябва. - person Danubian Sailor; 13.01.2012

arrow_upward
1
arrow_downward

Бурканът на избрания отговор (от 26.09.2014 г.) вече не съществува.

И така, създадох разклонение на yuicompressor, където целият пакет rhino е вграден в пакета yuicompressor и го поставих под yui.

https://github.com/timothykim/yuicompressor

Просто клонирайте репото и стартирайте ant, за да получите буркана.

Надявам се това да помогне на всеки друг, който се натъкне на този проблем.

person Timothy Kim    schedule 26.09.2014

arrow_upward
0
arrow_downward

Наистина ли имате проблеми със зареждането на класове в JBoss?

Ще трябва да направите някакъв вид изключване на конкурентния JAR файл на rhino. Защо Rhino е на класната пътека? Може да е незадължителна функция на JBoss, която можете да изключите и по този начин да избегнете конфликта.

person Howard M. Lewis Ship    schedule 12.07.2011
comment
Rhino е на класовата пътека, защото maven пакетираният yuicompressor зависи от него. По принцип yui презаписва няколко класа rhino, но не всички, което води или до изключения classNotFound, ако rhino е изключен, или до проблема по-горе, ако не е. Щях да изпратя имейл до пощенския списък на tapepry за това, тъй като бих си помислил, че използването на yui в tapepry 5.3 ще доведе до същите проблеми. Накрая просто смлях носорог и юи заедно в собствения си персонализиран буркан. - person lukewm; 13.07.2011
comment
Те описват проблема тук: yuilibrary.com/projects/yuicompressor/ticket/2528114. Казват, че е решен, но аз се съмнявам, като се има предвид как е написано това. Пакетът с изходен код, изтеглен днес, поне няма нищо направено по въпроса. - person Danubian Sailor; 13.01.2012