5 Replies Latest reply on Jan 17, 2013 4:05 PM by henk de boer

    JBoss EAP 6.0.1 doesn't work correctly on JBoss Tools 4

    henk de boer Master

      JBoss EAP 6.0.1 (JBoss AS 7.1.3.Final-redhat-4) doesn't seem to work correctly on Eclipse 4.2/JBoss Tools 4.

       

      The server starts and stops correctly, but the "JBoss Enterprise Application Platform 6.x Runtime" node under "Java Resources" -> src -> Libraries in e.g. a Dynamic Web Project is empty. None of the types that the runtime normally puts on the classpath are available.

       

      Upon inspecting, it seems that between EAP 6.0.0 (JBoss AS 7.1.2.Final-redhat-1) and JBoss EAP 6.0.1 (JBoss AS 7.1.3.Final-redhat-4), jboss-eap-6.0/modules/javax/activation/api/main/activation-1.1.1-redhat-1.jar has been renamed to jboss-eap-6.0/modules/javax/activation/api/main/activation-1.1.1-redhat-2.jar, but the runtime somewhere references the -1.jar version.

       

      After some more fiddling, I got Eclipse to emit the following build path error:

       

      The container 'JBoss Enterprise Application Platform 6.x Runtime [JBoss EAP 6.0 Runtime]' references non existing library '/Users/henk/eclipse42/jboss-eap-6.0/modules/javax/activation/api/main/activation-1.1.1-redhat-1.jar'
      

       

      After some more digging, I found there are many, many more libraries that aren't being recognized. A small list:

       

      /modules/javax/annotation/api/main/jboss-annotations-api_1.1_spec-1.0.1.Final-redhat-1.jar
      /modules/javax/ejb/api/main/jboss-ejb-api_3.1_spec-1.0.2.Final-redhat-1.jar
      /modules/javax/el/api/main/jboss-el-api_2.2_spec-1.0.1.Final-redhat-1.jar
      /modules/javax/enterprise/api/main/cdi-api-1.0-SP4-redhat-1.jar
      /modules/javax/enterprise/deploy/api/main/jboss-jad-api_1.2_spec-1.0.1.Final-redhat-1.jar
      

       

      The majority of them have -1.jar renamed to -2.jar, but in case of jboss-el-api_2.2_spec-1.0.1.Final-redhat-1.jar the 1.0.1 changed to 1.0.2.

        • 1. Re: JBoss EAP 6.0.1 doesn't work correctly on JBoss Tools 4
          henk de boer Master

          Just wondering if I'm perhaps the only one seeing this?

          • 2. Re: JBoss EAP 6.0.1 doesn't work correctly on JBoss Tools 4
            Max Rydahl Andersen Master

            the classpath is dynamically calculatedb based on the content of the server thus its a bit weird.

             

            Does it happen on complete new projects/new server setup too ?

             

            In any case try remove and add the classpath container again.

            • 3. Re: JBoss EAP 6.0.1 doesn't work correctly on JBoss Tools 4
              Rob Stryker Master

              I just tested this in my dev environment, and I'm not able to replicate it. My classpath seems to be set properly.

               

              Did you perhaps delete a runtime during a workspace session and then create a new one with the same name?

               

              One workaround to force the classpath to reset for the dynamic web project would be to right-click the project, properties, then go to the "Targeted Runtimes" page, and uncheck your runtime. Press apply, then re-check it, and press apply. This will try to reset the classpath containers at least.

               

              Where exactly are you seeing this build path error? You say you fiddled a bit and got it to reveal the error. Where was it?

               

              Let's hope this is just a fluke of some type. Is it repeatable if done from a clean workspace? Any more information is definitely useful.

              • 4. Re: JBoss EAP 6.0.1 doesn't work correctly on JBoss Tools 4
                henk de boer Master

                Rob Stryker wrote:

                 

                I just tested this in my dev environment, and I'm not able to replicate it. My classpath seems to be set properly.

                 

                Did you perhaps delete a runtime during a workspace session and then create a new one with the same name?

                 

                Initially I updated my existing EAP 6.0.0 runtime to point to a 6.0.1 installation, which is an operation I normally do for every other runtime I have. Then I created a completey new server and a new runtime as well, and set the target runtime of both an existing and new project to this, but in both cases the mentioned libraries could not be found.

                 

                I then tried an Eclipse 3.7 installation, with an existing workspace and an existing project already targetting the EAP 6.0.0 runtime. This gave the same problem.

                 

                 

                Where exactly are you seeing this build path error? You say you fiddled a bit and got it to reveal the error. Where was it?

                 

                It was in the Markers view. At first it wasn't there, but after some combination of closing and re-opening a project, cleaning and rebuilding, and restarting Eclipse (my usual recipe to reset potential caching issues) the entry appeared in that view. Since I wasn't looking at it all the time, I'm not exactly sure at what point it appeared there.

                 

                I'll try to see what happens when I do the uncheck-apply-recheck trick.

                • 5. Re: JBoss EAP 6.0.1 doesn't work correctly on JBoss Tools 4
                  henk de boer Master

                  Rob Stryker wrote:

                   

                  Let's hope this is just a fluke of some type. Is it repeatable if done from a clean workspace? Any more information is definitely useful.

                   

                  What do you know, I can't seem to replicate it again either! :X

                   

                  The other week I could consistently replicate it in two different Eclipse instances and now it works in both. The only thing I can think of that changed is that I rebooted my system in the mean time (something I otherwise rarely do).

                   

                  Let's indeed treat it then as some kind of fluke. I'll post a new comment here should I encounter it again (hopefully not ).