Discussions

General J2EE: Websphere Studio 5.1.0 and third party libraries

  1. Websphere Studio 5.1.0 and third party libraries (11 messages)

    I am using Log4j 1.2.8 and Websphere Studio Application Developer 5.1.0

    Log4j provides a pre-built jar: log4j-1.2.8.jar

    What is the best approach for integrating this pre-built
    JAR in WSAD?

    Option 1:
    =========

    Create a Java project called "Log4j"

    Use "Import ---> Filesystem" to import the JAR into the
    project.

    Web projects that need Log4j will reference the Log4j
    project.

    Option 2:
    =========

    Create a Java project called "Log4j"

    Use "Import ---> Zip file" to import the JAR into the
    project.

    Log4j's class files will sit inside the Log4j project.

    Web projects that need Log4j will reference the Log4j
    project.

    Option 3
    ========

    Workspace --> Java --> Classpath Variables

    Declare a Classpath Variable called MYCORP_LOG4J

    Projects that need Log4j can reference the Classpath Variable.

    Option 4
    ========

    For each Web project, drop a copy of log4j-1.2.8.jar
    in the WEB-INF/lib directory.


    What is the best approach?

    Thanks in advance,
  2. It depends on what your target server environment is.

    If you know for certain that your target server already has Log4J installed, use Option 3 to put it in your project classpath.

    If you have any doubts, use Option 4 and but it in your WEB-INF/lib. That is the safest approach.
  3. There is another option[ Go to top ]

    This one doesnt get mentioned often.

    You can drop the jar into you EAR project. Do copy of the jar file in the filesystem, the right click on the EAR project and do paste.

    This will automagically make the jar file available to any projects associated with the EAR project. So once jar is in your EAR project, right click on any of the associated projects and do click properties. Under dependant jars, the jar that you added to the EAR project can be selected as a dependant jar.

    This will add it to the build path of the project, and if you deploy you projects as EAR files, the jar will be deployed to the server also, so the jar does not need to be added to the servers classpath.
  4. hi guys I am unable to deploy a WAR file into WAS 5.1 . Can any one help me out.
  5. Option 3 is the best, IMHO.

    That way it becomes part of your environment. And can be used by multiple projects, web/EAR or non-web projects.
  6. Let me add the following:

    We have multiple projects in WSAD.

    1) Java projects (standalone Java libraries)
    2) Web application projects (WAR's)
    3) Enterprise application projects (EAR's)

    We want to be able to use Log4j in our Java projects (#1) as well
    as in the Web application projects.
  7. I received an email reply from Tim deBoer (IBM):

    > Since you won't be making changes to the log4j jar, there's no point in
    > creating a separate Java utility project. So, don't use 1 or 2.
    >
    > Option 3 only handles build time. You'd have to add the jar to the
    > server's
    > classpath as well to make it work at runtime, so I'd leave this one out
    > too.
    >
    > Option 4 is the most clean and self contained, but as you said it will
    > require a separate copy of log4j in each Web module. If you only have a
    > few
    > Web modules that use it, or they are in separate EARs, I would still take
    > this path. If you have many Web modules, but they are in the same EAR, you
    > can put the jar into the EAR project instead. Then you'll need to use
    > "Edit
    > Module Dependancies" on each of the Web modules that need to make use of
    > log4j. This will add it to the Java build path of the Web modules (build
    > time) and to the manifest file of the Web module (runtime classpath). This
    > cuts down on the number of copies of log4j, but still keeps it
    > self-contained within the EAR and makes it easy to deploy your
    > application.
    >
    > Thanks,
    > Tim deBoer
    > WebSphere Tools - IBM Canada Ltd.
  8. Hi Sean,

    My apologies for not continuing the conversation. I am so used to you *answering* questions rather than answering them, that when I saw your later postes I assumed that was what you were doing. It took me a while to notice that the original question was yours :)

    Here is another possibility:

    Go with Option 3 (Log4J in the WSAD classpath) and put your Log4J jar in the same place for all your projects. Then, write Ant build scripts to add the jar to the generated WAR or EAR in the "build" or "dist" task of your script.

    This cuts down on all the duplicate copies of Log4J in your development enviroment, but puts independent copies of Log4J in your deployable archives.
  9. My development environment is more complex that the basic
    scenarios described in the WSAD product documentation.

    This is my scenario:

    Project 1 is a Java project that contains a package called
    com.mycorp.util

    Project #1 is dependent upon two 3rd party libraries: foo.jar
    and bar.jar

    Project #2 is an Enterprise Application Project.

    Project #3 is a Web Application Project. This Web project
    is associated with Project #2.

    Project #3 is dependent upon Project #1.

    Project #4 is an Enterprise Application Project.

    Project #5 is a Web Application Project. This Web project
    is associated with Project #4.

    Project #5 is dependent upon Project #1.

    Note: There are multiple EAR's. Each EAR contains one WAR.

    I want to configure my workspace such that:

    1) there is only 1 physical copy of foo.jar
    2) there is only 1 physical copy of bar.jar
    3) foo.jar is included in Project 1's Java build path
    4) bar.jar is included in Project 1's Java build path
    5) foo.jar and bar.jar is included in the WEB-INF/lib folder of
       both Web applications
    6) When I use WSAD's EAR Export feature, I want to
       the exported EAR to have foo.jar and bar.jar
       embedded inside the WAR's WEB-INF/lib directory

    I prefer a solution where I don't have to create multiple physical
    copies of the JAR's.

    As far as I can tell, WSAD 5.1.0 is requires that I create
    multiple physical copies of foo.jar and bar.jar

    Is there a better way?

    -Sean
  10. I prefer to handle these kinds of issues with build scripts.

    Put all of your Jars in one place (on a web server). Write an Ant build target that uses the <get> task to download all the jars.

    In the build targets that generate your EAR, copy the JARs to the right place. If you have cross-project dependencies, your "dist" target can update the master copy of the JAR via FTP or something.

    You do end up with lots of copies of your Jars, but since they are all pulled from one master location, this is not a big issue. Plus, it means that when you get a new developer (or need to rebuild your IDE), all you need to do is run the Ant script and get all of the correct jars.

    Look at the repository approach of Maven for a hyper-sophisticated variation on this theme (which is where I got the idea), and then do something similar but simpler.

    I use the trick in the build file for the Chrysalis project, if you want to see some sample code: http://chrysalis.sourceforge.net
  11. Has anyone experienced logging conflicts when using Log4J with multiple projects? At one point or another we've tried options 1, 3, and 4 - and have consistently found that if multiple projects were running on a server instance, the Log4J configs for whichever Log4J dependent project was accessed first - those configs would be used for the others (despite having different log4j.properties files for each).
  12. Has anyone experienced logging conflicts when using Log4J with multiple projects? At one point or another we've tried options 1, 3, and 4 - and have consistently found that if multiple projects were running on a server instance, the Log4J configs for whichever Log4J dependent project was accessed first - those configs would be used for the others (despite having different log4j.properties files for each).
    Yes!! I have this exact problem! Did you find a resolution to it?