glassfish
  1. glassfish
  2. GLASSFISH-14910

Why do I have to deploy all my libraries into domains/lib/ to get it to work?

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      Glassfish V3 / Ms Windows 7

      Description

      On Glassfish V3 (3.0.1 Build 22), when I deployed the jar file (Applicaton / EJB Module), it kept complaining certain external libraries (which is included in the jar), can not be found.

      Error in annotation processing: java.lang.NoClassDefFoundError:

      Attached file deployed successfully on glassfish V2, but filed on glassfish V3.

        Activity

        Hide
        Hong Zhang added a comment -

        I checked the attached test case, the libraries are all in the lib directory of the ejb jar. This is not a portable way of packaging library jars in the ejb jar.

        The portable way of packaging libraries jar for ejb is to create an ear and put the libraries jars in the ear lib directory.

        I tried to deploy the same application to v2, the deployment failed there also. Was the application package the exact way when you tried on v2?

        Show
        Hong Zhang added a comment - I checked the attached test case, the libraries are all in the lib directory of the ejb jar. This is not a portable way of packaging library jars in the ejb jar. The portable way of packaging libraries jar for ejb is to create an ear and put the libraries jars in the ear lib directory. I tried to deploy the same application to v2, the deployment failed there also. Was the application package the exact way when you tried on v2?
        Hide
        ykartal added a comment - - edited

        I have updated the jar file with working file.

        Simple issue is that;
        Glassfish v2.1.1 deployment is successful but Glassfish V3 deployment is failed with this jar.
        If the lib files(*.jar) within the servis.jar copied the

        {Glassfish}

        /lib directory, Glassfish v3 deployment is successful.

        Show
        ykartal added a comment - - edited I have updated the jar file with working file. Simple issue is that; Glassfish v2.1.1 deployment is successful but Glassfish V3 deployment is failed with this jar. If the lib files(*.jar) within the servis.jar copied the {Glassfish} /lib directory, Glassfish v3 deployment is successful.
        Hide
        Hong Zhang added a comment -

        I see. Yes, in v2.* the root level library jars of the ejb module used to be added to the classpath. But as JavaEE6 spec has enforced the jar visibility rules more strictly, in order to encourage the writing of portable applications, we have enforced the rules in the implementation in v3 as well. To maintain the backward compatibility of the jar visibility, user could use the compatibility property, such as:

        asadmin deploy --property compatibility=v2 Servis.jar

        However, this property was only supported for ear level jar visibility in v3, the support for ejb jar is in the 3.1 (we discovered this backward compatibility use case later).

        I guess you could either move to 3.1 to use the property, or you could repackage the application to be a portable application like I suggested earlier (package ejb jar as an ear, and put the libs in the ear/lib), or continue to workaround using domain/lib till you are ready to move to 3.1. Thanks.

        Show
        Hong Zhang added a comment - I see. Yes, in v2.* the root level library jars of the ejb module used to be added to the classpath. But as JavaEE6 spec has enforced the jar visibility rules more strictly, in order to encourage the writing of portable applications, we have enforced the rules in the implementation in v3 as well. To maintain the backward compatibility of the jar visibility, user could use the compatibility property, such as: asadmin deploy --property compatibility=v2 Servis.jar However, this property was only supported for ear level jar visibility in v3, the support for ejb jar is in the 3.1 (we discovered this backward compatibility use case later). I guess you could either move to 3.1 to use the property, or you could repackage the application to be a portable application like I suggested earlier (package ejb jar as an ear, and put the libs in the ear/lib), or continue to workaround using domain/lib till you are ready to move to 3.1. Thanks.
        Hide
        Hong Zhang added a comment -

        Mark the issue as fixed in 3.1 as the user could use the compatibility property to achieve the product backward compatibility.

        Show
        Hong Zhang added a comment - Mark the issue as fixed in 3.1 as the user could use the compatibility property to achieve the product backward compatibility.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            ykartal
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: