Skip to Content
h3. Requirements    In this WebLog I describe two release-specific (SAP NetWeaver 7.0 and CE 7.10) solutions to use the same external JAR file in different Web Dynpro development components fulfilling three main requirements:   h4. Central storage place     The JAR file is stored in a central development component. To keep this JAR file independent from the runtime environment, we use a non-deployable External Library development component. With this “single-source” approach we avoid, that the same JAR file is physically stored in different development components   h4. Compilation at design time    At design time, the JAR file is needed by several Web Dynpro development components for compilation or build time purpose. As clients of the JAR file we name them Web Dynpro client development components here. The External Library development component comprising the JAR file must therefor expose it in a puplic part of type compilation.   h4. Classloading at runtime     At runtime, the JAR file must be doployed at the SAP NetWeaver AS Java so that the Web Dynpro Java runtime environment can load the JAR file’s classes. To deploy the JAR file to the server we have to wrap its embedding (non-deployable) +External Library development component+ in a separate deployable development component of type +J2EE Server Component/Library+. The External Library development component must therefore expose its comprised JAR file in another puplic part of type assembly.  In this case the JAR file is added to the deployable archive of its deployable “wrapper” development component (using the second public part). By deploying the wrapper development component to the SAP NetWeaver AS Java the JAR file gets also deployed to the server to be found by the class loader at runtime.     To load the JAR file’s classes at runtime inside the Web Dynpro client development component, the Web Dynpro Java runtime must additionally know the fully qualified name of the development component comprising the JAR file. We therefore have to define a runtime dependency between the Web Dynpro client development component where the JAR file’s classes are invoked and the J2EE Server Component/Library development component comprising them. In SAP NetWeaver 7.0 this runtime dependency is defined as Library reference in the properties of a Web Dynpro development component. The Library reference entry must be the technical name of the J2EE Server Component/Library development component. For example,*vendor.org/jsclib~ext~exlexp* is the technical name of a J2EE Server Component/Library development component with name *vendor.org/jsclib/ext/exlexp*.   +*Note*: Using Web Dynpro Java Helper Classes+  +To implement and reuse own Web Dynpro Java specific Java utility or helper classes like classes for sorting or filtering tables to be invoked in your Web Dynpro controllers, you do not need to create and deploy a corresponding JAR file. Simply implement these helper classs in folder src of a Web Dynpro development component, build and deploy it to the SAP NetWeaver AS and expose the classes to other Web Dynpro development components in a public part of type compilation.  + h3. Solution in SAP NetWeaver 7.0 SP9  The solution fulfilling all these requirements in SAP NetWeaver 7.0 is illustrated below:  *How to!*   * Expose the same JAR file in two separate public parts, one with purpose assembly (1) and another one with purpose compilation (2). * Use the public part with purpose compilation in the Web Dynpro “client” development component where you need the JAR file to implement your Java code, for example, inside a Web Dynpro component controller class (3). *  Add a development component of type  *J2EE Server Component/Library*, and use the second public part (of type assembly) of the External Library development component  there (4).0.1.  Define a *Library reference* to the J2EE Server Component/Library development component in the project properties of theWeb Dynpro client development component, where classes and interfaces of the external JAR file are invoked (5). In the properties window select Web Dynpro References – Library references and enter the technical development component name like “*vendor.org/jsclib~ext~exlexp*”.0.1.   0.2. Deploy the development component of type J2EE Server Component/Library “wrapping” the External Library development component to the SAP NetWeaver AS Java (6). 0.3. h3. Solution in SAP NetWeaver CE 7.10
To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Dina Mann

    Hi.     ERROR: C:\Documents and Settings\dina.mann\.dtc\LocalDevelopment\t\6D3FFC34CD71E98FF3F164DBE562D65F\gen_wdp\packages\sap\com\CatalogView.java:20: ‘.’ expected<br/>     ERROR: import TableFilterHandler;<br/>     ERROR:                          ^<br/>     1 error<br/><br/>Is there anything I’ve neglected to do?<br/>Any suggestions on what I may have done wrong, or how else to solve my problem?<br/><br/>Thank you,<br/>Dina Mann<br/>

    (0) 
    1. Bertram Ganz Post author
      Hallo Dina, there was a problem in NetWeaver 7.0 SP9 described in SAP Note https://service.sap.com/sap/support/notes/993799 but you develop with SP15 where the problem was already fixed. Based on your description I cannot find any reason for this compilation problem. Please make sure that you trigger a DC build but not a project build to really create the Public Part Archive.
      Regards, Bertram
      (0) 
      1. Dina Mann
        Hi Bertram.

        As I read more of the official SAP material related to this, I suspect maybe the problem might be related to the creation or storage of the original jar file.
        I have seen comments such as:
        “The JAR files to be added must be in the workspace”
        and
        “Copy all the JARs that you need for the project from the portal for deployment to the workspace of your project.”

        This seems to indicate that the jar file needs to be stored in the workspace, and that the jar file needs to be pre-registered somehow.
        All I did was export to jar, which I stored in some folder of my own, not in teh workspace, and then copied the jar file from there to the libraries folder of the External Library DC.

        Is this enough, or did I really miss something like what I quoted above?
        And if so – Could you tell me in more detail what I have to do?

        Thanks!
        Dina Mann

        (0) 
  2. Dina Mann
    Hi again.

    Just want to add that I also tried your other suggestion:
    To implement and reuse own Web Dynpro Java specific Java utility or helper classes like classes for sorting or filtering tables to be invoked in your Web Dynpro controllers, you do not need to create and deploy a corresponding JAR file. Simply implement these helper classs in folder src of a Web Dynpro development component, build and deploy it to the SAP NetWeaver AS and expose the classes to other Web Dynpro development components in a public part of type compilation. 

    Here is what I did:
    I created a Web Dynpro DC project with no actual component.
    I added my java class files under src/packages.
    I included them all in a single public part of type compilation.
    I built and deployed.
    I added the public part under Used DCs in my project, defining the dependency as both Build and Run. (I had previously tried just Build as well)
    I then added in my code a declaration of an object using one of the java classes.
    It was recognized without having to add any import.
    I successfully built and deployed my DC project.
    In run time, at the point of instantiating the new object using the new class, I received the following error:
    java.lang.NoClassDefFoundError: sap/com/TableFilterHandler

    Again – Any suggestions?

    Thank you,
    Dina Mann

    (0) 
    1. VINCENZO TURCO
      Hi, sorry to say that I’m experiencing the same behaviour.
      Up to now I only managed to use plain java classes in src folder of my “Utils” WDJ project in the following way:
      – add all your java classes to public part of type compilation
      – add all your java classes to public part of type assembly

      in your WDJ client DC declare build dependency from both the public parts. However if your client DC is later on used by another DC which in turn uses the same “Utils”, the same Utils assembly public part will be included twice, leading to unpredictable behaviour (it happened to me).

      I’d be glad if someone might shed some light on how to achieve this.
      Thanks and kind regards.
      Vincenzo

      (0) 
    2. Ashwani Kumar Sharma
      Hi Dina,

      The steps mentioned by you are following:

      1) I created a Web Dynpro DC project with no actual component.
      2) I added my java class files under src/packages.
      3) I included them all in a single public part of type compilation.
      4) I built and deployed.
      5) I added the public part under Used DCs in my project, defining the dependency as both Build and Run. (I had previously tried just Build as well)
      6) I then added in my code a declaration of an object using one of the java classes.
      7) It was recognized without having to add any import.
      8) I successfully built and deployed my DC project.

      Let us call the DC created at step 1 as wddc1 and DC created at step 5 as wddc2.

      I ran the same scenario and it worked worked properly.
      I hope at step 4 and 8: You are doing DC build and the deployment was successful.
      Both wddc1 and wddc2 should be build and deployed. In this particular scenario, there is no need to create public part of type “assembly”.

      If you want to only deply wddc2:
      At step 4) You have do following also:
      In 04\04s – You need to create public part of type “Can be packaged into other build results”
      In CE – You need to create a public part of “assembly” also.
      And in step 5) You need to create dependency to the public part created in step 4.

      Regards,
      Ashwani Kr Sharma

      (0) 
  3. René van Mil
    Thanks, your explanation worked for me.

    One thing to keep in mind though (I found out the hard way):
    Make sure the external libraries you’re using are compatible with the Java version the server is running on.

    (0) 
  4. Ondrej Hugan
    Hi Bertram.
    Nice blog with usefull information. Definitely in 7.10 it’s better implemented – all connections are on the DCs level – it’s more transparent and clear approach.
    Ondrej
    (0) 
  5. Sharath M G

    Hello Bertram,

    Thank you for the blog.

    I have been struggling with DC as most blog and posts give a step by step process. But, you blog gave me the indepth understanding of behavior of DCs with external library.

    I am yet to implement and resolve the issue ( Unfortunately, server is down ). But, I am confident that the issue will be resolved.

    If not, then I may leave a question in my follow up comment. 🙂

    Thank you.

    Regards,

    Sharath

    (0) 

Leave a Reply